Continuous Lifecycle 2018, Mannheim: Vortrag von Mario-Leander Reimer (@LeanderReimer, Cheftechnologe bei QAware)
=== Dokument bitte herunterladen, falls unscharf! Please download slides if blurred! ===
Abstract:
Jahrzehnte lang haben wir mehr oder weniger erfolgreich monolithische Enterprise Applikationen gebaut. Leider können diese Systeme und deren Betriebsmodelle den hohen Anforderungen moderner Geschäftsmodelle nur noch schwer genügen. Kurze Release-Zyklen, Antifragilität und Hyperscale scheinen unerreichbar zu sein. Was also tun? Muss man diese Systeme alle neu bauen? Das ist sicherlich kein besonders ökonomischer und sinnvoller Weg. Dieser Vortrag zeigt mögliche Wege der Cloud-nativen Evolution von Bestandssystemen und berichtet aus der Praxis.
Steinzeit war gestern! Wege der cloud-nativen Evolution
1. Mario-Leander Reimer, QAware GmbH
mario-leander.reimer@qaware.de
Steinzeit war gestern!
Wege der Cloud-nativen Evolution.
Mannheim, 15. November 2018
2. Mario-Leander Reimer
Cheftechnologe, QAware GmbH
Contact Details
Mail: mario-leander.reimer@qaware.de
Twitter: @LeanderReimer
Github: https://github.com/lreimer/
14.11.2018
2
Developer && Architect
20+ years of experience
#CloudNativeNerd
Open Source Enthusiast
Speaker && Author
3. Safe Harbor Statement
Die in der nun folgenden kleinen Geschichte dargestellten
Personen und geschilderten Ereignisse sind frei erfunden und
so (hoffentlich) nicht passiert. Sollten sie dennoch zutreffend
sein, ist das purer Zufall.
5. Gesagt, getan!
5
Mein Unternehmen
Cloud
Private Cloud
Mein
Unter-
nehmen
Internet
Cloud
Mein Unternehmen
Mein
Unter-
nehmen
Internet
Cloud
Cloud
Internet
Cloud
Cloud
Cloud
Public Cloud
Hybrid Cloud
Multi Cloud
7. A <<System / Plattform>>
IO Business Applications (BDR)
A <<Ext. System>>
Saferpay
A <<System>>
SMTP.MUC
A <<System>>
SOFAK
Berechtigter Dritter (PKW),
Berechtigter Dritter (Motorrad)
A <<System>>
P-CODE (BDR)
A <<Subsystem>>
Tuner APP (BDR)
A <<Subsystem>>
VIN Decoder (BDR)
A <<System>>
ITSM SUITE
OSMC User Security Context
A <<System>>
Integrierte Web-Applikation
B2I Security Context
B2I Security Context
A <<System>>
OSMC (BDR)
H <<System>>
Fahrzeug
H <<System>>
Fahrzeuginterface (PTT)
I <<System>>
LAAS
A <<System>>
AOS (BDR)
A <<Subsystem>>
AOS-TS (BDR)
B2I Security Context
A <<System>>
B2I-UA (BDR)
A <<Ext. System>>
BZAFS
A <<System>>
Group Directory
A <<System>>
APRIL (BDR)
A <<System>>
Integr. Client-Appl.
OSS Tech Security Context
(OSS Client Zertifikat)
A <<System>>
externes System
B2I-UB DB
AOS-TS DB
OSMC DB
AOS DB
P-CODE DB
B2I Security Context
I <<Execution Unit>>
OpenShift CNAP
A <<System>>
Billing Service
A <<System>>
Payment Service
A <<System>>
Process Service
A <<Ext. System>>
ASBC
A <<Ext. System>>
SAP (EAI/TBB)
7
Hyperscale, Antifragilität und Continuous Delivery sind
Treiber für die Evolution von Bestandssystemen.
8. 8
Hyperscale, Antifragilität und Continuous Delivery sind
Treiber für die Evolution von Bestandssystemen.
Stateful Webapp,
Stateful Webapp, GFv4
Spring MVC, DB
A <<System>>
OSMC (BDR)
9. 9
Hyperscale, Antifragilität und Continuous Delivery sind
Treiber für die Evolution von Bestandssystemen.
Liferay Portal
GFv3, Portlets, DB
A <<System>>
AOS (BDR)
Stateful Webapp,
Stateful Webapp, GFv4
Spring MVC, DB
A <<System>>
OSMC (BDR)
10. 10
Hyperscale, Antifragilität und Continuous Delivery sind
Treiber für die Evolution von Bestandssystemen.
Stateless ESB, GFv4
No UI, No Database
A <<System>>
APRIL (BDR)
Liferay Portal
GFv3, Portlets, DB
A <<System>>
AOS (BDR)
Stateful Webapp,
Stateful Webapp, GFv4
Spring MVC, DB
A <<System>>
OSMC (BDR)
11. 11
Lassen sich unsere Bestandssysteme mit vertretbarem
Aufwand in Richtung Cloud entwickeln?
Containerization
12-Factor App Principles
Microservices
Cloud-native Apps
Monolithic Deployment
Traditional Infrastructure
12. 12
Lassen sich unsere Bestandssysteme mit vertretbarem
Aufwand in Richtung Cloud entwickeln?
Containerization
12-Factor App Principles
Microservices
Cloud-native Apps
Monolithic Deployment
Traditional Infrastructure
13. 13
Lassen sich unsere Bestandssysteme mit vertretbarem
Aufwand in Richtung Cloud entwickeln?
Containerization
12-Factor App Principles
Microservices
Continuous Delivery
Monolithic Deployment
Traditional Infrastructure
14. Fakten schaffen. Es braucht eine belastbar Aufwands-
und Ressourcenprognose.
14
Software-Analyse
Statische Analyse mit Windup, …
Architektur Analyse mit S101, …
Fragenkatalog
Welche Komplexität hat das System?
Welche Musterlösung verwendet das System?
Welche Technologien werden verwendet?
Proof of Concepts
Migration von Bibliotheken
Migration verschiedener Apps
Know How
Erfahrung aus anderen Migrationen
Kontenrahmen
Eingespieltes Team
Aufwandsprognosewerkzeug
EAM-Tool
17. Fragebogen: Typische Fragen und ihre Motivation.
17
1. Technology Stack (e.g. OS, appserver, jvm)
2. Benötigte Resourcen (memory, CPU cores)
3. Braucht Storage (local/remote storage, write mode,
data volume)
4. Spezielle Anforderungen (native libs, special
hardware)
5. Inbound und Outbound Protocols (protocol stack,
TLS, multicast, dynamic ports)
6. Ability to Execute (regression/load tests, business
owner, dev knowhow, release cycle, end of life)
7. Client Authentifizierung (e.g. SSO, login, certificates)
• What images to provide?
• How many applications will be hard or
inefficient to schedule? (> 3 GB RAM, > 2
cores)?
• What storage solutions to provide?
• What applications will be hard or impossible
to be containerized?
• Are there any non cloud-friendly protocols?
• How risky is the migration? Is the migration
maybe not required?
• What IAM and security mechanisms haveto
be ported to the cloud?
18. Anwendungen können auf fünf verschiedene Wege
migriert werden.
18
0. Don‘t: Die Anwendung eignet sich nicht für die Cloud. Don‘t migrate!
1. Replace: Anwendungen abmanagen oder durch neue Anwendungen ersetzen.
2. Rehost: Die Anwendung as-is auf neue (virtuelle) Hosts umziehen.
3. Refactor: Die Anwendung möglichst ohne funktionale Änderung so anpassen, dass sie auf
einer Cloud-Plattform (Kubernetes, OpenShift, …) und der darauf verfügbaren Ausführungs-
plattform (Container, OS, JDK, AppServer) läuft.
4. Revise: Die Anwendung so anpassen, dass sie die Möglichkeiten und Vorteile der Cloud-
Plattform möglichst gut ausnutzt. Die wesentlichen Design Prinzipien Cloud-nativer Apps
werden dabei soweit vertretbar berücksichtigt.
5. Rebuild: Anwendung neu bauen oder im großen Stil umbauen. Als Cloud Native Anwendung,
geschnitten in Microservices und API getrieben.
19. Wichtige Design Prinzipien Cloud-nativer Applikationen
dienen als Leitplanken für benötigte Umbauten.
19
Design for Distribution: Containers; Microservices; API getriebene Entwicklung.
Design for Automation: Automatisierung von Dev & Ops Tasks.
Design for Resiliency: Fehlertolerant und selbstheilend.
Design for Elasticity: Skaliert dynamisch und reagiert auf Stimuli.
Design for Performance: Responsive; Concurrent; Ressourcen effizient.
Design for Delivery: Kurze Roundtrips und automatisierte Provisionierung.
Design for Diagnosability: Cluster-weite Logs, Metriken und Traces.
Design for Security: Abgesicherte Endpunkte, API-Gateways, E2E-Encryption.
20. 20
Ein gestuftes Vorgehen macht die Migration planbar, die
technologischen Risiken werden leichter beherrschbar.
Loosely coupled microservices.
Scales dynamically based on load.
Level 3: Cloud Native
Fault tolerant and resilient design.
Metrics and monitoring built-in.
Level 2: Cloud Resilient
Adheres to the 12-factor app principles.
Cloud friendly app server runtime.
Level 1: Cloud Friendly
Executed as self-contained image.
Runs on virtualized HW and file system.
Level 0: Cloud Ready
https://www.opendatacenteralliance.org/docs/architecting_cloud_aware_applications.pdf
21. Exponentielle Migration für Massen-Migrationen.
21
Applikations-Migration
Industrialisierung
„Säge schärfen“
Tranchen
Governance-
Aufwände
1 2 3 4 5 6 7 8 9 10 11
Massen-Migration
Anzahl an gleichzeitig
migrierte Systeme
23. Exponentielle Migration für Massen-Migrationen.
23
Massen-Migration
• Migration im 2-erTeam.
• Jedes Migrations-Team unterstützt dann 2
weitere Migrations-Teams
• Die Applikationsverantwortlichen migrieren
ihr System selbst. (falls möglich)
24. QAware 24
Wie lassen sich wesentliche Crosscutting Concerns
schnell und einfach nachrüsten?
25. QAware 25
Wie lassen sich wesentliche Crosscutting Concerns
schnell und einfach nachrüsten?
26. Option 1) Nachrüsten von Metriken, Health Endpoints,
und Resilienz durch Verwendung von OSS Bibliotheken.
26
<dependencies>
<dependency>
<groupId>io.dropwizard.metrics</groupId>
<artifactId>metrics-core</artifactId>
<version>${metrics.version}</version>
</dependency>
</dependencies>
Verwendung von Dropwizard Metrics für
Metriken und Health Endpoints
Einfache Integration in Enterpise Anwendungen
Definition von Custom Health Checks möglich
Verwendung als Liveness und Readiness Probes
Verwendung von Netflix Hystrix für den
resilienten Aufruf von Fremdsystemen
Einfache Integration in Enterprise Anwendungen
Circuit Breaker und Bulk Heading
Integriert sich nahtlos mit Dropwizard Metrics
<dependencies>
<dependency>
<groupId>com.netflix.hystrix</groupId>
<artifactId>hystrix-core</artifactId>
<version>${hystrix.version}</version>
</dependency>
</dependencies>
29. 29
Components All Along the Software Lifecycle.
DESIGN
Complexity unit
Data integrity unit
Coherent and cohesive
features unit
Decoupled unit
RUN
Release unit
Deployment unit
Runtime unit
(crash, slow-down, access)
Scaling unit
n:1
BUILD
Planning unit
Team assignment unit
Knowledge unit
Development unit
Integration unit
1:1
33. 33
„Decomposing the Monolith“: Nachher.
Base Runtime (Mule ESB 3.7)
Monitoring
B2I
Adapter
Logging
User
Adapter
Portal
Adapter
Integration
Adapter
Security
APRIL AOS Deployment
Tracing
… Base Runtime (Mule ESB 3.7)
Monitoring Logging
Commercial
Adapter
Security
APRIL Commercial
Deployment
Tracing
Base Runtime (Mule ESB 3.7)
Monitoring Logging
Vehicle
Adapter
Security
APRIL Vehicle
Deployment
Tracing
Base Runtime (Mule ESB 3.7)
Monitoring Logging
Finance
Adapter
Security
APRIL Finance
Deployment
Tracing
Base Runtime (Mule ESB 3.7)
Monitoring
Score
Adapter
Logging
FASTA
Adapter
Cert
Adapter
OSS Legacy
Adapter
Security
APRIL Client Deployment
Tracing
…
Ein Deployment pro
System-Context
34. 90% der Bestandsapplikationen sind Zustandsbehaftet.
100% der Applikationen haben mehr als eine Instanz.
34
Session Stickyness:
Funktioniert nicht in der Cloud!
Ist, je nach Plattform, proprietär und funktioniert anders als bisher.
Session Persistence:
Über die Datenbank: möglicherweise hoher Einfluss auf die Performance.
Per Cookie: möglicherweise hoher Einfluss auf die Performance.
Session Synchronization:
Kein Multicast-Support in der Cloud!
Application Server: funktioniert oft nicht. Benötigt häufig Multicast oder statische Host Liste.
In-memory Data Grids:
Hazelcast – ($$$ for TLS)
Apache Ignite. Done.
35. Transform: ein Teil der Bestandsfunktionalität wird extrahiert
und in ein neues, modernes System eingebaut.
Coexist: beide Systeme koexistieren für eine Zeit. Aufrufe
der alten Funktionalität werden umgeleitet.
Eliminate: alte Funktionalität wird aus dem Bestandssystem
entfernt sobald diese nicht mehr genutzt wird.
Eignet sich besonders für Web - oder API-Monolithen.
Problematisch bei Non-RESTful URL Strukturen.
Schrittweise Evolution und Cloud-nativer Neubau mit
dem Strangler Pattern.
35https://martinfowler.com/bliki/StranglerApplication.html
36. Eine Migrations-Geschichte. Es war einmal …
36
OSMCOTP
Als System möchte ich für meine
registrierten Benutzer die Bezahlung
per hinterlegter Kreditkarte und die
Rechnungsstellung in regelmäßigen
Abständen in Auftrag geben und
überwachen können.
• Als System binde ich bereits eine Schnittstelle
zur Bezahlung per Kreditkarte an
• Als System binde ich bereits eine (sehr alte)
Schnittstelle zur Rechnungsstellung an
• Aber ich besitze derzeit keine Logik für einen
Post-Payment (auf Rechnung) Prozess
37. High-Level System Überblick nach dem Umbau.
37
Process
MQseries
OTP
APRIL
Payment
OpenShift
Billing
Payment
APRIL
UI
B&P
B2ILAAS EAI/SAP
Saferpay
OSMC
40. Veränderte Vorgehen bei Absicherung, Deployment und
Betrieb erfordern ein Umdenken und zusätzliche Skills.
40
41. Software Industrialisierung ist eine Schlüsselanforderung
für erfolgreiches DevOps und Continuous Delivery.
41
Hoher Automatisierungsgrad von arbeits-
intensiven und wiederkehrenden Tasks
Bessere Software-Qualität durch eine
abgestimmte Tool-Chain
Mehr Produktivität und Zufriedenheit der
Entwickler-Teams
Bessere Kosten-Effizienz und
Wettbewerbsfähigkeit
Everything-as-code
42. Nutzung einer Agile Delivery Tool Chain
Migration aller Repositories von SVN nach Git mit
voller Historie innerhalb 1 Woche
Anpassung und Migration aller Jenkins Build-Jobs
auf neue Build Infrastruktur
More improvements to come …
Durch die Evolution der Build Toolchain werden schnelle
Roundtrips und effiziente Feature Entwicklung möglich.
42
Drastisch reduzierte Build-Zeiten für mehr
Produktivität und Qualität
Migration von Bestandsprojekten mit Augenmaß
https://gradle.org/gradle-vs-maven-performance/
47. Evolution der Test-Pyramide für ein agiles Vorgehen.
47
http://www.agilecoachjournal.com/2014-01-28/the-agile-testing-pyramid
48. Evolution der Test-Pyramide für ein agiles Vorgehen.
48
http://www.agilecoachjournal.com/2014-01-28/the-agile-testing-pyramid
49. ManuelleTests
Hoher Testautomatisierung auf den
unteren Ebenen ist häufig vorhanden.
Hoher Anteil an manuellen Test auf den
oberen Ebenen mündet in langen,
und aufwändigen Absicherungs-Zyklen
Testautomatisierung auf den oberen
Ebenen ist
gut für Regressionstests geeignet
reduziert manuelle Test-Aufwände
Mythen (?) der Test-Pyramide:
Langsame Ausführungsgeschwindigkeit
Aufwändig in der Umsetzung
Fehleranfällig und schlechte Wartbarkeit
Evolution der Test-Pyramide für ein agiles Vorgehen.
49
UnitTests
Acceptance
Tests
UI
Tests
Anzahl derTests
AngenommeneAusführungskosten
50. Evolution hin zu einem „Test-Haus“ ist möglich.
50
Unit Tests
Acceptance Tests
Load Tests
Schnittstellen Tests
Security Tests
Infrastructure Tests
End-2-End Tests
Exploratory Test
Leichtgewichtige Umsetzung als natürlich-sprachliche
Test- und Automatisierungs-DSL
51. Industrialisierte Migration aller Deployment Artefakte für
eine schnelle und einheitliche Containerisierung.
51
Legacy Staging Tool
XML Files
kompose
OpenShift Deployment
YAML Files
Dockerfile +
docker-compose.yml
go2cnap
Local Development Cloud DeploymentTraditional Deployment
53. resources:
# CPU is specified in units of cores
# Memory is specified in units of bytes
# required resources for a Pod to be scheduled and started
requests:
memory: "128Mi"
cpu: "1"
# the Pod will be restarted if limits are exceeded
# so be careful not to set them too low!
limits:
memory: "1Gi"
cpu: "2"
Define Resource Constraints Carefully.
53
54. -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap
-XX:ParallelGCThreads=2 -XX:ParallelGCThreads=2
-server
-Xmx320m -Xss256k -XX:MaxMetaspaceSize=160m -XX:CompressedClassSpaceSize=32m
# Do not use G1GC?
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:NewRatio=1 -XX:+CMSParallelRemarkEnabled
# Use for small heaps on 64-bit VMs
-XX:+AggressiveOpts -XX:+UseCompressedOops -XX:+UseCompressedClassPointers
# optional
-XX:+UnlockDiagnosticVMOptions -XX:NativeMemoryTracking=summary
Tame and Tune your JVM for Cloud Infastructure!
54
Since jdk8_131
Extra memory settings
GC tuning.
Fancy tuning.
Diagnostics.
56. Viele Bestandssysteme lassen sich mit vertretbarem
Aufwand in Richtung Cloud entwickeln. Aber ...
56
… alles mit Augenmaß.
Kein naiiver „as-is into Containers“ Ansatz!
Nicht auf biegen und brechen, egal ob das System geeignet ist oder nicht!
Nicht jeder Infrastruktur-Baustein muss gleich mit in die Cloud!
Während der Migrationsphase wird es unerwartete Inkompatibilitäten geben, die sicherlich lösbar sind.
Test the Waters! Frühe Proof of Concepts helfen enorm.
Ein Invest in CI/CD Umgebungen und Prozesse sowie automatisierte Tests ist absolut notwendig.
Es ist ein Umdenken auf allen Ebenen notwendig. IT, Product Owner, Tester, …
And don‘t forget about Security!!!