Migration eines Java EE Monolithen nach Cloud Foundry auf Azure – Lessons learned

2017 IT Tage, Frankfurt, Germany

Transcript

1. Migration eines Java EE Monolithen nach Cloud Foundry auf Azure – Lessons learned Matthias Haeussler & Thorsten Jakoby t 11. – 14.12.2017 Frankfurt am Main #ittage 1
2. Agenda • Infos über Sprecher & NovaTec • Vorstellung der Anwendung ◦ Business & Technischer Kontext • Initiale Problem Situation • High-Level Migrationspfad • Detail Analyse von Themen ◦ Anwendung ◦ Persistenz & Messaging ◦ Platform 2
3. Sprecher & NovaTec Consulting GmbH Matthias Häußler - Consultant @maeddes Thorsten Jakoby - Consultant @jakobyte1024 3
5. Business Kontext • Zentrale Backend Komponente für eine “connected vehicle” Anwendung ◦ Verbindet Nutzer mit Fahrzeug für z.B. ▪ Automatisches Abschließen der Tür ▪ Vorkonfiguration der Standheizung/Klimaanlage ◦ B2B Use Case ▪ “Pay how you drive” ◦ Anlage und Verwaltung von Nutzerkonten ◦ Sichere Fahrzeugverknüpfungsprozesse ◦ Prozesse für Dienstaktivierung • Großer deutscher Automobilhersteller 5
6. WAS App DB2 MQ Client Client Client Eclipse SOAP MQ REST Anwendungsumgebung 6
7. • ~ 1.000.000 Requests/Stunde • ~100 kloc • Deployed in 3 Geos • Komplett auf Java EE 6 basiert - läuft auf WAS 8 • Schnittstellen zu externen Komponenten via ◦ JMS ◦ HTTP ◦ SOAP ◦ JDBC (DB2) Technische Details der Anwendung 7
8. Die Ausgangssituation • Modernisierung der Infrastruktur • Verbesserung der Deployment Geschwindigkeit & Zyklen • Klarere Domain-spezifische Trennung der Anwendung • Beispiel Hotfix Data Center WAS App Cloud Micro Services App Kick-off Q3 2016 Zukunft 8
9. Local Operating System Monolith Public Cloud Local Operating System Cloud ready app Local Operating System Public Cloud Local/Dev Cloud Kick-off Q3 2016 Zukunft High-Level Migrationspfad Cloud ready app Cloud ready app Cloud native app 9
10. 10 Local Operating System WAS App Hosted CF App Local Operating System WLP App Local Operating System WLP App Hosted CF WLP App Local CF Zukunft Micro Services Migrationspfad Kick-off Q3 2016
11. Anwendung 11
12. Anforderung • Die Anwendung in einen “cloud-ready” Zustand zu bringen ◦ Lauffähig in einem Container ◦ Idealerweise Unterstützung eines Liberty Buildpacks/Runtime ◦ Skalierbar ◦ Stateless • Wahl der Variante mit geringstem Risiko • Ermöglichung eines fließenden Wechsels / Zero-downtime 12
13. 13 Local Operating System WAS App Cloud Foundry Docker Container WAS App Cloud Foundry Liberty Buildpack WLP App Cloud Foundry Various Buildpacks App‘ App‘ App‘ App‘ „WAS in container“ „Liberty Profile“ „Reimplementierung Cloud Native“ Initiale Ausrichtung
14. 14 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“ „Reimplementierung Cloud Native“ Initiale Ausrichtung • Einfacher WAS nur sehr bedingt Container-tauglich • WAS Cluster unmöglich • Zu lange Startup Zeit • Von IBM nicht empfohlen
15. 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“ „Reimplementierung Cloud Native“ • Gewünschter Zielzustand • Erfordert Umschreiben großer Teile • Zu riskant für direkte Umstellung von alter zu neuer Architektur • Bedeutet zwei parallele Code-Branches bis zum Go-Live Initiale Ausrichtung 15
16. Paralleler Branch Neuer “cloud” branch “Alter” master branch Deployment Cloud Deployment Legacy Manual merges der Deltas 16
17. One codebase - many deploys “One and only” master branch Deployment Cloud Deployment Legacy Verschiedene Konfigurationen Deltas in Funktionalität nur bei einem branch 17
18. Liberty App DB2 MQ Client Client Client Eclipse SOAP JMS REST Anwendungsumgebung WAS 18
19. • Austausch von WebSphere Application Server mit WebSphere Liberty Profile als Runtime • Ansatz mit gleicher Backend Komponente für minimalste Änderung • Proof of Concept “Anwendung kann in Liberty laufen” • Fokus auf möglichst wenig Änderung im Code und Logik, sondern in hauptsächlich in der Konfiguration • Dauer ca. 2 Monate Phase I - WAS nach WLP Local Operating System WAS App Local Operating System WLP App 19
20. 20 Java EE 6 oder 7?
21. 21 IBM Migration Tools • IBM bietet zwei Tools zur Migration ◦ IDE Plugin ◦ CLI Analyse • https://developer.ibm.com/wasdev/docs/migration/
22. 22 > 8000 notwendige Änderungen Austausch des JPA Providers Überraschende Ergebnisse
23. 23 Hilfreiche Matrix
24. 24 … Manuelle Erstellung (Java EE 6 & 7) Vom Tool generiert WLP Konfiguration - server.xml
25. Wirkliche Findings • Apache Axis2 API nicht verfügbar • WebSphere WorkArea API/SPI nicht verfügbar • WebSphere Web Services Security API nicht verfügbar • Java API for RESTful Web Services (JAX-RS) muss Version 2.0 sein • JNDI Lookups mit “ejblocal” Prefix sind nicht unterstützt • WAS toleriert mehr (auch außerhalb der Java EE Specs) ◦ z.B. Klasse mit @Singleton und @Stateless annotiert 25
26. Lessons learned • WAS toleriert mehr als WLP -> code wird “sauberer” in WLP • PoC sehr hilfreich - Modell außerhalb “Agile” • IBM Tools hilfreich, aber nicht immer akkurat - “hört sich eventuell schlimmer an als es wirklich ist” • Bietet gute Grundlagen, reicht aber allein oft nicht aus • Kompatibilitätsmatrix sehr hilfreich • IBM Support hilfreich 26
27. Persistenz 27
28. Anforderungen • Ein relationales “cloud-native” Datenbanksystem verwenden • Weiterhin JPA und Flyway verwenden • Automatisches verbinden und migrieren der Datenbank möglich 28
29. Persistenz - vorher • DB2 als DBMS ◦ Skalierung per Bufferpool & Tablespaces ◦ Administriert und gewartet von “Kunden-Ops” ◦ Betrieben in eigenem Datencenter • Flyway zur Datenbankmigration • Apache OpenJPA als OR-Mapper 29
30. Persistenz - Suche und Auswahl • Entscheidung ob und welcher IaaS / PaaS Provider lange Zeit unklar • DBMS Kandidaten waren ◦ MySQL ◦ AzureSQL ◦ PostgreSQL • DB2 wurde als Benchmark festgelegt • Umfassender Vergleich erstellt: ◦ Transactional DDL ◦ Backup / Restore ◦ Scaling ◦ Maintenance ◦ Monitoring / Analysis 30
31. Persistenz - AzureSQL • AzureSQL in Cloudumgebung ◦ Skalierung durch Azure ◦ Performanzanalyse on-board • MSSQL-Docker-Container für IDE 31
32. Persistenz - Cloud • DB2 spezifische Datentypen migrieren • OpenJPA Dictionary anpassen • Single Schema einführen • Reservierte Wörter beachten (bspw. ‘key’ in DB2 möglich) • SQL-Dialekt der initialen DDL migrieren / neue Flyway baseline einführen 32
33. Lessons learned • gut gemacht: keine Geschäftslogik in der Datenbank • Das manuelle migrieren der Migrationsskripte zeigte auf, welche DB2-spezifischen Mechanismen verwendet wurden (bspw. MERGE INTO Statements) • Wechsel zwischen AzureSQL und MySQL mit geringem Aufwand verbunden (Sequences müssen entfernt / ersetzt werden) 33
34. Messaging 34
35. Anforderungen 35 • App soll mit “Cloud-nativen Bordmitteln” kommunizieren • Kompatibilität und Konnektivität zu Non-Cloud Applikationen bleiben erhalten
36. Messaging - vorher • Applikationen kommunizieren synchron und asynchron mittels verschiedenen Technologien • Anwendungslandschaft erfordert weiterhin asynchrone Kommunikation, auch in / aus der Cloud 36 App SOAP / REST / JMS Request SOAP / REST / JMS Response App
37. Messaging - Cloud • JMS ist Java-spezifisch und somit nicht Cloud-native • AMQP-Broker via JMS-Interface möglich, jedoch nicht eingesetzt • Gewählt wurde Async-REST: ◦ REST Call übergibt Callback-URL ◦ AMQP-broker transparent integriert 37 App Outbound REST Call incl. Callback-URL acknowledge REST Callback acknowledge App B r o k e r
38. Lessons learned • Async REST räumt den Messaging-Technology-Stack der App auf • Apache QPID hätte können JMS via AMQP ermöglichen, wenn es im CDI-Container wäre • Azure Service Bus mit QPID in der benötigten Version inkompatibel • Async REST wird entfernt sobald “alles in der Cloud ist” ; AMQP bevorzugt 38
39. Platform 39
40. Anforderungen • Die “cloud-ready” Anwendung in einer Cloud Foundry Umgebung zu betreiben • Erster Ansatz in einer lokalen Dev VM mit Anbindung existierender Services für Datenbank und Messaging • Zweiter Ansatz mit public Variante PCF auf Microsoft Azure und Anbindung cloud-basierter Services für Datenbank und Messaging 40
41. Was ist Cloud Foundry? • Applikations-orientierte Platform as a Service (PaaS) • Fokus auf einfache Handhabung • Starke Anlehnung an 12-factor app guidelines ◦ IV. Unterstützende Dienste ◦ VIII. Nebenläufigkeit ◦ X. Dev-Prod Parität ◦ XI. Logs ◦ ... 41 (source: http://nanduni.blogspot.de)
42. Cloud Foundry Basics 42 app buildpack cf push app Applications Services container
43. Mit WLP auf Cloud Foundry • App auf Liberty in lokaler Entwicklungsumgebung betreiben • Erster Ansatz mit gleicher Persistenz und Messaging Backends wie zuvor Local Operating System Liberty App Local Operating System Liberty App Local CF env 43
44. Liberty App DB2 MQ Client Client Client Eclipse SOAP MQ REST Anwendungsumgebung 44
45. Gleicher host/network Liberty Buildpack App DB2 MQ Client Client Eclipse MQ REST Cloud Foundry Cloud Foundry (PCF Dev) als Umgebung 45
46. Anwendung als “self-contained” Artefakt
47. github Cloud Foundry 47 image Liberty Buildpack App Liberty Buildpack Cloud Foundry deployment - cf push
48. Zwischenergebnis • Cloud (Foundry) Funktionalität verfügbar und testbar • Automatischer Neustart beim Crash • Skalieren auf mehrere Instanzen • Load Balancing • Blue/Green Deployment • Aggregiertes Logging • Testsuite 48
49. • Im public Betrieb fallen sämtliche Backends weg • Erfordert die Migration von DB & Messaging Migration von lokaler CF Umgebung auf public Liberty App Hosted CF Liberty App Local CF 49
50. Gleicher host/network Liberty Buildpack App DB2 MQ Client Client Eclipse MQ REST Pivotal Cloud Foundry PCF auf Microsoft Azure 50
51. Microsoft Azure Liberty Buildpack App AzureSQL Client Eclipse REST Pivotal Cloud Foundry PCF auf Microsoft Azure 51
52. Azure Service Catalog 52
53. server.xml mit Service Referenzen 53
54. Lessons learned • Migrationsschritt mit “Cloud Dev VM” sehr hilfreich • DB und Messaging Migration kann weitergemacht werden während App migriert wird • Minikube/Minishift als Alternativen • Sehr positive Erfahrungen mit Pivotal Cloud Foundry und Microsoft Azure • Übergang von Dev zu Public quasi über Nacht 54
55. Work in Progress & Lookout 55
56. Zerlegung des Monolithen • Neue Funktionalität wird nicht mehr in den Monolithen gepackt • Zerteilung des Monolithen mit Hilfe des Strangler Patterns ◦ Vorhandene Funktionalität wird in neuem Service abgebildet und damit im Monolithen redundant und ersetzbar gemacht 56 CF Spring „new“ REST Liberty App CF Liberty App‘ Liberty App‘ Nodejs App‘ Spring new Ruby/ Go/ Swift MS‘ New dev Decomposition
57. Q+A 57
58. Besuchen Sie uns am NovaTec Stand - gegenüber von Raum Solar 2! 58
60. Backup 60
61. Persistenz - Datenmigration / GoLive • Migration bei Zero-downtime bei minimaler Last • Write-Lock auf DB2 erzeugt kontrollierbaren App-Fehlerzustand pro Request • Möglichkeit #1 “Offline”: Datenmigration via Migrations-App • Möglichkeit #2 “Online”: linked Databases 61 App @ WAS DB2 Non-Cloud App @ WLP Azure SQL Cloud Schreibzugriff unterbrochen Migrator App
62. Unterschiede beim CF Betrieb • Keine absoluten Dateisystem-basierten Referenzen • Keine Hochkommata 62