Migration eines Java EE Monolithen nach Cloud Foundry auf Azure

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Sprecher & NovaTec Consulting GmbH Matthias Häußler - Consultant @maeddes Thorsten Jakoby - Consultant @jakobyte1024 3

Slide 4

Slide 4 text

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

WAS App DB2 MQ Client Client Client Eclipse SOAP MQ REST Anwendungsumgebung 6

Slide 7

Slide 7 text

● ~ 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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

Anwendung 11

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

Paralleler Branch Neuer “cloud” branch “Alter” master branch Deployment Cloud Deployment Legacy Manual merges der Deltas 16

Slide 17

Slide 17 text

One codebase - many deploys “One and only” master branch Deployment Cloud Deployment Legacy Verschiedene Konfigurationen Deltas in Funktionalität nur bei einem branch 17

Slide 18

Slide 18 text

Liberty App DB2 MQ Client Client Client Eclipse SOAP JMS REST Anwendungsumgebung WAS 18

Slide 19

Slide 19 text

● 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

Slide 20

Slide 20 text

20 Java EE 6 oder 7?

Slide 21

Slide 21 text

21 IBM Migration Tools ● IBM bietet zwei Tools zur Migration ○ IDE Plugin ○ CLI Analyse ● https://developer.ibm.com/wasdev/docs/migration/

Slide 22

Slide 22 text

22 > 8000 notwendige Änderungen Austausch des JPA Providers Überraschende Ergebnisse

Slide 23

Slide 23 text

23 Hilfreiche Matrix

Slide 24

Slide 24 text

24 … Manuelle Erstellung (Java EE 6 & 7) Vom Tool generiert WLP Konfiguration - server.xml

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

Persistenz 27

Slide 28

Slide 28 text

Anforderungen ● Ein relationales “cloud-native” Datenbanksystem verwenden ● Weiterhin JPA und Flyway verwenden ● Automatisches verbinden und migrieren der Datenbank möglich 28

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

Persistenz - AzureSQL ● AzureSQL in Cloudumgebung ○ Skalierung durch Azure ○ Performanzanalyse on-board ● MSSQL-Docker-Container für IDE 31

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Messaging 34

Slide 35

Slide 35 text

Anforderungen 35 ● App soll mit “Cloud-nativen Bordmitteln” kommunizieren ● Kompatibilität und Konnektivität zu Non-Cloud Applikationen bleiben erhalten

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

Platform 39

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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)

Slide 42

Slide 42 text

Cloud Foundry Basics 42 app buildpack cf push app Applications Services container

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

Liberty App DB2 MQ Client Client Client Eclipse SOAP MQ REST Anwendungsumgebung 44

Slide 45

Slide 45 text

Gleicher host/network Liberty Buildpack App DB2 MQ Client Client Eclipse MQ REST Cloud Foundry Cloud Foundry (PCF Dev) als Umgebung 45

Slide 46

Slide 46 text

Anwendung als “self-contained” Artefakt

Slide 47

Slide 47 text

github Cloud Foundry 47 image Liberty Buildpack App Liberty Buildpack Cloud Foundry deployment - cf push

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

● 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

Slide 50

Slide 50 text

Gleicher host/network Liberty Buildpack App DB2 MQ Client Client Eclipse MQ REST Pivotal Cloud Foundry PCF auf Microsoft Azure 50

Slide 51

Slide 51 text

Microsoft Azure Liberty Buildpack App AzureSQL Client Eclipse REST Pivotal Cloud Foundry PCF auf Microsoft Azure 51

Slide 52

Slide 52 text

Azure Service Catalog 52

Slide 53

Slide 53 text

server.xml mit Service Referenzen 53

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

Work in Progress & Lookout 55

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

Q+A 57

Slide 58

Slide 58 text

Besuchen Sie uns am NovaTec Stand - gegenüber von Raum Solar 2! 58

Slide 59

Slide 59 text

Slide 60

Slide 60 text

Backup 60

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

Unterschiede beim CF Betrieb ● Keine absoluten Dateisystem-basierten Referenzen ● Keine Hochkommata 62