„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 Cloud-spezifischer Architekturmuster? Wie kann uns das Cloud Maturity Model dabei helfen? Und was steckt eigentlich hinter Akronymen wie IaaS, PaaS, BaaS, SaaS und FaaS? Im Rahmen des Worskhops werde ich eine klassische Enterprise Anwendung Schritt für Schritt in die Cloud migrieren und dabei die verschiedenen Stufen / Reifegrade des Cloud Maturity Models durchlaufen. Angefangen bei "Lift & Shift" bis hin zu "Cloud Native" und "Cloud Voodoo – aka Serverless".

1. #WISSENTEILEN
Lars Röwekamp (@mobileLarson) | open knowledge (@_openKnowledge)
Cloud Computing
Das “New Normal“?

2. DISCLAIMER
By cloud, we mean any computing environment
in which computing, networking, and storage
resources can be provisioned and released
elastically in an on-demand, self-service
manner.*
“
* public and private/cooperate cloud Infrastructure
(Matt Stine, CTO Software Architecture, Pivotal.)

3. Warum
Cloud?

4. 0% 20% 40% 60% 80% 100%
Cloud
Computing
Cloud Monitor 2020
aktive Nutzer Planer/Diskutierer (noch) kein Thema
76%
73%
66%
19%
19%
21%
6%
8%
13%
2017
2018
2019
(Quelle: Bitcom Research, 2020, https://www.bitkom.org/Presse/Presseinformation/Drei-von-vier-Unternehmen-nutzen-Cloud-Computing)

5. Private Cloud
Computing
Public Cloud
Computing
Cloud Monitor 2020
58%
55%
51%
38%
35%
31%
25%
23%
22%
30%
28%
27%
16%
21%
28%
31%
37%
42%
2017
2018
2019
2017
2018
2019
0% 20% 40% 60% 80% 100%
aktive Nutzer Planer/Diskutierer (noch) kein Thema
(Quelle: Bitcom Research, 2020, https://www.bitkom.org/Presse/Presseinformation/Drei-von-vier-Unternehmen-nutzen-Cloud-Computing)

6. From idea to App
The biggest advantage of a cloud(-native)
architecture is that it takes you from idea
to app in the quikest possible time.
“
(Pavan Belagatti, Groth Marketing Manager, jfrog)

7. I promise!
(Amazon, Google, Microsoft, IBM…)

8. Die 6 Cloud-Versprechen
1. einfacheres Management
2. …
3. …
4. …
5. …
6. …

9. Die 6 Cloud-Versprechen
1. einfacheres Management
2. schnellere Releases
3. …
4. …
5. …
6. …

10. Die 6 Cloud-Versprechen
1. einfacheres Management
2. schnellere Releases
3. verbesserte Kosteneffizienz
4. …
5. …
6. …

11. Die 6 Cloud-Versprechen
1. einfacheres Management
2. schnellere Releases
3. verbesserte Kosteneffizienz
4. mehr Zuverlässigkeit/Sicherheit
5. …
6. …

12. Die 6 Cloud-Versprechen
1. einfacheres Management
2. schnellere Releases
3. verbesserte Kosteneffizienz
4. mehr Zuverlässigkeit/Sicherheit
5. beliebige Skalierbarkeit
6. …

13. Die 6 Cloud-Versprechen
1. einfacheres Management
2. schnellere Releases
3. verbesserte Kosteneffizienz
4. mehr Zuverlässigkeit/Sicherheit
5. beliebige Skalierbarkeit
6. besseres Kundenerlebnis

14. Die 6 Cloud-Versprechen
1. einfacheres Management
2. schnellere Releases
3. verbesserte Kosteneffizienz
4. mehr Zuverlässigkeit/Sicherheit
5. beliebige Skalierbarkeit
6. besseres Kundenerlebnis
BTW: keine Lock-In Effekte mehr*
* Cloud-native

16. #1
Agilität

17. #2
Plattform

18. #3
Kosten

19. #4
Innovationen

20. Wieviel
Cloud?*
* … passt zu mir?

21. 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)

22. Systems for the Cloud
For systems behave well on the cloud,
they need to be written for the cloud.*
“
(Paul Fremantle, VP Product Engineering at Weaveworks)
* Applications vs. Software-as-a-Service

23. Road to the Cloud
On Prem Cloud Native
?

24. … but want to be here!
Cloud Native
You are here
…
On Premise
?
Road to the Cloud

25. … or maybe here!
Cloud Native
00
01
02
03
04
Das Cloud-Maturity Model
… or there?
Cloud Friendly
But you want to be here …
Cloud Resilient
… or maybe here ..
Cloud Ready
You are here …
On Premise

26. aka “architecture”
Cloud Native
00
01
02
03
04
Das Cloud-Maturity Model
aka “repeatable”
Cloud Friendly
aka “lift & shift”
Cloud Ready
aka “me. myself & I”
On Premise
aka “self-healing”
Cloud Resilient

27. Showcase: ok Forum

31. „cool“ API
Web Content

32. Auf get‘s
in die Cloud

33. aka “architecture”
Cloud Native
00
01
02
03
04
Das Cloud-Maturity Model
aka “repeatable”
Cloud Friendly
aka “lift & shift”
Cloud Ready
aka “me. myself & I”
On Premise
aka “self-healing”
Cloud Resilient

34. 00
Das Cloud-Maturity Model
aka “me. myself & I”
On Premise

35. Stage #0
No
Cloud

36. 00
No-Cloud
aka „WTF“
*WTF = waste the future
Legacy Apps von Client-Server bis 3-Tier auf „bare metal“
getrennte Entwicklungs- und Operation-Teams
keine zentrale IT Governance
keine zentrale IT Innovationsstrategie
kaum bis keine Automatisierung

37. myApp
myApp
myApp
App Server
App Server
App Server
PRODUCTION
Self-Managed
Load Balancer
myDB
RDBMS
on prem

38. myApp
myApp
myApp
App Server
App Server
App Server
PRODUCTION
myDB
RDBMS
on prem
INTEGRATION
Self-Managed
Load Balancer

39. „cool“ API
Web Content
v1.3
v2.1
DEV Team

40. „cool“ API
Web Content
v1.3
v2.1
NEW NEW
DEV Team
Release

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

42. v1.3
v2.1
v2.2 v2.0
OPS „Team“
Release
aka Dooms-Day

43. v2.0
v2.2
„Let‘s pray!“
„cool“ API
v2.0
Web Content
v2.2
OPS „Team“

44. 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

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

46. > Hands-On

50. Die 6 Cloud-Versprechen
1. einfacheres Management
2. schnellere Releases
3. verbesserte Kosteneffizienz
4. mehr Zuverlässigkeit/Sicherheit
5. beliebige Skalierbarkeit
6. besseres Kundenerlebnis
BTW: keine Lock-In Effekte mehr*

51. Next Level EPICs
1. Nutzen von Cloud Servern
2. Nutzen von Cloud Plattform Services
3. Entsorgen der App Server Instanzen

52. Stage #1
Cloud
Ready

53. 00
Cloud-Ready
aka „lift & shift“
01
Self-contained Applications
Ports/Networking Plattform-managed
Infrastructure Services (IaaS/VMs)
erste Plattform Services (PaaS light)

54. myApp
myApp
myApp
EC2 Instance
EC2 Instance
EC2 Instance
Routing
PROD
Load Balancer
myDB
EC2 Instance

55. myApp
myApp
myApp
EC2 Instance
EC2 Instance
EC2 Instance
Routing
PROD
Load Balancer
myDB
EC2 Instance

56. myApp
myApp
myApp
EC2 Instance
EC2 Instance
EC2 Instance
Routing
PROD
Load Balancer
myDB
EC2 Instance
myFS
EC2 Instance
myMQ
EC2 Instance

57. myApp
myApp
myApp
EC2 Instance
EC2 Instance
EC2 Instance
Routing
PROD
Load Balancer
myDB
EC2 Instance
myFS
EC2 Instance
myMQ
EC2 Instance

58. myApp
myApp
myApp
EC2 Instance
EC2 Instance
EC2 Instance
Routing
PROD
Load Balancer
Queue
RDBMS
File Storage

60. „Kling soweit echt gut. Aber
wie bekomme ich meine
Anwendung in die Cloud?“

61. „Das ist ganz einfach:
• EC2 Instanz provisionieren
• App in Container
• Container in Registry
• Container auf Cloud-Instanz
• Zugriff auf Cloud-Instanz

62. ok-forum via EC2 – Step 01:
Cloud Instanz provisionieren
DEVOPS

63. ok-forum via EC2 – Step 02:
Docker installieren
DEVOPS

64. ok-forum via EC2 – Step 03:
Self-contained App packen
DEVOPS
forum v2.0

65. ok-forum via EC2 – Step 04:
Self-contained App „dockerisieren“
DEVOPS
forum-container:2.0

66. c
DEVOPS
ok-forum via EC2 – Step 05:
Docker Image in Registry pushen ok-forum:2.0
ok/forum:2.0

67. DEVOPS
ok-forum via EC2 – Step 06:
Docker Image pullen/starten
ok/forum:2.0

68. DEVOPS
ok-forum via EC2 – Step 07:
Deployment auf EC2 testen
Load Balancer
ok/forum:2.0
API v2.0

71. > Hands-On

75. „Das sind dann aber immer
recht große Deployments
durch das FAT JAR, oder?

76. „Das stimmt, daher arbeitet
man auch eher mit Layern*:
• App JAR
• App Dependencies JARs
• Server Hollo JAR
• JRE
• OS
*Don't Put Fat Jars in Docker Images:
https://phauer.com/2019/no-fat-jar-in-docker-image/

77. OS
JRE
app-v1.jar app-v2.jar app-v3.jar
70 MB
126 MB
63 MB 63 MB
63 MB

78. app-v1.jar 63 MB
DEPENDENCIES
53 MB
changes rarely
RESOURCES
8 MB
changes from
time to time
CODE
2 MB
changes frequently

79. OS
JRE
code-v1.jar code-v2.jar code-v3.jar
70 MB
126 MB
2 MB 2 MB
2 MB
Dependencies
Resources
53 MB
8 MB

82. „Ok, aber WARUM sollte ich
zusätzlich Teile der App durch
Plattform-Komponenten
ersetzen?

83. „Plattformkomponenten bieten
u.a. folgende Vorteile:
• Maintenance via Provider
• automatische Sicherung
• globale Replikation
• ggf. Kostenoptimierung

84. Warum ein Cloud Filesystem*?
• virtuelles Filesystem für beliebige Cloud Ressourcen (Art & Anzahl)
• Zugriff via On-Premises Server und EC2 Instanzen
• einfache, „sekundenschnelle“ Provisionierung (UI, CLI, API)
• dynamische Elastizität in beide Richtungen ohne Ausfallzeiten
• hoher Durchsatz / geringe Latenz unabhängig von der Größe
• AZ-übergreifende Datenbereitstellung
• Zahlmodell Pay-per-User berücksichtigt tatsächlich Nutzung
• Support von Serverless (AWS Lambda)
*Amazon Elastic File Service (EFS)

85. Alternativen zum Cloud Filesystem?
Simple Storage Service (S3)
• Object Store für „User Files“
• jedes Objekt hat eindeutigen Identifier
• automatische Versionierung inkl. Rollback
• programmativer und servicebasierter Zugriff
• Static Web Hosting Support
• hohe Data-Durability (99.999999999% aka „eleven nines“)
• Reliable Disaster Recovery via Cross-Region Replikation

86. Alternativen zum Cloud Filesystem?
Elastic Block Storage (EBS)
• Daten werden in gleich großen Blöcken gespeichert
• Provisionierung und Zuweisung zu EC2 Instanz via Size/Blöcken*
• optimierte Performanz durch 1:1 Beziehung
• schnelles Up- und Down-Scaling möglich
• Hochverfügbarkeit via Redundanz in AZs
• Snapshot für Data Backup und Region Duplicates
*vergleichbar mit der lokalen Disk einer physikalischen Machine

87. Alternativen zum Cloud Filesystem?
Amazon EBS vs EFS vs S3
https://www.missioncloud.com/blog/resource-amazon-ebs-vs-efs-vs-s3-
picking-the-best-aws-storage-option-for-your-business
Confused by AWS Storage Options?
https://dzone.com/articles/confused-by-aws-storage-options-
s3-ebs-amp-efs-explained

88. Warum ein Cloud RDBMS*?
• einfache, „sekundenschnelle“ Provisionierung (UI, CLI, API)
• manuelle oder automatische Skalierung ohne Ausfallzeiten
• Read Replica zur Entlastung der „Hauptinstanz“
• synchronisierte Standby Instanz via Multi-AZ-DB Instanzen
• verbrauchsorientierte Kosten
• zugriffsgesteuerte Sicherheit via Virtual Private Cloud
• PostgeSQL, MySql, MariaDB, Oracle DB, MS SQL Server, Amazon Aurora
*Amazon Relational Database Service (RDS)

89. Alternativen zu Cloud RDBMS?
NoSQL Database (dynamoDB)
• Key-Value und –Document DB
• konsistente Zugriffszeit im Bereich von Millisekunden
• > 10 Milliarden Zugriffe / Tag
• > 20 Millionen Zugriffe / Sekunde
• automatische Skalierung auf Tabellenebene
• Automatische Sicherung inkl. Recovery

90. Alternativen zu Cloud RDBMS?
In-Memory DB (ElastiCache)
• Key-Value in-Memory Store
• Zugriffszeiten unterhalb von Millisekunden für „Real-Time“ Use Cases
• zwei Varianten (Memcached / Redis API kompatibel)

91. Alternativen zu Cloud RDBMS?
RDS vs Redshift vs DynamoDB vs SimpleDB:
https://www.msp360.com/resources/blog/aws-database-services-
complete-overview-rds-vs-redshift-vs-dynamodb-vs-simpledb/
Amazon RDS vs DynamoDB:
https://digitalcloud.training/amazon-rds-vs-dynamodb/

92. Warum ein Cloud Message Broker*?
• einfache, „sekundenschnelle“ Provisionierung (UI, CLI, API)
• Unterstützung der Standard APIs (JMS, NMS, AMQP, STOMP, MQTT, WebSocket)
• einfache und schnelle Migration durch Aktualisieren der Endpunkte
• hohe Verfügbarkeit via Reliable Messages verteilt auf mehrere AZs
• Apache ActiveMQ, RabbitMQ
*Amazon MQ

93. Alternativen zum Cloud Message Broker?
Simple Queue Service (SQS)
• Hochverfügbarer, skalierbarer Queue Service*
• keine zusätzliche MQ Software notwendig
• Standard- und FIFO-Warteschlange
• je Nachricht mehrere Kopien in mehreren AZs
• verschlüsselte Nachrichten via Integration von AWS Key Management
• Zahlmodell Pay-per-User berücksichtigt tatsächlich Nutzung
*nur Queues, keine Topics – d.h. nur ein Abnehmer

94. Alternativen zum Cloud Message Broker?
Simpe Notification Service (SNS)
• Pub/Sub Notification an (AWS) Systeme & Personen
• Push über einen Endpunkt an beliebige Plattformen
• SMS, Mobile Push (Apple, Android, et al), eMail
• zuverlässige Nachrichtenzustellung (Notification Storage, Retry Policy, DLQ)
• Standard- und FIFO-Themen

95. Alternativen zum Cloud Message Broker?
Amazon SQS vs SNS
https://wisdomplexus.com/blogs/amazon-sqs-vs-sns/
AWS - Difference between SQS and SNS
https://medium.com/awesome-cloud/aws-difference-between-
sqs-and-sns-61a397bf76c5

96. > Hands-On

97. Die 6 Cloud-Versprechen
1. einfacheres Management
2. schnellere Releases
3. verbesserte Kosteneffizienz
4. mehr Zuverlässigkeit/Sicherheit
5. beliebige Skalierbarkeit
6. besseres Kundenerlebnis
BTW: keine Lock-In Effekte mehr*

98. Die 6 Cloud-Versprechen
1. einfacheres Management
2. schnellere Releases
3. verbesserte Kosteneffizienz
4. mehr Zuverlässigkeit/Sicherheit
5. beliebige Skalierbarkeit
6. besseres Kundenerlebnis
BTW: keine Lock-In Effekte mehr*

99. Next Level EPICs
1. Automatisieren der Skalierung
2. Verbessern der Verfügbarkeit
3. Optimieren des Deployments
4. Nutzen weiterer Cloud Plattform Services*
* nice to have

100. Stage #2
Cloud
Friendly

101. Cloud-Friendly
aka „repeatable“
02
12-factor App Design
mehr Plattform Services (PaaS)
Skalierung via Cloud Plattform
Verfügbarkeit (HA) via Cloud Plattform

103. 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.

104. 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

105. myApp
myApp
myApp
EC2 Instance
EC2 Instance
EC2 Instance
Routing
PROD
Load Balancer
Queue
RDBMS
File Storage

106. myApp
myApp
myApp
EC2 Instance
EC2 Instance
EC2 Instance
Routing
PROD
Load Balancer noSQL
Queue
RDBMS
File Storage Archive

107. myApp
myApp
myApp
EC2 Instance
EC2 Instance
EC2 Instance
Routing
PROD
Load Balancer noSQL
Queue
RDBMS
File Storage Archive
automatische Skalierung?

108. Elastic
Beanstalk
Service
Elastic
Container
Service
Elastic
Kubernetes
Service
Level of „Cloud Native“
high
low
low
high
Level of Integration & Ease of Use

109. Elastic
Beanstalk
Service
Elastic
Container
Service
Elastic
Kubernetes
Service
Level of Integration & Ease of Use
Level of „Cloud Native“
high
low
low
high

110. myApp
myApp
myApp
Routing
Elastic
Container
Service
Backing
Services
PROD
noSQL
Queue
RDBMS
File Storage Archive
Load Balancer

111. myApp
myApp
myApp
Routing
Elastic
Container
Service
Backing
Services
PROD
noSQL
Queue
RDBMS
CI/CD
app.yml
Declarative API
File Storage Archive
Load Balancer

112. Routing
Elastic
Container
Service
Backing
Services
PROD
noSQL
Queue
RDBMS
CI/CD
app.yml
Declarative API
File Storage Archive
myApp
myApp
DEV
Code Base
Load Balancer
myApp
myApp
myApp

113. Routing
Elastic
Container
Service
Backing
Services
PROD
noSQL
Queue
RDBMS
CI/CD
app.yml
Declarative API
File Storage Archive
myApp
myApp
DEV
Code Base
Load Balancer
myApp
myApp
myApp
Availability Zone A
Availability Zone B
Availability Zone C

114. Routing
Queue
Elastic
Container
Service
Backing
Services
CI/CD
app.yml
Declarative API
myApp
myApp
Code Base
Log Stream
Trace Info
Config
Users
Monitorring
File Storage Archive
RDBMS noSQL
IAM Certificates
PROD
DEV
Load Balancer
myApp
myApp
myApp
Availability Zone A
Availability Zone B
Availability Zone C

116. „Ok, und wie bekomme ich
meine 12-factor App
in die Cloud und dort dann
automatisch skaliert etc.?“

117. „Auch das ist recht einfach:
• App in Container
• Container in Cloud-Registry
• Zielbild deklarativ beschreiben
• und dann ab in den Managed
Container Service

118. DEVOPS
Elastic Container Regesty
Elastic Container Service
ECS Cluster
ECS Service
ECS Task (Def) Docker Image
Elastic Container Service:
Task, Service, Cluster

119. (Quelle: https://www.freecodecamp.org/news/amazon-ecs-terms-and-architecture-807d8c4960fd/)

120. DEVOPS
Elastic Container Regesty
Elastic Container Service
ok-forum via ECS:
Das Zielbild
Task
Service
Cluster
API v2.0
ok/forum:2.0

121. DEVOPS
Elastic Container Regesty
Elastic Container Service
ok-forum via ECS - Step 01:
Docker Image in ECR pushen ok-forum:2.0
ok/forum:2.0

122. DEVOPS
Elastic Container Regesty
Elastic Container Service
ok-forum via ECS - Step 02:
Cluster anlegen
(zunächst als leere Hülle)
ok/forum:2.0
Cluster

123. DEVOPS
Elastic Container Regesty
Elastic Container Service
ok-forum via ECS - Step 03:
Task Def erstellen
(deklarative Beschreibung)
ok/forum:2.0
Task
Cluster

124. DEVOPS
Elastic Container Regesty
Elastic Container Service
ok-forum via ECS - Step 04:
ECS Service definieren
(referenziert 1:1 auf Task Def)
ok/forum:2.0
Task
Cluster
Service

125. DEVOPS
Elastic Container Regesty
Elastic Container Service
ok-forum via ECS - Step 05:
ECS Service starten
(startet Container im Cluster)
ok/forum:2.0
Task
Cluster
Service

126. DEVOPS
Elastic Container Regesty
Elastic Container Service
ok-forum via ECS – Step 06:
Elastic Load Balancer
(optional)
Task
Service
Cluster
API v2.0
ok/forum:2.0
Load
Balancer

127. DEVOPS
Elastic Container Regesty
Elastic Container Service
ok-forum via ECS – Step 07:
Cluster starten
(passiert automatisch)
Task
Service
Cluster
API v2.0
ok/forum:2.0
Load
Balancer

128. DEVOPS
Elastic Container Regesty
Elastic Container Service
ok-forum via ECS:
Cluster monitoren
(e.g. via CloudWatch)
Task
Service
Cluster
API v2.0
ok/forum:2.0
Cluster, Service & Task Status
CPU & Memory Utilization

129. ECS Cluster in Action:

130. > Hands-On

134. „Welche interessanten
zusätzlichen Plattform-
Dienste der Cloud kann
ich denn nutzen?“

135. „Super interessant sind:
• noSQL DBs*
• Archive Storages
• Config Mgmt Systems
• IAM / User Mgmt Systems
• …
*siehe Cloud Ready: „Alternativen zu RDS - Dynamo DB“

136. Routing
Queue
Elastic
Container
Service
Backing
Services
CI/CD
app.yml
Declarative API
myApp
myApp
Code Base
Log Stream
Trace Info
Config
Users
Monitorring
File Storage Archive
RDBMS noSQL
IAM Certificates
PROD
DEV
Load Balancer
myApp
myApp
myApp
Availability Zone A
Availability Zone B
Availability Zone C

137. Routing
Elastic
Container
Service
Backing
Services
CI/CD
app.yml
Declarative API
myApp
myApp
Code Base
Log Stream
Trace Info
Monitorring
Queue Config
Users
File Storage Archive
RDBMS noSQL
IAM Certificates
PROD
DEV
Load Balancer
myApp
myApp
myApp
Availability Zone A
Availability Zone B
Availability Zone C
Archive

138. Warum ein Cloud Archive Service*?
• kostengünstig(er)
• 99,999999999 Data Durability via autom. Verteilung auf mind. drei AZ
• CloudTrail Integration zur Protokollierung zwecks Auditing
• 4+ verschiedende Abrufklassen
• Active Archive (1-5 Minuten)
• Standard (3-5 Stunden)
• Mass Data (5-12 Stunden)
• Deep Archive (12 – 48 Stunden)
*S3 Glacier & S3 Glacier Deep Archice

139. Routing
Queue
Elastic
Container
Service
Backing
Services
CI/CD
app.yml
Declarative API
myApp
myApp
Code Base
Log Stream
Trace Info
Config
Users
Monitorring
File Storage Archive
RDBMS noSQL
IAM Certificates
PROD
DEV
Load Balancer
myApp
myApp
myApp
Availability Zone A
Availability Zone B
Availability Zone C

140. Routing
Elastic
Container
Service
Backing
Services
CI/CD
app.yml
Declarative API
myApp
myApp
Code Base
Log Stream
Trace Info
Monitorring
Queue Config
Users
File Storage Archive
RDBMS noSQL
IAM Certificates
PROD
DEV
Load Balancer
myApp
myApp
myApp
Availability Zone A
Availability Zone B
Availability Zone C
IAM

141. Warum ein Cloud IAM & User Mgmnt?
• Verwaltung von AWS-Benutzern und Nutzergruppen
• detaillierte Zugriffssteuerung für AWS-Services & Ressourcen
• Zugriffspläne und Zugriffsanalysen (z.B. least privilege)
• Active Directory Integration
• Verwaltung von App-Benutzern und Nutzerpools
• Registrierungs- und Anmelde-Flows
• Oauth 2.0 , SAML 2.0 , OpenID Connect
• 3rd Party (Apple, Facebook, Google und Amazon)
IAM
Cognito

145. > Hands-On

146. Die 6 Cloud-Versprechen
1. einfacheres Management
2. schnellere Releases
3. verbesserte Kosteneffizienz
4. mehr Zuverlässigkeit/Sicherheit
5. beliebige Skalierbarkeit
6. besseres Kundenerlebnis
BTW: keine Lock-In Effekte mehr*

147. Die 6 Cloud-Versprechen
1. einfacheres Management
2. schnellere Releases
3. verbesserte Kosteneffizienz
4. mehr Zuverlässigkeit/Sicherheit
5. beliebige Skalierbarkeit
6. besseres Kundenerlebnis
BTW: keine Lock-In Effekte mehr*

148. Next Level EPICs
1. Überwachen des Systemzustands*
2. Überwachen der System-KPIs**
3. Proaktives verhindern von Fehlzuständen
4. Autom. reagieren auf Fehlzustände
* „Ist mein System gesund?“
** „Reagiert mein System wie erwartet?“

149. Stage #3
Cloud
Resilient

150. 03
Cloud-Resilient
aka „self-healing“
*antifragiles System
proaktives Design für Ausfälle
proaktives Testen von Ausfällen*)
Metriken & Monitoring als Systembestandteil
App-Resilient gegen Ausfälle von Teilsystemen

151. Ensure fault tolerance
Build without taking steps to ensure fault
tolerance, 30 dependencies each with 99.99%
uptime would result in 2+ hours downtime per
month.
“
(netflix Techblog)

152. Routing
Queue
Elastic
Container
Service
Backing
Services
CI/CD
app.yml
Declarative API
myApp
myApp
Code Base
Log Stream
Trace Info
Config
Users
Monitorring
File Storage Archive
RDBMS noSQL
IAM
PROD
DEV
Load Balancer
myApp
myApp
myApp
Availability Zone A
Availability Zone B
Availability Zone C
Certificates

153. Routing
Queue
Elastic
Container
Service
Backing
Services
CI/CD
app.yml
Declarative API
myApp
myApp
Code Base
Config
Users
Monitorring
File Storage Archive
RDBMS noSQL
IAM
PROD
DEV
Load Balancer
myApp
myApp
myApp
Availability Zone A
Availability Zone B
Availability Zone C
Certificates
Log Stream
Trace Info
Health Checks
Metrics

154. Routing
Queue
Elastic
Container
Service
Backing
Services
CI/CD
app.yml
Declarative API
myApp
myApp
Code Base
Config
Users
Monitorring
File Storage Archive
RDBMS noSQL
IAM
PROD
DEV
Load Balancer
myApp
myApp
myApp
Availability Zone A
Availability Zone B
Availability Zone C
Certificates
Log Stream
Trace Info
Health Checks
Metrics
self
healing

155. DEV
Routing
Queue
Elastic
Container
Service
Backing
Services
CI/CD
app.yml
Declarative API
myApp
myApp
Code Base
Config
Users
Monitorring
File Storage Archive
RDBMS noSQL
IAM
PROD
TEST
Load Balancer
myApp
myApp
myApp
Availability Zone A
Availability Zone B
Availability Zone C
Certificates
Log Stream
Trace Info
Health Checks
Metrics
self
healing
proactive
test for
failure

157. „Verstanden, Health Checks
und Metriken sind der
Schlüssel zum Erfolg! Was
genau kann/muss ich dafür
tun.

158. „Du bekommst bereits etliche
HCs & Metriken automatisch.
Zusätzlich kannst du eigene
erstellen, einbinden und
natürlich überwachen:
• Alarm -> Notification
• Notification -> Action*
*e.g. trigger Auto Scaling Policy

159. DEVOPS
Elastic Container Regesty
Elastic Container Service
ok-forum via ECS:
Cluster monitoren
(e.g. via CloudWatch)
Task
Service
Cluster
API v2.0
ok/forum:2.0
Cluster, Service & Task Status
CPU & Memory Utilization

160. DEVOPS
CloudWatch
Elastic Container Service
ok-forum via ECS:
Cluster monitoren
(e.g. via CloudWatch)
Cluster
API v2.0
Status: Cluster, Service, Task
Metrics: Cpu, Memory
Logs
Alarm Synthetics
Rules
myHealth: Container, App
myMetrics: Functional, Business

161. DEVOPS
CloudWatch
Elastic Container Service
ok-forum via ECS:
Cluster monitoren
(e.g. via CloudWatch)
Cluster
API v2.0
HC & Metrics
(1x minute)
Logs
Alarm Synthetics
Rules

162. DEVOPS
CloudWatch
Elastic Container Service
ok-forum via ECS:
Cluster monitoren
(e.g. via CloudWatch)
Cluster
API v2.0
Logs
Alarm Synthetics
Rules
HC & Metrics
(1x minute)

163. DEVOPS
CloudWatch
Elastic Container Service
ok-forum via ECS:
Cluster monitoren
(e.g. via CloudWatch)
Cluster
API v2.0
Logs
Alarm Synthetics
Rules
trigger action, e.g. restart or scale tasks
HC & Metrics
(1x minute)

164. > Hands-On

170. Die 6 Cloud-Versprechen
1. einfacheres Management
2. schnellere Releases
3. verbesserte Kosteneffizienz
4. mehr Zuverlässigkeit/Sicherheit
5. beliebige Skalierbarkeit
6. besseres Kundenerlebnis
BTW: keine Lock-In Effekte mehr*

171. Die 6 Cloud-Versprechen
1. einfacheres Management
2. schnellere Releases
3. verbesserte Kosteneffizienz
4. mehr Zuverlässigkeit/Sicherheit
5. beliebige Skalierbarkeit
6. besseres Kundenerlebnis
BTW: keine Lock-In Effekte mehr*

172. Next Level EPICs
1. Erhöhen der Unabhängigkeit*
2. Flexibilisieren der Skalierung
3. Ausweiten der (API) Nutzung
4. Vermindern der Provider-Abhängigkeit
* gilt für Entwicklung, Test und Laufzeit

173. Stage #4
Cloud
Native

174. Cloud-Native
aka „architectured“
04
Microservices statt Monolithen
Loose gekoppelte Komponenten
API First Design Ansatz
Consumer-driven Contract Testing

175. DEV
Routing
Queue
Elastic
Container
Service
Backing
Services
CI/CD
app.yml
Declarative API
myApp
myApp
Code Base
Config
Users
Monitorring
File Storage Archive
RDBMS noSQL
IAM
PROD
TEST
Load Balancer
myApp
myApp
myApp
Availability Zone A
Availability Zone B
Availability Zone C
Certificates
Log Stream
Trace Info
Health Checks
Metrics
self
healing
proactive
test for
failure

176. DEV
Routing
Queue
Elastic
Container
Service
Backing
Services
CI/CD
app.yml
Declarative API
myApp
myApp
Code Base
Config
Users
Monitorring
File Storage Archive
RDBMS noSQL
IAM
PROD
TEST
Load Balancer
Availability Zone A
Availability Zone B
Availability Zone C
Certificates
Log Stream
Trace Info
Health Checks
Metrics
self
healing
proactive
test for
failure
MS
MS
MS
MS
MS
MS
MS

177. DEV
Routing
Queue
Elastic
Container
Service
Backing
Services
CI/CD
app.yml
Declarative API
myApp
myApp
Code Base
Config
Users
Monitorring
File Storage Archive
RDBMS noSQL
IAM
PROD
TEST
Load
Balancer
Availability Zone A
Availability Zone B
Availability Zone C
Certificates
Log Stream
Trace Info
Health Checks
Metrics
self
healing
proactive
test for
failure
MS
MS
MS
MS
MS
MS
MS
API
Gateway

178. DEV
Routing
Queue
Backing
Services
CI/CD
app.yml
Declarative API
myApp
myApp
Code Base
Config
Users
Monitorring
File Storage Archive
RDBMS noSQL
IAM
PROD
TEST
Availability Zone A
Availability Zone B
Availability Zone C
Certificates
Log Stream
Trace Info
Health Probes
Metrics
self
healing
proactive
test for
failure
MS
MS
MS
MS
MS
MS
MS
API
Gateway
Elastic
Kubernetes
Service
ALB
Controller

180. „Wow, Skalierung auf
fachlicher Ebene. Das macht
Sinn! Aber wie finde ich den
richtigen Service-Schnitt“

181. „Der richtige fachliche Service-
Schnitt? Hold my beer …“*
*Domain Driven Design

182. > Hands-On

183. > Hands-On
ok FORUM
User
Service
Discussion
Service

184. > Hands-On
ok FORUM
User
Service
Discussion
Service
Category
Service

185. > Hands-On
ok FORUM
User
Service
Discussion
Service
Category
Service Elastic
Search
Service

189. „Ok. APIs hatte ich ja vorher
auch schon irgendwie. Muss
ich da jetzt etwas ändern?
Und wie stelle ich die APIs
3ten zur Verfügung?“

190. „Wissenswertes aus der Rubrik
‚API Design leicht gemacht‘:
• Public vs Private API
• API Design Guide
• API Governance
• API Gateway

191. > Hands-On

198. Die 6 Cloud-Versprechen
1. einfacheres Management
2. schnellere Releases
3. verbesserte Kosteneffizienz
4. mehr Zuverlässigkeit/Sicherheit
5. beliebige Skalierbarkeit
6. besseres Kundenerlebnis
BTW: keine Lock-In Effekte mehr*

199. Die 6 Cloud-Versprechen
1. einfacheres Management
2. schnellere Releases
3. verbesserte Kosteneffizienz
4. mehr Zuverlässigkeit/Sicherheit
5. beliebige Skalierbarkeit
6. besseres Kundenerlebnis
BTW: keine Lock-In Effekte mehr*

200. Next Level EPICs
1. Schneller, höher, weiter …

201. Stage #4
Cloud
Voodoo

202. … and you are here now!
Cloud Native
00
01
02
03
04
Congratulations!
You came from here …
On Premise

203. … and you are here now!
Cloud Native
00
01
02
03
04
But … ?
You came from here …
On Premise
aka “functions as a service”
aka “Serverless”
Cloud Voodoo

204. DEV
Routing
Queue
Backing
Services
CI/CD
app.yml
Declarative API
myApp
myApp
Code Base
Config
Users
Monitorring
File Storage Archive
RDBMS noSQL
IAM
PROD
TEST
Availability Zone A
Availability Zone B
Availability Zone C
Certificates
Log Stream
Trace Info
Health Probes
Metrics
self
healing
proactive
test for
failure
MS
MS
MS
MS
MS
MS
MS
API
Gateway
Elastic
Kubernetes
Service
ALB
Controller

205. Routing
Queue
Backing
Services
CI/CD
app.yml
myApp
myApp
Code Base
Config
Users
Monitorring
File Storage Archive
RDBMS noSQL
IAM Certificates
PROD
TEST
DEV
proactive
test for
failure
Fn
Fn
Fn
Fn
Fn
Fn
Fn
Fn
Serverless
Functions
Fn
Fn
Fn Fn
Fn
Fn
Fn
Fn
Fn
Fn
Fn
Fn
Fn
Log Stream
Trace Info
Healt Probes
Metrics
Declarative API
API
Gateway

206. Die 6 Cloud-Versprechen
1. einfacheres Management
2. schnellere Releases
3. verbesserte Kosteneffizienz
4. mehr Zuverlässigkeit/Sicherheit
5. beliebige Skalierbarkeit
6. besseres Kundenerlebnis
BTW: keine Lock-In Effekte mehr*

207. Die 6 Cloud-Versprechen
1. einfacheres Management
2. schnellere Releases
3. verbesserte Kosteneffizienz
4. mehr Zuverlässigkeit/Sicherheit
5. beliebige Skalierbarkeit
6. besseres Kundenerlebnis
BTW: keine Lock-In Effekte mehr*

208. Zwischenfazit zur Cloud …

209. „cool“ API
v2.0
Web Content
v2.2

210. „cool“ API
v2.0
Web Content
v2.2

211. „cool“ API
v2.0
Web Content
v2.2
v2.0
?

212. Stage #99
Cloud
Frontend

213. DEVOPS
some GIT Registy
Amplify Hosted Web App
ok-forum – Frontend:
Frontend via CNN bereitstellen
(und builden, testen, deployen)
provison
deploy build
{ … }
local Repository
{ … }
remote Repository

214. DEVOPS
some GIT Regesty
Amplify Hosted Web App
ok-forum – Frontend:
Frontend via CNN bereitstellen
(und builden, testen, deployen)
provison
deploy build
{ … }
local Repository
{ … }
remote Repository

215. DEVOPS
some GIT Regesty
Amplify Hosted Web App
ok-forum – Frontend:
Frontend via CNN bereitstellen
(und builden, testen, deployen)
provison
deploy build
{ … }
local Repository
{ … }
remote Repository

216. DEVOPS
some GIT Regesty
Amplify Hosted Web App
ok-forum – Frontend:
Frontend via CNN bereitstellen
(und builden, testen, deployen)
provison
deploy build
{ … }
local Repository
{ … }
remote Repository

217. DEVOPS
some GIT Regesty
Amplify Hosted Web App
ok-forum – Frontend:
Frontend via CNN bereitstellen
(und builden, testen, deployen)
provison
deploy build
{ … }
local Repository
{ … }
remote Repository

218. DEVOPS
some GIT Regesty
Amplify Hosted Web App
ok-forum – Frontend:
Frontend via CNN bereitstellen
(und builden, testen, deployen)
provison
deploy build
{ … }
local Repository
{ … }
remote Repository

223. „cool“ API
v2.0
Web Content
v2.2

224. (M)ein Fazit zur Cloud …

225. (M)ein Fazit zur
Cloud
Cloud ist mehr als nur Technologie
Cloud ist auch
• Architektur
• Vorgehen
• Organisation

226. Cloud braucht Mut zur Veränderung …

227. Mut und Willen zur Veränderung
Technologie
• fachliches Splitten der Monolithen
• fachliches Splitten der Daten
• Einführung von Containerisierung
• leichtgewichtige Prozesse*
*Choreographie wenn möglich, Orchestrierung wenn nötig

228. Mut und Willen zur Veränderung
Organisation
• Einführung Business Capability Teams
• Einführung Platform Operation Team

229. 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

230. Was ihr mitnehmen solltet …

231. ? ? ?
@mobileLarson
lars.roewekamp@openknowledge.de

232. Lars Röwekamp, @mobileLarson
Kontakt:
lars.roewekamp@openknowledge.de
kontakt@openknowledge.de
Besten Dank! #WISSENTEILEN

233. © you – shutterstock.com (Folie 1)
© krakenimages.com – shutterstock.com (Folie 7)
© rawpixel.com – shutterstock.com (Folie 16)
© foxaon1987 – shutterstock (Folie 75)
© ligthspring – shutterstock.com (Folie 77)
© re:invent 2019 (Folie 81)
Alle weiteren Bilder der Präsentation sind entweder von pixabay.com
oder von mir selbst erstellt.
Bildernachweis

234. 1) EC 2 Provisionierung inkl Docker Installation
2) ECS Provisionierung inkl ECR
ANHÄNGE

