Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Migrating a Complex, Monolithic WebSphere App...

Migrating a Complex, Monolithic WebSphere Application to a Cloud Foundry Environment

2017 - IBM InterConnect, Las Vegas, USA

Matthias Haeussler

March 15, 2017
Tweet

More Decks by Matthias Haeussler

Other Decks in Technology

Transcript

  1. InterConnect 2017 Migrating a Complex, Monolithic WebSphere Application to a

    Cloud Foundry Environment Matthias Haeussler Managing Consultant, NovaTec GmbH [email protected] @maeddes 1 3/15/2017
  2. The DevOps problem 3 3/15/2017 Data Center WAS App PaaS

    Layer (CF) Micro Services App Kick-off Q3 2016 future Breakdown of monolithic architecture into multiple functional items (Cloud Native Approach) More flexibility in development and deployment of individual components (DevOps) Faster software delivery and quicker reaction to change Better scalability of components with heavy load Example: Today a minimal change of code requires the rebuild of the entire application package, e.g. in a HotFix. The deployment will have an effect on the overall application. With a micro service architecture, only the affected component needs to replaced. The deployment cycle is much quicker. Problems can be identified and solved easier. Functionality can be added faster.
  3. • ~1.000.000 requests/hour • ~100 kloc • Deployed in 2

    Geos – 3rd Geo currently being built up • Fully Java EE based – running on WAS 8 • Interfacing multiple external components • MQ • SOAP • DB2 4 3/15/2017 Some application details
  4. Initial decision 5 3/15/2017 Local Operating System WAS App Cloud

    Foundry Docker Container WAS App Cloud Foundry Liberty Buildpack Liberty App Cloud Foundry Various Buildpacks App‘ App‘ App‘ App‘ „WAS in container“ „Liberty profile“ „Reimplement as Cloud Native“
  5. Cloud-native approach 6 3/15/2017 Local Operating System WAS App Cloud

    Foundry Docker Container WAS App Cloud Foundry Liberty Buildpack Liberty App Cloud Foundry Various Buildpacks App‘ App‘ App‘ App‘ „WAS in container“ „Liberty profile“ „Reimplement as Cloud Native“ • Final goal state • Requires rewriting of large pieces of the infrastructure • Too risky to perform direct switch from current architecture • Would imply two parallel development streams
  6. 7 3/15/2017 WebSphere in container vs. Liberty Buildpack IBM •

    https://developer.ibm.com/wasdev/blog/author/amulholl/ • https://developer.ibm.com/wasdev/blog/2016/04/20/which-was-in-paas/ • https://developer.ibm.com/wasdev/docs/was-classic-or-was-liberty-how-to-choose/ Pivotal • http://cloud.rohitkelapure.com/2015/07/migrating-websphere-application-server.html • https://content.pivotal.io/blog/case-study-refactoring-a-monolith-into-a-cloud-native-app-part-1
  7. Roadmap 8 3/15/2017 Local Operating System WAS App Hosted CF

    App Local Operating System Liberty App Local Operating System Liberty App Hosted CF Liberty App Local CF Kick-off Q3 2016 future Micro Services
  8. • Replace WebSphere Application Server with Liberty Profile as runtime

    • Minimize change / risk by using database, messaging, transaction mechanisms etc as before • Evaluation of doability „Run application code successfully on Liberty“ • Migrate with least possible impact on application code, focus on configuration rather than modification • Time frame ~2 months 10 3/15/2017 Phase I – WAS to Liberty: Local Operating System WAS App Local Operating System Liberty App
  9. Remaining issues 16 3/15/2017 • Apache Axis2 API unavailable •

    WebSphere WorkArea API/SPI unavailable • WebSphere Web Services (WSS) API unavailable • Java API for RESTful Web Servives (JAX-RS) must be version 2.0
  10. • Run App application on a local Cloud Foundry environment

    • Start by using persistence & messaging mechanisms etc as before • Evaluate alternative options for persistence & messaging • Add requirements that surfaced during the migration to the product development backlog 17 3/15/2017 Phase II – Liberty to Cloud Foundry: Local Operating System Liberty App Local Operating System Liberty App CF Dev env
  11. • Hosted CF environment does not provide dev-style database and

    messaging • Requires migration of Database to target data center • Requires handling of messaging to non-Cloud environments • Removal of complete SOAP and MQ interface • Enforcement of REST interfaces 18 3/15/2017 Phase III – local to hosted Cloud Foundry: Liberty App Hosted CF Liberty App Local CF
  12. 21 3/15/2017 Handling of Messaging App Legacy Component Outbound REST

    Call acknowledge REST Callback acknowledge Callback-URL Callback-URL
  13. • Development of new and losely coupled functionalities will not

    depend on same application server, messaging and persistence mechanisms • New functionality is developed according to Cloud Native guidelines • REST for synchronous, RabbitMQ for asynchronous • Will not require any migration effort in later deployment phases • Serve as role model for future development • Example: “new” Microservice 23 3/15/2017 Phase III – new developments “Starve the monolith”: Local Operating System Liberty App CF local Spring „new“ REST
  14. • Decomposing the monolith • Implement individual components (Micro Services)

    according to 12- factor-app/Cloud-native guidelines • Combine decomposed services with newly developed ones • Provide the ability for each service to have tailored messaging and persistence 24 3/15/2017 Phase IV – Decomposition CF Spring QRC REST Liberty App CF Liberty App‘ Liberty App‘ Nodejs App‘ Spring QRC Ruby/ Go/ Swift MS‘ New dev Decomposition
  15. • First migrate the monolith to the platform, then start

    decomposing • Liberty migration tools very helpful to get started, but handle with care • Java EE compatibility matrix very important • Keep code modification low - try to handle via config options • Evaluate persistence and messaging constraints on target platform • Check usage distribution for database • Develop new code on target platform with modern design 26 3/15/2017 Lessons learned (so far)