Steinzeit war gestern! Wege der Cloud-nativen Evolution.
1 gefällt mir•409 aufrufe
Der Vortrag von Mario-Leander Reimer zur cloud-nativen Evolution beleuchtet die Herausforderungen und Strategien für die Migration bestehender Systeme in die Cloud. Es werden verschiedene Ansätze zur Anwendungsmigration vorgestellt, darunter Ersetzen, Umstellen und Umbauen von Anwendungen, sowie die Implementierung cloud-nativer Designprinzipien. Darüber hinaus betont Reimer die Notwendigkeit automatisierter Tests und kontinuierlicher Integration, um die Migration effizient zu gestalten und die Softwarequalität zu verbessern.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
- 1. Mario-Leander Reimer, QAware GmbH [email protected] Steinzeit war gestern! Wege der Cloud-nativen Evolution. Düsseldorf, 09. Oktober 2018
- 2. Mario-Leander Reimer Principal Software Architect, QAware GmbH Contact Details Mail: [email protected] Twitter: @LeanderReimer Github: https://github.com/lreimer/ 11.10.2018 2 Developer && Architect 20+ years of experience #CloudNativeNerd Open Source Enthusiast Speaker && Author
- 3. Wir gehen in die Cloud! 3
- 4. Gesagt, getan! 4 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
- 5. DISRUPT 5 INDUSTRIALIZE OPEX SAVINGS (automation & utilization) ANTIFRAGILITYHYPERSCALE TRAFFIC, DATA, FEATURES DEVOPS & CONTINUOUS DELIVERY SPEED Cloud
- 6. 6 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) StatefulWebapp, StatefulWebapp, GFv4 Spring MVC, DB A <<System>> OSMC (BDR)
- 7. 7 Lassen sich unsere Bestandssysteme mit vertretbarem Aufwand in Richtung Cloud entwickeln? Containerization 12-Factor App Principles Microservices Cloud-native Apps Monolithic Deployment Traditional Infrastructure
- 8. 8 Lassen sich unsere Bestandssysteme mit vertretbarem Aufwand in Richtung Cloud entwickeln? Containerization 12-Factor App Principles Microservices Cloud-native Apps Monolithic Deployment Traditional Infrastructure
- 9. 9 Lassen sich unsere Bestandssysteme mit vertretbarem Aufwand in Richtung Cloud entwickeln? Containerization 12-Factor App Principles Microservices Continuous Delivery Monolithic Deployment Traditional Infrastructure
- 10. Fakten schaffen. Es braucht eine belastbar Aufwands- und Ressourcenprognose. 10 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
- 11. Beispiel für einen Migration Issue Report von 11
- 12. 12 Ein Migrations-Kochbuch definiert, wo und wie welche Migrations-Maßnahmen umgesetzt werden. Experten-Schätzung Erfahrungen aus PoCs
- 13. Fragebogen: Typische Fragen und ihre Motivation. 13 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?
- 14. Anwendungen können auf fünf verschiedene Wege migriert werden. 14 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.
- 15. Wichtige Design Prinzipien Cloud-nativer Applikationen dienen als Leitplanken für benötigte Umbauten. 15 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.
- 16. 16 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
- 17. Exponentielle Migration für Massen-Migrationen. 17 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
- 18. Exponentielle Migration für Massen-Migrationen. 18 Industrialisierung „Säge schärfen“ • Grundvoraussetzungen schaffen • Know-How im Kernteam aufbauen • Migrations-Tranchen bestimmen • Stabilisatoren (Cookbooks, Halbzeuge, ...) • Katalysatoren (SEU, CI/CD, …)
- 19. Exponentielle Migration für Massen-Migrationen. 19 Massen-Migration • Migration im 2-er Team. • Jedes Migrations-Team unterstützt dann 2 weitere Migrations-Teams • Die Applikationsverantwortlichen migrieren ihr System selbst. (falls möglich)
- 21. 21 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
- 22. 22 Dev Components Ops Components?:1 System Subsystems Components Services Unser Ausgangspunkt DecompositionTrade-Offs Microservices Nanoservices Macroservices Monolith + Flexiblere Skalierung möglich + Runtime Isolation (Crash, Slow-Down, …) + Unabhängige Releases, Deployments,Teams + Bessere Ressourcennutzung − Verteilungsschulden: Latenz − Steigende Infrastruktur Komplexität − SteigendeTroubleshooting Komplexität − Steigende Integration-Komplexität
- 23. 23 „Decomposing the Monolith“: Vorher. Base Runtime (Mule ESB 3.7) Monitoring Finance Adapter Logging Cert Adapter Vehicle Adapter Commercial Adapter Security APRIL Runtime Tracing … Portal Adapter B2I Adapter Session Adapter Log Adapter Score Adapter Legacy Adapter Togglz FASTA Adapter Alle fachlichen Komponenten und Schnittstellen in einer riesigen, gemeinsamen Deployment Einheit Querschnittskomponenten
- 24. Aufgabe: finde die richtigen Sollbruchstellen. 24
- 25. 25 „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
- 26. 90% der Bestandsapplikationen sind Zustandsbehaftet. 100% der Applikationen haben mehr als eine Instanz. 26 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.
- 27. 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. 27https://martinfowler.com/bliki/StranglerApplication.html
- 28. Eine Migrations-Geschichte. Es war einmal … 28 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
- 29. High-Level System Überblick nach dem Umbau. 29 Process MQseries OTP APRIL Payment OpenShift Billing Payment APRIL UI B&P B2ILAAS EAI/SAP Saferpay OSMC
- 31. QAware 31 Wie lassen sich wesentliche Crosscutting Concerns schnell und einfach nachrüsten?
- 32. QAware 32 Wie lassen sich wesentliche Crosscutting Concerns schnell und einfach nachrüsten?
- 33. Option 1) Nachrüsten von Metriken, Health Endpoints, und Resilienz durch Verwendung von OSS Bibliotheken. 33 <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>
- 34. Option 2) Container Orchestrierungsmuster. 34http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html 1. Sidecar Container: Erweitern das Container Verhalten Log Extraction / Reformating (fluentd, logstash) Scheduling (cron, quartz) 2. Ambassador Container: Proxy Communication TLS Tunnel (Stunnel, ghostunnel, Istio) Circuit Breaking (linkerd, Istio) Request Monitoring (linkerd, Istio) 3. Adapter Container: Stellt eine standardisierte Schnittstelle bereit Monitoring (Prometheus) Configuration (ConfigMaps, Secrets, …)
- 35. DevOps, Continuous Integration & Deployment and Feedback is all about People, Processes and Tools. 35
- 36. 36
- 37. 37
- 38. 38
- 39. Software Industrialisierung ist eine Schlüsselanforderung für erfolgreiches DevOps und Continuous Delivery. 39 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
- 40. Veränderte Vorgehen bei Absicherung, Deployment und Betrieb erfordern ein Umdenken und zusätzliche Skills. 40
- 41. 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. 41 Drastisch reduzierte Build-Zeiten für mehr Produktivität und Qualität Migration von Bestandsprojekten mit Augenmaß https://gradle.org/gradle-vs-maven-performance/
- 42. 42 Eine mögliche Continuous Integration & Deployment Pipeline. Andere Projekte, andere Pipelines.
- 43. Die goldenen Zeiten der Test-Pyramide sind vorbei … 43 Anzahl derTests AngenommeneAusführungskosten 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 (?) automatisierter UI-Tests: Langsame Ausführungsgeschwindigkeit Aufwändig in der Umsetzung Fehleranfällig und schlechte Wartbarkeit UnitTests IntegrationTests UI Tests ManuelleTests
- 44. Die Evolution hin zu einem „Test-Haus“. 44 http://www.agilecoachjournal.com/2014-01-28/the-agile-testing-pyramid UnitTests IntegrationTests End-2-EndTests ExploratoryTest Leichtgewichtige Umsetzung als natürlich-sprachliche Test- und Automatisierungs-DSL
- 45. Industrialisierte Migration aller Deployment Artefakte für eine schnelle und einheitliche Containerisierung. 45 Legacy Staging Tool XML Files kompose OpenShift Deployment YAML Files Dockerfile + docker-compose.yml go2cnap Local Development Cloud DeploymentTraditional Deployment
- 46. -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! 46 Since jdk8_131 Extra memory settings GC tuning. Fancy tuning. Diagnostics.
- 47. Lessons Learned
- 48. Viele Bestandssysteme lassen sich mit vertretbarem Aufwand in Richtung Cloud entwickeln. Aber ... 48 … 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!!!
- 49. QAware GmbH München Aschauer Straße 32 81549 München Tel.: +49 (0) 89 23 23 15 – 0 Fax: +49 (0) 89 23 23 15 – 129 github.com/qaware linkedin.com/qaware slideshare.net/qaware twitter.com/qaware xing.com/qaware youtube.com/qawaregmbh