235. Provisionierung – EC2:

236. Provisionierung – EC2:

237. Provisionierung – EC2:

238. Provisionierung – EC2:

239. Provisionierung – EC2:

240. Provisionierung – EC2:

241. Provisionierung – EC2:

242. Provisionierung – EC2:

243. Installation Docker: ~% ssh -i keypair.pem ec2-user@<EC2-IP>

244. Installation Docker: [ec@ip~]$ sudo yum install –y docker

245. Installation Docker: [ec@ip~]$ sudo service docker start

246. Installation Docker: [ec@ip~]$ sudo docker info

247. Container starten: [ec@ip~]$ sudo docker run –d –p 80:7070 …

248. Installation testen: http://<EC2-DNS-IP>/categories

249. Installation testen: http://<EC2-DNS-IP>/categories

250. Provisionierung – ECS:

251. Provisionierung – ECS:

252. Provisionierung – ECS:

253. Provisionierung – ECS:

254. Provisionierung – ECS:

255. Provisionierung – ECS:

256. ECS in Action - Cluster:

257. ECS in Action – NO EC2 Instances(!):

258. ECS in Action - Tasks:

259. ECS in Action - Service:

260. ECS in Action – Service Details:

261. ECS in Action – Load Balancer:

262. ECS in Action – API Call:

263. ECS in Action – API Call: