Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

OpenShift Meetup - Application modernization and migration

1,156 views

Published on

Legacy IT systems are often the Achilles heel for established companies looking to compete successfully in the same environment as digital companies. Application modernization solutions include options for rebuilding platforms, re-coding, new architectures, consolidation and interoperability to align existing IT applications and investments more closely with the current needs of the digital business.

This talk will show you the different strategies, alternatives and considerations to realize that way towards the integral platforms of applications in the cloud like OpenShift. The migration and modernization of your business applications in these platforms will allow you to expand and improve the capabilities of them offering a new value, which allows you to gain in speed while optimizing your costs.

We will show an example of migration and modernization of a standard JEE application to OpenShift to consolidate some of the concepts described during the talk.

Link: https://www.meetup.com/es-ES/openshift_spain/events/244932110/

Published in: Technology
  • Login to see the comments

OpenShift Meetup - Application modernization and migration

  1. 1. Application Modernization and Migration Journey to the Cloud
  2. 2. oc whoami $ oc whoami rmarting, jromanmartin $ oc describe user rmarting jromanmartin Name: Jose Roman Martin Gil Created: 41 years ago Labels: father, husband, friend, runner, curious, red hatter, developer (in any order) Annotations: Senior Middleware Architect @ Red Hat Identities: mailto: rmarting@redhat.com GitHub: https://github.com/rmarting Twitter: https://twitter.com/jromanmartin LinkedIn: https://www.linkedin.com/in/jromanmartin/
  3. 3. APPLICATION MODERNIZATION & MIGRATION
  4. 4. DevOps !? DON’T MIND ME JUST SUPPORTING MY DEVS Devs Ops
  5. 5. Application Designs Monoliths Microservices
  6. 6. Application Designs Monoliths Microservices
  7. 7. Java and JavaEE still very relevant !? Source: DZone 2017 “Java Development and Evolution” whitepaper
  8. 8. What does AMM mean? APPLICATION MODERNIZATION & MIGRATION
  9. 9. What does AMM mean? APPLICATION MODERNIZATION & MIGRATION Focus on business workloads and solutions.
  10. 10. What does AMM mean? APPLICATION MODERNIZATION & MIGRATION Digital transformation. Journey to the future.
  11. 11. What does AMM mean? APPLICATION MODERNIZATION & MIGRATION Making old new again.
  12. 12. APPLICATION
  13. 13. Application Servers Framework / APIs App Middleware Services Operational Platform App App App App App Persistence | Security | Transaction | Messaging | HTTP Deployment | Management | Monitoring | HA | Logging Virtual Machine | Operating System
  14. 14. RUN Brownfield TRANSFORM Greenfield GROW VIRTUALPHYSICAL PRIVATE & PUBLIC CLOUD Complex & heterogeneous Lack of common standards Inconsistent automation & governance Typical Landscape Today
  15. 15. New problems to resolve Without adding more complexity and inconsistencies? MODERNIZE EXISTING APPS DEVELOP NEW APPLICATIONS THE MODERN WAY
  16. 16. MODERNIZATION
  17. 17. Why Modernize? DISRUPTION CUSTOMER EMBRACE BUSINESS ADAPTS DIGITAL TRANSFORMATION
  18. 18. Why Modernize? ● Every business is a technology business ● Code has no business value until it’s deployed ● Scale and Speed challenges ● Competitive challenges ● Gain Business Agility ● Growth enablement
  19. 19. MIGRATION
  20. 20. Why Migrate? There is not a “off button” for your Business Applications
  21. 21. Why Migrate? ● Optimizing and streamlining existing application usage ● Unlocking more value from your IT investments ● Consolidate application instances ● Rehost or replatform the application to newer infrastructure ● Develop new application code to extend the life and utility of the legacy application ● Convert and update existing code into new development languages ● Restructure application code to support a more modular, loosely coupled services architecture ● Retire the existing packaged application and migrate to a new application
  22. 22. JOURNEY TO OPENSHIFT
  23. 23. Where would like to be? ● One platform to support you today and tomorrow TRANSFORM Greenfield GROWRUN Modernized brownfield COMMON HYBRID APPLICATION INFRASTRUCTURE BETTER SOFTWARE ARCHITECTURE AGILE INTEGRATION STREAMLINE APPLICATION LIFECYCLE CONTINUOUS INNOVATION MODERN APPLICATION CONCEPTS
  24. 24. OpenShift is the new Application Server Runtime App Cloud Platform Data Build | Deploy | Scheduling | Scaling | Elasticity | Metrics | Logging Security IMDG Messaging Runtime Svc Runtime Svc Cloud Provider
  25. 25. How do it get it? ● How do we build and run applications in the new world? ● Strategy and methodology ● Containerization is not the only step
  26. 26. STRATEGIES
  27. 27. The 6 R’s Source: https://aws.amazon.com/cloud-migration/
  28. 28. Decision Tree Rehost (lift & shift) Replatform (lift & reshape) Repurchase Refactor (rewrite & decouple) Assess, review, prioritize. Retire Retain as is (for now) ?Existing App Out-of-scope application for the migration. End-of-life application and will not be migrated. Replacement planned for the application. Enhancements on top of the minimal changes. (e.g. tech updates, mavenization, re-architecture) Minimal migration (as few changes as possible). Not a target Highly scaled and high rate of change apps are candidates Smaller or frozen apps are candidates here
  29. 29. Patterns in Modernizing Applications REHOST (lift & shift) ● Containerize existing workloads ● Deploy them on a PaaS ● Keep external integrations and data on legacy ● Legacy applications have to be well written and suited REPLATFORM (augment) ● Legacy remains intact ● New layer - new capabilities ● Deploy on PaaS ● New integration points between legacy and new layers (Need for Agile Integration) REFACTOR (rewrite & decouple) ● Legacy is totally replaced ● New interfaces and data ● Use PaaS to run ● Some data and features can be re-wrapped, but mostly are retired.
  30. 30. Patterns in Modernizing Applications Cost of Migration Time REHOST (Lift and Shift) REFACTOR (Rewrite and Decouple) REPLATFORM (Augment with new Layers) Generally the most expensive and longest
  31. 31. Modern Application Concepts Future-proof applications BETTER SOFTWARE ARCHITECTURE Modularize “Fast moving monolith” Microservices Clean technical debt Speed up your business STREAMLINE APPLICATION LIFECYCLE Accelerate time from idea to production Continuous Integration & Delivery (CI/CD) Automation & self-service Container technology Foster an agile culture CONTINUOUS INNOVATION Agile methodology DevOps principles Collaboration Bridge old and new AGILE INTEGRATION Decouple, expose & integrate APIs, services & applications Need hybrid-cloud-enabled integration platform Enhancing applications, platform and processes
  32. 32. CLOUD-READINESS
  33. 33. Cloud-Readiness ● “Cloud-Native” ○ Distinctive architectural characteristics ● “Cloud-Compatible” ○ Represents the minimum viable product ● “Cloud-Ready” / “Container-Ready” / “OpenShift-Ready” ● Not every application should / can / must be made “cloud-native” ○ Container-Ready is often enough ○ Primary focus on OpenShift adoption instead on high re-architecturing efforts
  34. 34. Cloud-Native Application Ideals ● Ability to handle dynamic scaling, load configuration in flexible ways, and aggregate logs ● Dynamic discovery of dependencies ● Load balancing of requests to dependencies ● Enable application monitoring and distributed tracing ● Circuit breaker and and bulkhead patterns ● Feature toggles and health checks
  35. 35. Journey from Cloud-Compatible to Cloud-Native ● Start with Cloud-Compatible changes ○ Create support from external configurations ○ Remove IP bindings ○ Run on Linux ○ Ensure logs write to console/stdout ● Progress with subsequent iterations ● Actual end state should be dictated by the needs of the business
  36. 36. CONTAINERIZING APPLICATIONS
  37. 37. What is Containerization? ● Packaging of a configured application and all its dependencies into a light, portable, cloud-ready sandbox.
  38. 38. Containerization Challenges Beyond the code APPLICATIONS Dependencies Concurrency Log and file system State and persistence Environment independance Backing services Port bindings Automation Admin processes Configuration management Application aggregation Availability and reliability Elastic scaling Security INFRASTRUCTURE Application lifecycle Application discovery Log management Monitoring and health Knowledge governance PROCESS
  39. 39. DEMO TIME
  40. 40. Demo Time - Show me the code ● Standard JEE Application ○ JPA + Hibernate to manage an external MySQL Database ○ JMS Queues to add more information to the application ○ MDB to load data from JMS Queues to store information into MySQL Database ○ Initial Servlets consuming extra startup time ● Main issues ○ Extra time to be ready after redeploy it ○ Monolithic architecture
  41. 41. Demo Time - Show me the code ● Migration ○ Package using Wildfly Swarm ○ Deploy using Maven Fabric8 Plug-In ○ Automate ○ Monitoring ○ Scale up/down
  42. 42. Demo Time - Wildfly Swarm ● An innovate approach to package and run Java EE applications ● Just enough App Server: package your app with required runtime dependencies (but nothing more) ● Based in Wildfly Application Server ● Packaged as an Uber Jar (self-contained, executable Java archive)
  43. 43. Demo Time - Maven Fabric8 PlugIn ● Brings your Java applications on to Kubernetes and OpenShift ● Provides tight integration into Maven ● Focus on two tasks: ○ Building Docker Images ○ Creating Kubernetes and OpenShift resource descriptors
  44. 44. Demo Time - Show me the code ● Modernization ○ Deploy Messaging Services ○ Deploy Integration Services ○ Deploy CronJobs ○ Remove old operations in monolithic application ○
  45. 45. Questions?
  46. 46. Thank you!

×