From Zero to still Zero: Die schönsten Fehler auf dem Weg in die Cloud
0 gefällt mir86 aufrufe
Das Dokument diskutiert die Vorteile und Herausforderungen des Cloud-Computing, einschließlich Agilität, Plattformservices und Kostenmodelle aus Kundensicht. Es beleuchtet verschiedene Ansätze zur Cloud-Migration wie 'Lift & Shift', Vendor-Lock-In und ClickOps, wobei Vorteile wie einfacheres Management und Skalierbarkeit betont werden. Außerdem werden Risiken wie Kostenüberlauf und begrenzte Flexibilität bei der Portabilität hervorgehoben.
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die Cloud
- 1. From Zero to Hero still Zero X Die schönsten Fehler auf dem Weg in die Cloud Lars Röwekamp | @mobileLarson
- 2. @mobileLarson CIO New Technologies OPEN KNOWLEDGE Lars Röwekamp (Architecture, Microservices, Cloud, AI & ML)
- 3. Warum Cloud?
- 4. aktive Nutzer Planer/Diskutierer (noch) kein Thema Cloud Monitor (Bitcom Research, 2021, https://www.bitkom.org/Presse/Presseinformation/Drei-von-vier-Unternehmen-nutzen-Cloud-Computing) 15% 82%
- 5. From idea to App The biggest advantage of a cloud(-native) architecture is that it takes you from idea to app in the quickest possible time. “ (Pavan Belagatti, Groth Marketing Manager, jfrog)
- 6. Customer Survey “Welche Mehrwerte erhoffen sie sich von der Cloud?“
- 7. Cloud-Mehrwerte* • Top 1: Agilität *aus Kundensicht
- 8. Cloud-Mehrwerte* • Top 1: Agilität • Top 2: Plattformservices *aus Kundensicht
- 9. Cloud-Mehrwerte* • Top 1: Agilität • Top 2: Plattformservices • Top 3: Kostenmodelle *aus Kundensicht
- 10. Cloud-Mehrwerte* • Top 1: Agilität • Top 2: Plattformservices • Top 3: Kostenmodelle • Top 4: Innovationen *aus Kundensicht
- 11. I promise! (Amazon, Google, Microsoft, IBM…)
- 12. Die Cloud-Versprechen 1. Software-as-a-Service 2. Virtualization 3. Pay-per-Use 4. High Availability 5. Scale-Up / Scale-Out 6. IaaS, PaaS, BaaS, SaaS
- 13. Die Cloud-Versprechen 1. einfacheres Management 2. schnellere Releases 3. verbesserte Kosteneffizienz 4. mehr Zuverlässigkeit/Sicherheit 5. beliebige Skalierbarkeit 6. besseres Kundenerlebnis
- 14. Die Cloud-Versprechen 1. einfacheres Management 2. schnellere Releases 3. verbesserte Kosteneffizienz 4. mehr Zuverlässigkeit/Sicherheit 5. beliebige Skalierbarkeit 6. besseres Kundenerlebnis BTW: kein Vendor-Lockin* * Cloud-native „done right“ * Cloud-native „done right“
- 15. „What could possibly go wrong?“ Cloud? Yeah! (Famous last words!)
- 16. Road to the Cloud Running applications on the cloud is not a binary decision. You don‘t just move to the cloud and call it a day. “ (Paul Fremantle, VP Product Engineering at Weaveworks)
- 17. „Es könnte alles so einfach sein …“ (… isses aber nich!)
- 18. Lift & Shift Für den Anfang gut, aber auf Dauer auch gut genug? 01
- 19. myApp myApp myApp App Server App Server App Server PRODUCTION on prem Self-Managed Load Balancer myFS myMQ myDB
- 20. myApp myApp myApp App Server App Server App Server PRODUCTION on prem INTEGRATION* Self-Managed Load Balancer *same but different myFS myMQ myDB
- 21. „cool“ API Web Content v1.3 v2.1 DEV Team
- 22. „cool“ API Web Content v1.3 v2.1 NEW NEW DEV Team Release
- 25. v2.0 v2.2 „Let‘s pray!“ „cool“ API v2.0 Web Content v2.2 OPS „Team“ Release aka Dooms-Day
- 26. v2.0 v2.2 v2.0.hfr „Let‘s pray!“ „And do some hotfixes!“ „cool“ API v2.0 Web Content v2.2 Release aka Dooms-Day + X
- 28. Lift & Shift Superpower „Entsorgen der eigenen Infrastruktur.“ 1. Nutzen von Cloud Servern 2. Schnelle und einfache Provisionierung 3. An der Anwendung keine Änderungen Keine große Umgewöhnung
- 29. myApp myApp myApp App Server App Server App Server PRODUCTION on prem Self-Managed Load Balancer myFS myMQ myDB
- 30. myApp myApp myApp EC2 Instance EC2 Instance EC2 Instance Routing Load Balancer myDB EC2 Instance myFS EC2 Instance myMQ EC2 Instance PRODUCTION
- 31. myApp myApp myApp EC2 Instance EC2 Instance EC2 Instance Routing Load Balancer myDB EC2 Instance myFS EC2 Instance myMQ EC2 Instance PRODUCTION
- 32. List & Shift Lift & Shift Cloud-Versprechen 1. einfacheres Management 2. schnellere Releases 3. verbesserte Kosteneffizienz 4. mehr Zuverlässigkeit/Sicherheit 5. beliebige Skalierbarkeit 6. besseres Kundenerlebnis
- 33. Lift & Shift Limitations „Cloud? Auch nur Server – halt woanders.“ 1. Kaum (Cloud-)Mehrwerte gehoben 2. In der Regel teurer als on-premise 3. Performance / Latency / Security Risiko* 4. Mainframe Migration nicht möglich *fehlendes Verständnis für die Cloud
- 34. myApp myApp myApp EC2 Instance EC2 Instance EC2 Instance Routing PROD Load Balancer myDB EC2 Instance myFS EC2 Instance myMQ EC2 Instance WHY ME
- 35. myApp myApp myApp EC2 Instance EC2 Instance EC2 Instance Routing PROD Load Balancer Queue RDBMS File
- 36. myApp myApp myApp EC2 Instance EC2 Instance EC2 Instance Routing PROD Load Balancer noSQL Queue RDBMS File Storage Archive Managed Services • Auto-Backup / -Restore • Object / Data Versioning • Security Patches • Availabily Zones • Region Replica • Standby Instances • Integrated Security • Integrated Monitoring • Integrated Eventing • Flexible Sizing* • Pay-per-Use* • Spot Instances* * depends
- 37. List & Shift Lift & Shift Cloud-Versprechen 1. einfacheres Management 2. schnellere Releases 3. verbesserte Kosteneffizienz 4. mehr Zuverlässigkeit/Sicherheit 5. beliebige Skalierbarkeit 6. besseres Kundenerlebnis
- 38. Lift & Shift & Managed Services Cloud-Versprechen 1. einfacheres Management 2. schnellere Releases 3. verbesserte Kosteneffizienz 4. mehr Zuverlässigkeit/Sicherheit 5. beliebige Skalierbarkeit 6. besseres Kundenerlebnis
- 39. Vendor Lock-in Ich will dich lieben, achten und ehren. in guten und in schlechten Zeiten. 02
- 40. Vendor Lock-in aka „Best Friends 4ever“ 200+ Services 2000+ Features
- 41. Vendor Lock-in Superpower „Alles aus einer Hand.“ 1. Hoher Grad an Integration 2. Full-Service Component Management 3. Gutes Preis-/Leistungsverhältnis 4. No more DIY ;-)
- 42. myApp myApp myApp EC2 Instance EC2 Instance EC2 Instance Routing PROD Load Balancer noSQL Queue RDBMS File Storage Archive
- 43. myApp myApp myApp EC2 Instance EC2 Instance EC2 Instance Routing PROD Load Balancer noSQL Queue RDBMS File Storage Archive „Automatische Bereitstellung & Skalierung?“ Kein Problem, da haben wir einen Cloud Service für!“
- 44. AWS App Runner Service Elastic Container Service Elastic Kubernetes Service low high Level of Integration & Ease of Use
- 45. AWS App Runner Service Elastic Container Service Elastic Kubernetes Service Level of „Cloud Native“ high low low high Level of Integration & Ease of Use
- 46. AWS App Runner Service Elastic Container Service Elastic Kubernetes Service Level of „Cloud Native“ high low low high Level of Integration & Ease of Use
- 48. AWS App Runner Source: https://aws.amazon.com/de/apprunner/
- 49. myApp myApp myApp EC2 Instance EC2 Instance EC2 Instance Routing PROD Load Balancer noSQL Queue RDBMS File Storage Archive Ausgangsbasis
- 50. myApp myApp myApp Routing Backing Services PROD noSQL Queue RDBMS File Storage Archive Load Balancer AWS App Runner Zielbild
- 51. DEVOPS Elastic Container Registry AWS App Runner Service Source Deployment Mode Min / Max Scaling Networking / Ports Monitoring Health Checks Docker Image App Runner Service: Scaling, Security, Network at Deployment
- 52. DEVOPS AWS App Runner App Runner Service: Scaling, Security, Network API v1.0 Scale in / out AWS Backing Services at Runtime
- 53. DEVOPS AWS App Runner App Runner Service: Monitoring (e.g. via CloudWatch) API v1.0 Service Status, Active Instances CPU & Memory Utilization, User Actions … CloudWatch Logs Alarm Synthetics Rules at Runtime Health: Container, App Metrics: Cpu, Memory
- 54. DEVOPS AWS App Runner App Runner Service: Monitoring (e.g. via CloudWatch) API v1.0 Service Status, Active Instances CPU & Memory Utilization, User Actions … Health: Container, App Metrics: Cpu, Memory myHealth: App Components myMetrics: Functional, Business CloudWatch Logs Alarm Synthetics Rules at Runtime
- 55. App Runner in Action:
- 56. myApp myApp myApp Routing Backing Services PROD noSQL Queue RDBMS File Storage Archive Load Balancer AWS App Runner
- 57. Availability Zone C myApp myApp myApp Routing Backing Services PROD noSQL Queue RDBMS File Storage Archive Load Balancer Availability Zone A Availability Zone B Ach ja, ich hätte gerne noch … AWS App Runner
- 58. Availability Zone C myApp myApp myApp Routing Backing Services PROD noSQL Queue RDBMS File Storage Archive Load Balancer Availability Zone A Availability Zone B appX appX appX Ach ja, ich hätte gerne noch … AWS App Runner
- 59. Availability Zone C myApp myApp myApp Routing Backing Services PROD noSQL Queue RDBMS File Storage Archive Load Balancer Availability Zone A Availability Zone B appX appX appX OUT OF FLEXIBILTY ERROR AWS App Runner
- 60. Vendor Lock-in Limitation „Wie war das mit dem ewig binden?“ 1. Kaum bis keine Portierbarkeit / Flexibilität 2. Häufig proprietäres Wissen / Format 3. Abhängig von Support Cycles / End-of-Life Wechsel ist möglich und oft wenig aufwendig, aber der Zeitpunkt ist nicht selbstbestimmt!
- 61. Availability Zone C myApp myApp myApp Routing Backing Services PROD noSQL Queue RDBMS File Storage Archive Load Balancer Availability Zone A Availability Zone B appX appX appX WHAT NOW AWS App Runner
- 62. AWS App Runner Service Elastic Container Service Elastic Kubernetes Service Level of „Cloud Native“ high low low high Level of Integration & Ease of Use
- 63. AWS App Runner Service Elastic Container Service Elastic Kubernetes Service Level of „Cloud Native“ high low low high Level of Integration & Ease of Use
- 64. AWS App Runner Service Elastic Container Service Elastic Kubernetes Service Level of „Cloud Native“ high low low high Level of Integration & Ease of Use
- 65. myApp myApp myApp Routing Backing Services PROD noSQL Queue RDBMS File Storage Archive Load Balancer AWS App Runner
- 66. Availability Zone C myApp myApp myApp Routing Backing Services PROD noSQL Queue RDBMS File Storage Archive Availability Zone A Availability Zone B appX appX appX Elastic Kubernetes Service ALB Controller Kubernetes à la AWS aka managed
- 67. Vendor Lock-in Cloud-Versprechen 1. einfacheres Management 2. schnellere Releases 3. verbesserte Kosteneffizienz 4. mehr Zuverlässigkeit/Sicherheit 5. beliebige Skalierbarkeit 6. besseres Kundenerlebnis
- 68. Vendor Lock-in mit Verstand Cloud-Versprechen 1. einfacheres Management 2. schnellere Releases 3. verbesserte Kosteneffizienz 4. mehr Zuverlässigkeit/Sicherheit 5. beliebige Skalierbarkeit 6. besseres Kundenerlebnis
- 69. ClickOps Die Web Console, aka des Cloud Admins bester Freund. 03
- 70. ClickOps aka „Wie geht das?“ AWS Cloud Availability Zone 1 VPC Public subnet NAT gateway Private subnet Auto Scaling group Bastion host Availability Zone 2 Public subnet NAT gateway Private subnet Availability Zone 3 Public subnet NAT gateway Private subnet Amazon EKS Kubernetes nodes Kubernetes nodes Kubernetes nodes Auto Scaling group Source: https://github.com/aws-ia/cloudformation-base-eks
- 71. ClickOps Superpower „Nur einen Klick entfernt.“ 1. Anlegen / Ändern via Wizards 2. Kein Stress mit Rollen & Rechten 3. Vereinfachung der Provisionierung Gut für den Aufbau von Verständnis / Wissen
- 72. ClickOps aka „Wie geht das?“
- 73. ClickOps aka „Wie geht das?“
- 74. ClickOps aka „Wie geht das?“
- 75. ClickOps aka „Wie geht das?“
- 76. ClickOps aka „Wie geht das?“
- 77. ClickOps Limitation „Alles ganz einfach, aber …“ 1. Grenzen der Reproduzierbarkeit 2. Grenzen der Wiederverwendung 3. Grenzen der Versionierung 4. Grenzen der Testbarkeit
- 78. AWS Cloud Availability Zone 1 VPC Public subnet NAT gateway Private subnet Auto Scaling group Bastion host Availability Zone 2 Public subnet NAT gateway Private subnet Availability Zone 3 Public subnet NAT gateway Private subnet Amazon EKS Kubernetes nodes Kubernetes nodes Kubernetes nodes Auto Scaling group Source: https://github.com/aws-ia/cloudformation-base-eks CLI & IaC „Sag mir, was du willst!“
- 79. deklarative Beschreibung des Zielbilds CloudFormation IaC Template CLI & IaC „Sag mir, was du willst!“
- 80. 1. write template(s) 2. create stack 3. detect drift 4. update stack CLI & IaC „Sag mir, was du willst!“ deklarative Beschreibung des Zielbilds
- 81. IaC „Sag mir, was du willst!“ deklarative Beschreibung des Zielbilds 1. write template(s) 2. create stack 3. detect drift 4. update stack PANIK! Vendor Lock-in!
- 82. deklarative Beschreibung des Zielbilds Terraform IaC Template CLI & IaC „Sag mir, was du willst!“
- 83. 1. terraform init 2. terraform plan 3. terraform apply 4. terraform destroy deklarative Beschreibung des Zielbilds CLI & IaC „Sag mir, was du willst!“
- 84. 1. terraform init 2. terraform plan 3. terraform apply 4. terraform destroy deklarative Beschreibung des Zielbilds CLI & IaC „Sag mir, was du willst!“ „MOI?“ Na, dann vielen Dank!
- 85. Shared Responsibility Model Security Customer Data Platform, Applications, Identity & Access Management Operating System, Network & Firewall Configuration Client-side Data Encryption & Data Integrity Authentication Server-side Encryption (File System an/or Data) Network Traffic Protection (Encryption/Integrity/Identity) Customer Responsibility for security „in“ the cloud Application Development Team Compute Storage Database Networking Edge Locations Regions Availability Zones AWS Responsibility for security „of“ the cloud Cloud Service Provider AWS Global Infrastructure
- 86. Shared Responsibility Model Security Acct Mgmt AMI Bakery 3rd Party Vendor Mgmt Security & GRC Framework Monitoring & Logging Framework Client PaaS Responsibility for security „in“ the cloud platform Cloud Platform Team Customer Data Platform, Applications, Identity & Access Management Operating System, Network & Firewall Configuration Client-side Data Encryption & Data Integrity Authentication Server-side Encryption (File System an/or Data) Network Traffic Protection (Encryption/Integrity/Identity) Customer Responsibility for security „in“ the cloud Application Development Team Compute Storage Database Networking Edge Locations Regions Availability Zones AWS Responsibility for security „of“ the cloud Cloud Service Provider AWS Global Infrastructure
- 87. ClickOps Cloud-Versprechen 1. einfacheres Management 2. schnellere Releases 3. verbesserte Kosteneffizienz 4. mehr Zuverlässigkeit/Sicherheit 5. beliebige Skalierbarkeit 6. besseres Kundenerlebnis
- 88. ClickOps als Ausgangsbasis für IaC* Cloud-Versprechen 1. einfacheres Management 2. schnellere Releases 3. verbesserte Kosteneffizienz 4. mehr Zuverlässigkeit/Sicherheit 5. beliebige Skalierbarkeit 6. besseres Kundenerlebnis * und Platform Team
- 89. NCRS* Die Zeit der „eh da“ Mentalität ist vorbei, es sei denn du hast viel, sehr viel Geld. 04 *Never Change a Running System
- 90. NCRS* Superpower „Wat löppt, dat löppt.“ 1. Ressourcen sind einfach provisioniert 2. Rollen / Rechte sind schnell vergeben 3. ClickOps kompatibel *Never Change a Running System
- 91. Source: https://www.ciodive.com/news/with-the-cloud-comes-a-side-effect-cost-overrun NCRS-Denke aka „Zeit ist Geld“
- 92. NCRS-Denke aka „Zeit ist Geld“
- 93. Source: https://www.webapper.com/aws-cost-horror-stories/ NCRS-Denke aka „Zeit ist Geld“
- 94. NCRS Limitation „Das ist aber ganz schön teuer!“ 1. Verlagerung des Dev-Lifecycles 2. gefährliches Halbwissen 3. Missachtung des PoLP* 4. fehlende Kostenoptimierung *Principle of Least Privilege
- 95. Cost Optimization Step 1: Architect for cost efficency aka „Pay for what you think you need.“ Step 2: Optimize usage cost aka „Pay for what you realy use.“ Step 3: Take advantage of benefits over time aka „Pay for what you really need.“ Step-by-Step Ansatz
- 96. Cost Optimization Am Beispiel von EC2 Instanzen On-Demand Instances: • Pay-as-you-go auf Basis von angefangenen Stunden* • vorheriges Commitment nicht notwendig *bei einigen Systemen auch pro angefangener Minute
- 97. Cost Optimization Am Beispiel von EC2 Instanzen Reserved Instances: • Up-front-Fee auf Basis des Commitments • Pay-as-you-go zu günstigeren Preisen auf Basis von angefangenen Stunden* • vorheriges Commitment für ein oder drei Jahre notwendig • Marketplace für kürzere Commitments • 10% Preisvorteil bei einem Commitment auf min. 1200 Stunden / Jahr • 30% - 60% Preisvorteil bei einem Commitment auf ein bis drei Jahre
- 98. Cost Optimization Am Beispiel von EC2 Instanzen Spot Instances: • Pay-what-you-want für „freie“ Kapazitäten • Instanz läuft, wenn Bet-Preis den Spot-Preis übersteigt • Bei Verfügbarkeit extremes Sparpotential • 40% - 60% Preisvorteil bei Spot Blocks von 2-6 Stunden • bis zu 85% Preisvorteil bei echten Spots mit 2 Minuten „Warnzeit“
- 99. Cost Optimization Am Beispiel von EC2 Instanzen Real-Life Szenario: • RIs für planbare / bekannte Workload • Autoscale-Groups für den Rest • Spot Instances, wenn möglich • On-Demand Instances, alternativ Reserved Spot On-Demand
- 100. Cost Optimization Am Beispiel von S3 Object Store On-Demand: • flexibler Object Store • Zugriff im Millisekundenbereich • automatische Object Versionierung • beliebig on-demand skalierbar • 99,99% Verfügbarkeit • 99,999999999% Zuverlässigkeit (Durability)
- 101. Cost Optimization Am Beispiel von S3 Object Store Reduced Redundancy: • alles wie bei „on-demand“, außer • 99.99% Zuverlässigkeit (Durability) • einer statt zwei fehlertollerante Standorte • einige wenige % Preisvorteil
- 102. Cost Optimization Am Beispiel von S3 Object Store Infrequent Access: • alles wie bei „on-demand“, außer … • weniger als zwei Zugriffe je Data / Monat • bis zu 50% Preisvorteil bei Zugriff in Millisekunden
- 103. Cost Optimization Am Beispiel von S3 Object Store Glacier: • alles wie bei „on-demand“, außer … • verlängerte Zugriffszeit von 1 Minute bis 12 Stunden* • bis zu 65% Preisvorteil bei Minuten • bis zu 95% Preisvorteil bei Stunden *für Archivierung, Long-Term Backups und alte Daten
- 104. NCHARS-Denke Cloud-Versprechen 1. einfacheres Management 2. schnellere Releases 3. verbesserte Kosteneffizienz 4. mehr Zuverlässigkeit/Sicherheit 5. beliebige Skalierbarkeit 6. besseres Kundenerlebnis
- 105. NCHARS-Denke mit Plan Cloud-Versprechen 1. einfacheres Management 2. schnellere Releases 3. verbesserte Kosteneffizienz 4. mehr Zuverlässigkeit/Sicherheit 5. beliebige Skalierbarkeit 6. besseres Kundenerlebnis
- 106. Architektur Kann ich meinen geliebten Multi-Tier Monolithen auch in der Cloud sinnvoll nutzen? 05
- 107. myApp myApp myApp Routing Backing Services PROD noSQL Queue RDBMS File Storage Archive Architektur aka „EIN-fach einfach“ ALB Controller Elastic Kubernetes Service
- 108. Routing Backing Services PROD noSQL Queue RDBMS File Storage Archive Architektur aka „EIN-fach einfach“ ALB Controller Elastic Kubernetes Service myApp
- 109. Architektur Superpower „Der Multi-Tier Monolith: EIN-fach einfach!“ 1. einfach in der Entwicklung 2. einfach im Testing 3. einfach im Deployment 4. einfach im Monitoring 5. einfach im Debugging
- 110. Systems for the Cloud For systems to behave well on the cloud, they need to be written for the cloud.* “ * Applications vs. Software-as-a-Service (Paul Fremantle, VP Product Engineering at Weaveworks)
- 112. Eine Codebase Explizite Abhängigkeiten Konfiguration via EnvVars Unterstützende Dienste Build, Release, Run Stateless Prozesse Bindung an Ports Nebenläufigkeit Elastizität & Verfügbarkeit Dev-Prod Vergleichbarkeit Logs als Streams Admin-Prozesse VII. VIII. IX. X. XI. XII. I. II. III. IV. V. VI.
- 113. Eine Codebase Explizite Abhängigkeiten Konfiguration via EnvVars Unterstützende Dienste Build, Release, Run Stateless Prozesse Bindung an Ports Nebenläufigkeit Elastizität & Verfügbarkeit Dev-Prod Vergleichbarkeit Logs als Streams Admin-Prozesse VII. VIII. IX. X. XI. XII. I. II. III. IV. V. VI. APP DESIGN MANAGE BUILD & RELEASE
- 114. Architektur Limitation „Der Multi-Tier Monolith: EIN-fach zu einfach!“ 1. single Build - & Deployment Unit 2. starre Kopplung von Komponenten 3. Skalierung via „all-or-nothing“ 4. meist kein API-first Design
- 115. Routing Queue Backing Services File Storage Archive RDBMS noSQL PROD ALB Controller myApp myApp myApp Availability Zone A Availability Zone B Availability Zone C Elastic Kubernetes Service Architektur aka „EIN-fach zu einfach“ No SaaS Exception
- 116. Routing Queue Backing Services File Storage Archive RDBMS noSQL PROD ALB Controller Availability Zone A Availability Zone B Availability Zone C Elastic Kubernetes Service Architektur aka „Software-as-a-Service“ MS MS MS MS MS MS MS
- 117. Routing Queue Backing Services File Storage Archive RDBMS noSQL PROD ALB Controller Availability Zone A Availability Zone B Availability Zone C Elastic Kubernetes Service Architektur aka „Software-as-a-Service“ MS MS MS MS MS MS MS API Gateway API API API
- 118. Routing Backing Services File Storage Archive RDBMS noSQL PROD ALB Controller Availability Zone A Availability Zone B Availability Zone C Elastic Kubernetes Service Architektur aka „Software-as-a-Service“ MS MS MS MS MS MS MS API Gateway API API API EventBridge Domain Events Infra & Domain Events Infra Events
- 119. Architecture Cloud-Versprechen 1. einfacheres Management 2. schnellere Releases 3. verbesserte Kosteneffizienz 4. mehr Zuverlässigkeit/Sicherheit 5. beliebige Skalierbarkeit 6. besseres Kundenerlebnis
- 120. Architecture gemäß 12-Factor App Cloud-Versprechen 1. einfacheres Management 2. schnellere Releases 3. verbesserte Kosteneffizienz 4. mehr Zuverlässigkeit/Sicherheit 5. beliebige Skalierbarkeit 6. besseres Kundenerlebnis
- 121. „How to do it right?“ Cloud? Yeah!
- 122. myApp myApp myApp App Server App Server App Server PRODUCTION on prem Self-Managed Load Balancer myFS myMQ myDB On-Premise No Cloud / DIY
- 123. myApp myApp myApp EC2 Instance EC2 Instance EC2 Instance Routing PROD Load Balancer noSQL Queue RDBMS File Storage Archive Lift & Shift Managed Base Services
- 124. myApp myApp myApp Routing Backing Services PROD noSQL Queue RDBMS File Storage Archive Load Balancer AWS App Runner Vendor All-In Managed Extended Services
- 125. myApp myApp myApp Routing Backing Services PROD noSQL Queue RDBMS File Storage Archive ALB Controller Elastic Kubernetes Service Vendor Light Managed „CN“ Services
- 126. Routing Backing Services File Storage Archive RDBMS noSQL PROD ALB Controller Availability Zone A Availability Zone B Availability Zone C MS MS MS MS MS MS MS API Gateway API API API EventBridge Domain Events Infra & Domain Events Infra Events Elastic Kubernetes Service SaaS Architecture Access via APIs Modularization via Services Communication via Events
- 127. Routing Backing Services File Storage Archive RDBMS noSQL PROD ALB Controller Availability Zone A Availability Zone B Availability Zone C EKS MS MS MS MS MS MS MS API Gateway API API API EventBridge Infra Events myApp myApp Common Code Base Declarative API CI/CD Monitorring Components self healing Users IAM Cert Security Domain Events Infra & Domain Events Platform Team Cloud Templates Cloud Governance Common Security Common Observability CI/CD via IaC & CLI
- 128. Cloud all-in Cloud-native Architecture Road to the Cloud Cloud DevOps für reproduzierbare Bereitstellung Die ersten Schritte Orientierung via Lift & Shift Plattform Mgmt. Monitoring, Resilience Extended Services für vereinfachte Bereitstellung Managed Services verstehen und nutzen
- 129. (M)ein Fazit zur Cloud …
- 130. (M)ein Fazit zur Cloud Cloud ist mehr als nur Technologie Cloud ist auch • Architektur • Vorgehen • Organisation
- 131. Cloud braucht Mut zur Veränderung …
- 132. Mut und Willen zur Veränderung System-Design • fachliches Splitten der Monolithen • fachliches Splitten der Daten • Einführung von Containerisierung • leichtgewichtige Prozesse* *Choreographie wenn möglich, Orchestrierung wenn nötig
- 133. Mut und Willen zur Veränderung Organisation • Einführung Business Capability Teams • Einführung Platform Operation Team
- 134. Mut und Willen zur Veränderung Kultur • DevOps vs Silos • Continuous Delivery vs Releases • Autonomie vs Governance* • Fault Tolerant vs Static Systems *gilt für Micro Architektur, nicht für Marco Architektur
- 135. Was ihr mitnehmen solltet …
- 136. Lars Röwekamp | @mobileLarson FRAGEN? #WISSENTEILEN “From Zero to still Zero“ Die schönsten Fehler auf dem Weg in die Cloud.
- 137. Lars Röwekamp | @mobileLarson BESTEN DANK! #WISSENTEILEN “From Zero to still Zero“ Die schönsten Fehler auf dem Weg in die Cloud.
- 138. © Robert Daly – shutterstock.com (Folie 1) © AaronAmat – iStockphoto.com (Folie 11) © vasakna – fotolia.com (Folie 85) © foxacon – shutterstock.com (Folie 130) © lightspring – shutterstock.com (Folie 132) © re:invent 2019 (Folie 136) Alle weiteren Bilder der Präsentation sind entweder von pixabay.com, pexels.com, unsplash.com oder von mir selbst erstellt. Bildernachweis