App Mod 01: Moving existing apps to the cloud
•Transferir como PPTX, PDF•
1 gostou•930 visualizações
Slides from Red Hat's workshop in Detroit, June 5: Monoliths to Microservices
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a App Mod 01: Moving existing apps to the cloud
Semelhante a App Mod 01: Moving existing apps to the cloud (20)
Mais de Judy Breedlove
Mais de Judy Breedlove (13)
Último
Último (20)
App Mod 01: Moving existing apps to the cloud
- 1. MONOLITHS TO MICROSERVICES: APP TRANSFORMATION Hands-on Technical Workshop David Kramer, Sr. Solutions Architect Red Hat OpenShift Platform dkramer@redhat.com
- 2. MOVING EXISTING APPS TO THE CLOUD
- 3. Fast Monoliths Existing, Java EE, Spring MVC Java EE MSA Monolith Decomposition, Enterprise Java MSA Fast Monoliths (Java EE, Spring) Tomcat Spring Boot / MVC Web Tomcat, Spring MVC, SpringBoot Greenfield Reactive Java Java EE - mono to micro. / greenfield Reactive Reactive Java / Polyglot MSA Reactive JS Reactive client / server-side JavaScript Greenfield polymorphic JavaScript Server -less FaaS Existing Applications New Applications Spring MSA Java MSA Greenfield Java / Spring MSA THE SPECTRUM OF ENTERPRISE APPS
- 4. MIGRATION AND MODERNIZATION APPROACHES ● API-centric polyglot microservices architecture ● Autonomous development teams ● Agile development, continuous deployment, DevOps culture ● Containerized & orchestrated cloud deployments ● Reuse existing functionality and data as much as possible ● Move existing workloads to a modern deployment platform ● Apply new processes, products, and technology to existing apps MODERNIZING EXISTING APPS DEVELOPING NEW APPLICATIONS
- 5. GENERAL DISTRIBUTION PATTERNS IN MODERNIZING WORKLOADS 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 CONNECT & EXTEND ● Legacy remains intact ● New layer - new capabilities ● Deploy on PaaS ● New integration points between legacy and new layers (Need for Agile Integration) RIP & RE-WRITE ● Legacy is totally replaced ● New interfaces and data ● Use PaaS to run ● Some data and features can be re-wrapped, but mostly are retired.
- 6. GENERAL DISTRIBUTION PATTERNS IN MODERNIZING WORKLOADS 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 CONNECT & EXTEND ● Legacy remains intact ● New layer - new capabilities ● Deploy on PaaS ● New integration points between legacy and new layers (Need for Agile Integration) RIP & RE-WRITE ● Legacy is totally replaced ● New interfaces and data ● Use PaaS to run ● Some data and features can be re-wrapped, but mostly are retired. FOCUS FOR THIS SECTION
- 7. GENERAL DISTRIBUTION LIFT-AND-SHIFT MONOLITH TO CLOUD Application Server HTML Javascript Web ServiceServiceService Service Service Service Data Access HTML Javascript Web ServiceServiceService Service Service Service Data Access
- 8. GENERAL DISTRIBUTION LIFT-AND-SHIFT MONOLITH TO CLOUD HTML Javascript Web ServiceServiceService Service Service Service Data Access CONTAINER
- 9. 12 Why migrate to JBoss EAP? Runtime [1][2] (framework) Boot time server only Boot time including app deployment Memory usage without load Memory usage under load Measured[3] throughput JBoss EAP (Java EE) 2 - 3 sec 3 sec 40 MB 200 - 400 MB 23K req/sec JBoss EAP (Spring) 2 - 3 sec 7 sec 40 MB 500 - 700 MB 9K req/sec JBoss WS/Tomcat (Spring) 0 - 1 sec 8 sec 40 MB 0.5 - 1.5 GB 8K req/sec Fat JAR (Spring Boot) N/A 3 sec 30 MB 0.5 - 2.0 GB 11K req/sec [1] The microservice is a simple REST application. [2] All runtimes are using their default settings [3] The performance test was conducted with ApacheBench using 500K request with 50 users and keep-alive enabled. Don’t believe it? Try it out yourself http://bit.ly/modern-java-runtimes
- 10. LAB: MOVING EXISTING APPS TO THE CLOUD
- 11. GOAL FOR LAB In this lab you will learn: ● How to migrate an existing legacy Java EE application (CoolStore) from Weblogic to JBoss EAP using Red Hat Application Migration Toolkit ● How to deploy the result to OpenShift container platform to create a Fast Moving Monolith ● Different alternatives to building and deploying an application
- 13. COOLSTORE APPLICATION Data Tier Presentation Tier Business Logic Tier <<SLSB>> Inventory Service <<SFSB>> ShoppingCart Service <<SLSB>> Catalog Service Database <<REST>> Product- Endpoint <<SLSB>> Promo Service <<REST>> Cart- Endpoint <<SLSB>> Shipping Service <<AngularJS>> Web <<SLSB & MDB>> OrderService <<REST>> Order- Endpoint
- 14. Red Hat Application Migration ToolkitCatalyze large scale application modernizations and migrations ● Automate analysis ● Support effort estimation ● Accelerate code migration ● Free & Open Source IBM WebSphere AS Oracle WebLogic Server JBoss EAP upgrades Cloud readiness, containerization Pluggable: your own rules Java EE upgrades Eclipse plugin Command line interface Web console
- 15. LAB: MOVING EXISTING APPS TO THE CLOUD SCENARIO 2 MOVING EXISTING APPS TO THE CLOUD WEB: openshift-modernize-apps.katacoda.com SLIDES (PDF): bit.ly/m2m-slides
- 17. RESULT OF LAB In this lab you: ● Familiarized yourself with the Lab environment ● Migrated the CoolStore monolith from Weblogic to JBoss EAP using Red Hat Application Migration Toolkit ● Created a new development project on OpenShift ● Deployed the migrated app to OpenShift using a Template and a Binary Build ● In the next lab you will explore OpenShift deeper as a developer
- 19. MONOLITHS TO MICROSERVICES: APP TRANSFORMATION HANDS-ON LAB22 3-9 1$ subscription = 5-10$ services 100-2000MONTHS PROJECT DURATION DAYS OF CONSULTING 43% gains in DEV. PRODUCTIVITY 79% LESS EXPENSIVE 509% ROI over 3 years 10 months PAYBACK of investment 40% infrastructure SAVINGS 66% FASTER app delivery 8 months PAYBACK Sources: Consulting services data: Red Hat IDC “The business value of JBoss EAP”, 2015 IDC - “The business value of Red Hat OpenShift”, 2016 BUSINESS OPPORTUNITY FOR APP MODERNIZATION
- 20. Application Modernization & Migration23 THE UMBRELLA One customer conversation opening many opportunities MODERNIZATION MIGRATION APPLICATION MODERNIZATION & MIGRATION CONTINUOUS INNOVATION AGILE INTEGRATION STREAMLINE APPLICATION LIFECYCLE BETTER SOFTWARE ARCHITECTUR E APPLICATION SERVERS BUSINESS DECISION MANAGEMENT INTEGRATION PLATFORMS APPLICATION INFRASTRUCTUR E REDUCE / AVOID VENDOR LOCK-IN, INFLEXIBLE LICENSE MODELS REMOVE TECHNICAL DEBT & RISK RE-BALANCE MAINTENANCE AND INNOVATION INCREASE SPEED & BECOME MORE PRODUCTIVE ADOPT AGILE METHODOLOGIES, DEVOPS DECREASE COMPLEXITY, INCREASE EFFICIENCY Customer value beyond cost - Digital transformation
- 21. Application Modernization & Migration24 Modularize Adopt standards Reuse instead of reinvent Clean technical debt BETTER SOFTWARE ARCHITECTURE AGILE INTEGRATION Decouple, integrate, govern APIs, services, applications & clouds STREAMLINE APPLICATION LIFECYCLE Accelerate ideas to production Automation & self-service Containerization CI / CD Agile methodology DevOps principles Collaboration CONTINUOUS INNOVATION MODERNIZATION APPLICATION SERVERS IBM WebSphere, Oracle WebLogic, Glassfish, Community versions … … to EAP / JWS / JDG BUSINESS DECISION MANAGEMENT ILOG, TIBCO, ActiveMatrix, Pega, Bonita, Oracle & IBM Suites Red Hat JBoss BPMS & BRMS INTEGRATION PLATFORMS Functional (TIBCO, WebMethods, JCAPS, Cordys … to JBoss Fuse) Data (JDV) Messaging (AMQ) APPLICATION INFRASTRUCTURE OS (Windows/AIX/Unix to RHEL) Virtualization (RHEV) Containers (OpenShift) APPLICATION MODERNIZATION & MIGRATION MIGRATION
- 22. Application Modernization & Migration BENEFITS Red Hat provides the most comprehensive technologies, tools and services to support you TODAY and TOMORROW APPROACH COMBINE TRANSFORMATION FACTORY RED HAT APPLICATION MIGRATION & MODERNIZATION PROGRAM
- 23. Application Modernization & Migration SOME CUSTOMERS Application Modernization customers Read more at https://www.redhat.com/en/success-stories
- 24. Application Modernization & Migration JUMPSTART YOUR MODERNIZATION WITH RED HAT OPEN INNOVATIONS LABS INNOVATION ACCELERATED DEVELOP CONTEMPORARY APPS • Develop on PaaS environment • Transform how you design and develop apps • Adopt lean and agile principles • Master DevOps practices MODERNIZE TRADITIONAL APPS • Extend applications • Optimize applications • Scale applications • Expose to orchestration COLLABORATION Space to work, innovate, and discuss RESIDENCY An eight-week accelerated teaming engagement COMMUNITY INCUBATION Communities supporting innovation
- 25. Application Modernization & Migration INNOVATION LABS PROCESS Discovery session Agile, Lean, DevOps Backlog and roadmap PUSH-BUTTON INFRASTRUCTURE DEMO DAY CONTINUOUS LEARNING PRE-WORK RESIDENCY RETROSPECTIVE
- 26. Application Modernization & Migration DRIVE A CULTURE OF INNOVATION THROUGH A SPACE THAT FOSTERS COLLABORATION BOSTON SILICON VALLEY LONDON INNOVATE ANYWHERE • Purpose-driven • Collaborate and make • Network and share • Flex and adapt • Rejuvenate and connect SINGAPOR E
Notas do Editor
- - This is the reality of today and for the near future is that most larger organizations are going to continue to have a mixture of application types across a broad spectrum of technologies... - Main reason for this is because there is no one-size-fits-all approach that works for everything. - You’ll likely have a mixture of: - legacy applications - fast-moving monoliths built on Java EE or Spring - lighter weight cloud native and/or reactive apps - and/or serverless architectures The one thing you can count on is that they will need to talk to each other... MSA = Micro Service Architecture
- Let's start with the 2 main modern app/dev approaches -- 1. Modernize your existing apps 2. Re-develop new applications One could argue that most organization will leverage both of these approaches and that sometimes they are inter-related. Therefore, we want a target deployment environment that can be blended (with a mixture or modern and legacy workloads), one that is flexible and adapted for today's use cases.... Today, throughout the lab scenarios, we're going to position OpenShift and a variety of Red Hat technologies as well as methodologies that fundamentally address modernizing existing apps... ######## Modernizing existing apps means re-using applications as much as possible, sometimes achieving 100% reuse -- but moving them to an environment in which the app benefits from more automation, more consistent and continuous integration, and sets the app and its developers up for a deeper modernization effort in the future. In contrast, some organizations make a concerted effort to build net-new apps whose purpose is to replace some, or all of an existing app, but employing modern app development frameworks and architectures, and developing a process to get those apps to production very quickly and with less downtime when something fails.
- To address this challenge, Let’s talk about modernization and what to do with those existing apps. You essentially have three main choices. Rehost, reshape, or rearchitect. The other possibilities are essentially do nothing, and as we know isn’t really an option for most businesses today. Rehosting (also known as lift and shift) simply moves the app as-is over to a new platform, with no changes to the code except possibly moving away from proprietary APIs to a standard. Reshape is similar to a re-host but involves a slightly more invasive approach to making the app not only work on the new platform, but to take advantage of the platform’s features to provide enhanced performance, better manageability or possibly new business value. Finally a rearchitect is a complete re-write using modern application development methodologies and tools. Determining which to do requires analysis and prioritization based on business benefit and risk. For example, apps requiring high scale and for which you’d like to be able to revise quickly in the face of changing requirements are usually good for a reshape or rearchitect effort. Larger, more established, business critical apps might be rehosted first, and incrementally modernized as time and resources permit.
- Along these lines (modernizing existing apps), you essentially have three main choices. Rehost, reshape, or rearchitect. And it's "ok" if the lines get blurry a bit between these options. Rehosting (also known as lift and shift) simply moves the app as-is over to a new platform, with no changes to the code except possibly moving away from proprietary APIs to a standard. We have an example of this in our first lab scenario... Reshape is similar to a re-host but involves a slightly more invasive approach to making the app not only work on the new platform, but to take advantage of the platform’s features to provide enhanced performance, better manageability and/or possibly new business value. Finally, a rearchitect scenario is a complete re-write using modern application development methodologies and tools. Determining which to do requires analysis and prioritization based on business benefit and risk. For example, - apps requiring high scalability and for which you’d like to be able to revise quickly in the face of changing requirements are usually good for a reshape or rearchitect effort. - Larger, more established, business critical apps might be rehosted first, and incrementally modernized over time as resources permit.
- As we go thru this workshop, we’re going to explore these 3 patterns and approaches to app modernization… Starting with Lift and Shift… Again, we’re going to focus on “containerizing” the existing workload. We’ll then: -- Deploy the container in OpenShift -- Keeping external integrations and data on existing (or legacy) platforms -- Keep in mind, legacy workloads have to be well written and suited for this scenario… OK… so, anyone in the audience… why would you embark on this scenario? What benefit(s) do you see in this "lift and shift approach"? -- immutable workloads / leverage CI/CD -- better use of infrastructure (denser workload environment) -- process improvements -- etc…
- I mentioned: “determining which [workload] to migrate requires analysis and prioritization based on business benefit and risk…” So, along those lines: Red Hat has developed the “Application Migration Toolkit,” over the last decade or so through our consulting services. Upstream this is called windup… Essentially, it’s a collection of IP in the form of "rules" that our consultants leveraged in the field as they helped customer’s get off proprietary java platforms and embrace just the J2EE spec. Thus, reducing cost in their stack, simplifying the environment and starting to understand the logical "breakdown" within the monolithic applications. Windup leverages a rules/knowledge base and provides value across a portfolio of apps. I am not suggesting this approach for just 1 app… But across a portfolio, it identifies trends and low-hanging fruit to help you prioritize as you embark on this journey.
- So this diagram represents what we’re going to accomplish in the labs… -- We're going to explore Red Hat Red Hat Application Migration Toolkit… -- once we address/refactor some proprietary java extensions leveraging Red Hat Application Migration Toolkit as a reference guide -- we’ll deploy the app on EAP and then leverage a certified Red Hat EAP image which can run on OCP
- Many case studies have one thing in common: existing apps they want to modernize. Easier to develop since all dependencies are included Single code base for teams to work on No API backwards compatibility issues since all logic is packaged with the application Single deployable unit Hard for large teams to all work in the same code base. Who broke the build? Longer release cycles and even small changes goes through entire test suite and validation Same language / Same Framework in most cases Entropic resistance is low
- Before heading into the lab, let’s put some perspective around the first scenario… We’re re-packaging a proprietary weblogic java workload on JBoss EAP so that ultimately we can deploy it as a container on OCP Some would argue that this approach is problematic from a performance perspective… double encapsulation from the java server and container/container orchestration layers So I wanted to provide some metrics to level-set detailed out on the screen… again, workloads have to be well written and suited for this scenario, but these metrics help validate the approach presented in the labs. Note the link that we've included... if you want to drill into this further and try it for yourself.
- This is our monolith architecture… pretty standard 3 tier app...
- As mentioned, we’re going to use the Red Hat Application Migration Toolkit to anaylis our monolith sample app. Automate analysis -- to look for patterns and proprietary extensions Support effort estimation Accelerate code migration Free & Open Source
- So with one umbrella conversation to one group at a client it opens up quite a bit of opportunity to talk to others, such as infrastructure, IT, development, and the CIO about how you and Red Hat can address modern app dev concerns. All of the customer values mentioned near the bottom map very well to the Red Hat portfolio, including RHOAR as of today, so I encourage you to learn more about our app modernization program and use the resources you have as partners to drive those conversations with your clients.
- As I said before, partners are THE KEY to our success - so much so that Red Hat Consulting has developed an extensive App Migration and Modernization practice which, along with you, our partners, provides a proven, repeatable and measurable way to migrate and modernize your apps. CIOs don’t like to cut checks for open-ended, costly programs that simply re-write existing apps, so it’s important to understand how modernization plays a key role in your discussions. But it’s not just about the software and the apps - much of the so-called digital transformation involves the organizational changes necessary to support it, and this is another opportunity to strenghen your relationship with Red Hat and your own clients - the “trusted advisor” Red Hat likes to mention from time to time.
- As I said before, partners are THE KEY to our success - so much so that Red Hat Consulting has developed an extensive App Migration and Modernization practice which, along with you, our partners, provides a proven, repeatable and measurable way to migrate and modernize your apps. CIOs don’t like to cut checks for open-ended, costly programs that simply re-write existing apps, so it’s important to understand how modernization plays a key role in your discussions. But it’s not just about the software and the apps - much of the so-called digital transformation involves the organizational changes necessary to support it, and this is another opportunity to strenghen your relationship with Red Hat and your own clients - the “trusted advisor” Red Hat likes to mention from time to time.
- As I said before, partners are THE KEY to our success - so much so that Red Hat Consulting has developed an extensive App Migration and Modernization practice which, along with you, our partners, provides a proven, repeatable and measurable way to migrate and modernize your apps. CIOs don’t like to cut checks for open-ended, costly programs that simply re-write existing apps, so it’s important to understand how modernization plays a key role in your discussions. But it’s not just about the software and the apps - much of the so-called digital transformation involves the organizational changes necessary to support it, and this is another opportunity to strenghen your relationship with Red Hat and your own clients - the “trusted advisor” Red Hat likes to mention from time to time.
- As I said before, partners are THE KEY to our success - so much so that Red Hat Consulting has developed an extensive App Migration and Modernization practice which, along with you, our partners, provides a proven, repeatable and measurable way to migrate and modernize your apps. CIOs don’t like to cut checks for open-ended, costly programs that simply re-write existing apps, so it’s important to understand how modernization plays a key role in your discussions. But it’s not just about the software and the apps - much of the so-called digital transformation involves the organizational changes necessary to support it, and this is another opportunity to strenghen your relationship with Red Hat and your own clients - the “trusted advisor” Red Hat likes to mention from time to time.
- As I said before, partners are THE KEY to our success - so much so that Red Hat Consulting has developed an extensive App Migration and Modernization practice which, along with you, our partners, provides a proven, repeatable and measurable way to migrate and modernize your apps. CIOs don’t like to cut checks for open-ended, costly programs that simply re-write existing apps, so it’s important to understand how modernization plays a key role in your discussions. But it’s not just about the software and the apps - much of the so-called digital transformation involves the organizational changes necessary to support it, and this is another opportunity to strenghen your relationship with Red Hat and your own clients - the “trusted advisor” Red Hat likes to mention from time to time.
- As I said before, partners are THE KEY to our success - so much so that Red Hat Consulting has developed an extensive App Migration and Modernization practice which, along with you, our partners, provides a proven, repeatable and measurable way to migrate and modernize your apps. CIOs don’t like to cut checks for open-ended, costly programs that simply re-write existing apps, so it’s important to understand how modernization plays a key role in your discussions. But it’s not just about the software and the apps - much of the so-called digital transformation involves the organizational changes necessary to support it, and this is another opportunity to strenghen your relationship with Red Hat and your own clients - the “trusted advisor” Red Hat likes to mention from time to time.