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

2017 - IBM InterConnect, Las Vegas, USA

Transcript

1. InterConnect 2017 Migrating a Complex, Monolithic WebSphere Application to a Cloud Foundry Environment Matthias Haeussler Managing Consultant, NovaTec GmbH matthias.haeussler@novatec-gmbh.de @maeddes 1 3/15/2017
2. Agenda • Introduction • Migration • Review 2 3/15/2017
3. 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.
4. • ~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
5. 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“
6. 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
7. 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
8. 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
9. Agenda • Introduction • Migration • Review 9 3/15/2017
10. • 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
11. Java EE 6 or 7 11 3/15/2017
12. Migration 12 3/15/2017 https://developer.ibm.com/wasdev/docs/migration/
13. Tooling 13 3/15/2017 > 8000 required changes Exchange of JPA provider
14. Bad tooling – good matrix 14 3/15/2017
15. server.xml 15 3/15/2017 … Manual composition Generated by tool
16. 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
17. • 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
18. • 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
19. 19 3/15/2017 Handling of Async Communication App Legacy Component MQ Request MQ Response
20. 20 3/15/2017 Handling of Async Communication App Legacy Component MQ Request MQ Response X
21. 21 3/15/2017 Handling of Messaging App Legacy Component Outbound REST Call acknowledge REST Callback acknowledge Callback-URL Callback-URL
22. 22 3/15/2017 Database Analysis & Migration
23. • 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
24. • 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
25. Agenda • Introduction • Migration • Review 25 3/15/2017
26. • 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)
27. InterConnect 2017 27 3/15/2017