Cloud is the new normal”, so Andrew R. Jassy (CIO AWS). Was also liegt näher, als genau jetzt den Schritt in die Cloud zu wagen? Denn schließlich wollen wir ja alle irgendwie ein klein wenig „normal“ sein. Aber ist dieser Schritt wirklich so einfach, wie uns die verschiedenen Cloudanbieter glauben machen? Lässt sich eine klassische Enterprise-Architektur einfach so in die Cloud überführen oder bedarf es neuer, cloudspezifischer Architekturmuster?  Was unterscheidet dabei die verschiedenen As-a-Service-Varianten (IaaS, PaaS, BaaS und FaaS) voneinander und für welchen Anwendungsfall nimmt man was? Fragen über Fragen – aber keine Panik, der Talk liefert Antworten. 

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

23. v1.3
v2.1
v2.2 v2.0
OPS „Team“
Release

24. v1.3
v2.1
v2.2 v2.0
OPS „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

27. v2.0.hfr
v2.2
„cool“ API
v2.0
Web Content
v2.2
Release
next version

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