„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? Im Rahmen des Workshops werden wir Schritt für Schritt eine bestehende Enterprise-Anwendung in die Cloud migrieren. Angefangen bei der Nutzung von Cloudinfrastruktur (IaaS) über die Anbindung von Cloudplattformkomponenten (PaaS) und Backend-Services (BaaS) bis hin zu Serverless Functions (FaaS) werden wir für die unterschiedlichen Anwendungsszenarien unserer Applikation passende Architekturansätze entwerfen und deren Vor- und Nachteile diskutieren. Natürlich sprechen wir dabei auch Themen wie Testing, Monitoring und automatisiertes Deployment an.
3. ÜBER MICH
Wer bin ich - und wenn ja, wie viele?
• CIO New Technologies
• Enterprise & Mobile
• Autor, Speaker, Coach & Mentor
• Snowboard & MTB Enthusiast (a.k.a. “stets bemüht“)
Lars Röwekamp (a.k.a. @mobileLarson)
11. „Kein Server ist
einfacher zu
verwalten, als
kein Server.“
(Werner Vogels, CTO Amazon)
out-of-the-box self-scaling
out-of-the-box
self-scaling
cloud-based
super-backend
I had a dream ...
47. Road to less Server
Self-Managed Cloud-Managed
Provisioning
Security
Backup/Recovery
Scaling
Provisioning
Security
Maintenance
Scaling
48. Road to less Server
Self-Managed Cloud-Managed
API Key Mgmt
Throtteling
Zero-Downtime
Region Availability
Provisioning
Security
Backup/Recovery
Scaling
Provisioning
Security
Maintenance
Scaling
49. Road to less Server
PaaS
(Platform as a Service)
50. Road to less Server
PaaS
(Platform as a Service)
56. #WISSENTEILEN
“Run your business code
highly-available
in the cloud in response
to events and scale
without any servers to
manage.“*
* AWS Lambda Advertising
63. „Kein Server ist
einfacher zu
verwalten, als
kein Server.“
(Werner Vogels, CTO Amazon)
out-of-the-box self-scaling
out-of-the-box
self-scaling
cloud-based
super-backend
Remember
„your“ dreams?
78. #WISSENTEILEN
Function as self-contained application
Serverless Function: Entwickler schreibt eine Business-
Funktion in einer der unterstützen Programmiersprachen,
„bundled“ diese mit den entsprechenden Abhängigkeiten
(LIBs) und lädt sie in die Cloud.
Serverless Environment: Führt die Funktion bei „Aufruf“ in
der passenden Runtime effizient, flexibel und hoch skalierbar
aus.
“
79. #WISSENTEILEN
Serverless no need to maintain
Entwickler: Fokussiert sich ausschließlich auf die
Umsetzung der Business-Logik und das Erstellen des
Function-Bundle.
Cloud Provider: liefert und maintained rundum-sorglos
Umgebung für die Serverless Functions, inklusive etwaiger
Cloud Services (z.B. Storage, DB, Streaming, AI).
“
92. trigger
request
Hello World „under the Hood“
Download
Function Code
ZIP
AWS Cloud
Setup
Runtime
Init
Function
COLD START
Execute
Handler
93. trigger
request
Hello World „under the Hood“
Download
Function Code
ZIP
AWS Cloud
Setup
Runtime
Init
Function
COLD START
Execute
Handler
Terminate
Function
108. Szenario #1: Lessons Learned
Was wir bisher gelernt haben …
• S3 ist der Platz zur Ablage von Objekten in AWS
• S3 benötigt spezielle Zugriffsrechte
• S3 triggert automatisch Cloud Events an
• Filter innerhalb der Lambda können S3 Event Trigger gezielt
einschränken, z.B. für
• Buckets
• Prefix / Postfix,
• IAM Nutzer / Rollen
110. Szenario #2: Stream Processing
Regelmäßiges abarbeiten von Streaming Data
• Social Media Trendanalysen
• Sensor Data Monitoring / Anomaly Detection
111. AWS Cloud
1
sensor data stream is
uploaded to Kinesis
in real-time
Szenario #2: Stream Processing
tons of
very important
sensor data
112. AWS Cloud
1
sensor data stream is
uploaded to Kinesis
in real-time
Szenario #2: Stream Processing
tons of
very important
sensor data
113. AWS Cloud
Data Stream Analysis
StreamAnalyzer
Logs
1
sensor data stream is
uploaded to Kinesis
in real-time
2
Lambda runs code to
detect anomalies
Szenario #2: Stream Processing
tons of
very important
sensor data
114. AWS Cloud
Data Stream Analysis
StreamAnalyzer
Logs
store anomalies
extracted by lambda
function
1
sensor data stream is
uploaded to Kinesis
in real-time
2
3
Lambda runs code to
detect anomalies
Szenario #2: Stream Processing
tons of
very important
sensor data
115. AWS Cloud
Data Stream Analysis
StreamAnalyzer
Logs
Real-Time Monitoring / Querying
store anomalies
extracted by lambda
function
1
sensor data stream is
uploaded to Kinesis
in real-time
2
3
Lambda runs code to
detect anomalies
4
data immediately
available for interested
parties to query
Szenario #2: Stream Processing
tons of
very important
sensor data
118. Szenario #3: Lessons Learned
Was wir bisher gelernt haben…
• Kinesis erlaubt die Bearbeitung von Data / Media Stream
• Kinesis benötigt spezielle Zugriffsrechte
• Lambdas können Chunks eines Kinesis Streams bearbeiten
• Lambdas in Verbindung mit Kinesis können genutzt werden, um …
• Metriken zu erzeugen
• Fehler / Anomalien zu erkennen
• Media Trends zu analysieren
120. Szenario #3: Web Application
Serverless „all in“ einer Anwendung…
• Ausliefern von statischem Content via CDN
• Authentication / Autorization via BaaS
• Businesslogik via FaaS (unter Verwendung von PaaS)
121. Szenario #3: Web Application
AWS Cloud
Web Client
region aware
web app
delivery
1
122. Szenario #3: Web Application
AWS Cloud
Web Client
region aware
web app
delivery
1
login via id/pwd
returns JWT
2
123. Szenario #3: Web Application
AWS Cloud
Web Client
region aware
web app
delivery
1
login via id/pwd
returns JWT
2
3
REST
call
124. Szenario #3: Web Application
AWS Cloud
Web Client
region aware
web app
delivery
1
login via id/pwd
returns JWT
2
3
REST
call
4
translated
lambda
trigger
125. Szenario #3: Web Application
AWS Cloud
Web Client
storage related functions
region aware
web app
delivery
1
login via id/pwd
returns JWT
2
3
REST
call
4
translated
lambda
trigger
5
lambda
@work
126. Szenario #3: Web Application
AWS Cloud
Web Client
storage related functions
database related functions
region aware
web app
delivery
1
login via id/pwd
returns JWT
2
3
REST
call
4
translated
lambda
trigger
5
lambda
@work
5
lambda
@work
127. Szenario #3: Web Application
AWS Cloud
Web Client
storage related functions
database related functions
additional functions, e.g.
region aware
web app
delivery
1
login via id/pwd
returns JWT
2
6
3
REST
call
4
translated
lambda
trigger
5
lambda
@work
5
lambda
@work
128.
129. The Road to the Cloud ...
Der Serverless Showcase
130. Web Image Gallery
(easy version)
GET ../images/{imageId}
PUT ../images/{imageId}
DELETE ../images/{imageId}
POST ../images/
131. Web Image Gallery
(not so easy version)
GET ../images/{imageId}
PUT ../images/{imageId}
DELETE ../images/{imageId}
POST ../images/
132. Web Image Gallery
(real life version)
GET ../images/{imageId}
PUT ../images/{imageId}
DELETE ../images/{imageId}
POST ../images/
133. Szenario #3: Lessons Learned
Was wir bisher gelernt haben …
• CloudFront und S3 zur Web App Auslieferung (statischer Content)
• Cognito zur User Authentication via JWT
• Ketten von async / lose gekoppelten Lambdas
• Gateway dient als eine Art Function Dispatcher (plus …)
134. Szenario #3: Lessons Learned
Was wir bisher gelernt haben …
• CloudFront und S3 zur Web App Auslieferung (statischer Content)
• Cognito zur User Authentication via JWT
• Ketten von async / lose gekoppelten Lambdas
• Layer zur Mehrfachnutzung von Libraries in Lambdas
• Gateway dient als eine Art Function Dispatcher (plus …)
?
137. AWS Cloud
Wofür ist ein API Gateway gut?
• Security
• API Key Handling
• Throttling
• Proxying
• Logging / Tracing
• Request / Respons Mapping
• Staging
138. AWS Cloud
1
Szenario #4: API Gateway
GET ../resources/{resourceId}
PUT ../resources/{resourceId}
DELETE ../resources/{resourceId}
POST ../resources/
139. AWS Cloud
Szenario #4: API Gateway
21
GET ../resources/{resourceId}
PUT ../resources/{resourceId}
DELETE ../resources/{resourceId}
POST ../resources/
144. Szenario #4: Lessons Learned
Was wir bisher gelernt haben ...
• ein API Gateway „schützt“ die Cloud vor der Außenwelt
• HTTP Requests werden in Lambda Trigger überführt
• HTTP Parameter / Payload wird auf Lambda Events gemappt
• Lambda Results werden in HTTP Status Codes überführt
• Lambda Result Objekte werden auf HTTP Payload gemapped
• API Gateways kann ein Staging-Konzpt realisieren
148. AWS Cloud
Store raw Image
1
Use-Case: Upload Image
upload image
with additional
information
149. AWS Cloud
Store raw Image
Store Image Information
1
2
Use-Case: Upload Image
upload image
with additional
information
150. AWS Cloud
AWS Step Functions workflow: Store Image
Store raw Image
Store Image Information
1
2
Use-Case: Upload Image
upload image
with additional
information
151. AWS Cloud
AWS Step Functions workflow: Store Image
Create ThumbnailStore raw Image
Store Image Information
1
2
Use-Case: Upload Image
upload image
with additional
information
152. AWS Cloud
AWS Step Functions workflow: Store Image
Create Thumbnail
Inform Subscribers
Store raw Image
Store Image Information
1
2
Use-Case: Upload Image
upload image
with additional
information
153. AWS Cloud
AWS Step Functions workflow: Store Image
Create Thumbnail
Inform Subscribers
Store raw Image
Store Image Information
1
2
Use-Case: Upload Image
upload image
with additional
information
154. AWS Cloud
AWS Step Functions workflow: Store Image
Create Thumbnail
Inform Subscribers
Store raw Image
Store Image Information
1
2
Use-Case: Upload Image
upload image
with additional
information
155. AWS Cloud
AWS Step Functions workflow: Store Image
Create Thumbnail
Inform Subscribers
Store raw Image
Store Image Information
1
2
Use-Case: Upload Image
upload image
with additional
information
156. AWS Cloud
AWS Step Functions workflow: Store Image
Create Thumbnail
Inform Subscribers
Store raw Image
Store Image Information
1
2
Use-Case: Upload Image
upload image
with additional
information
158. AWS Cloud
AWS Step Functions workflow: Store Image
Create Thumbnail
Inform Subscribers
Store raw Image
Store Image Information
1
2
159. AWS Cloud
AWS Step Functions workflow: Store Image
Create Thumbnail
Inform Subscribers
Store raw Image
Store Image Information
1
2
160. AWS Cloud
AWS Step Functions workflow: Store Image
Create Thumbnail
Inform Subscribers
Store raw Image
Store Image Information
1
2
161. AWS Cloud
AWS Step Functions workflow: Store Image
Create Thumbnail
Inform Subscribers
Store raw Image
Store Image Information
1
2
162. AWS Cloud
AWS Step Functions workflow: Store Image
Create Thumbnail
Inform Subscribers
Store raw Image
Store Image Information
1
2
163. AWS Cloud
AWS Step Functions workflow: Store Image
Create Thumbnail
Inform Subscribers
Store raw Image
Store Image Information
1
2
164. AWS Cloud
AWS Step Functions workflow: Store Image
Create Thumbnail
Inform Subscribers
Store raw Image
Store Image Information
1
2
165. AWS Cloud
AWS Step Functions workflow: Store Image
Create Thumbnail
Inform Subscribers
Store raw Image
Store Image Information
1
2
166. AWS Cloud
AWS Step Functions workflow: Store Image
Create Thumbnail
Inform Subscribers
Store raw Image
Store Image Information
1
2
167. AWS Cloud
AWS Step Functions workflow: Store Image
Create Thumbnail
Inform Subscribers
Store raw Image
Store Image Information
1
2
168. Was kann da schon schiefgehen?
• Interne Programmier-/Logikfehler
• Anomalien (z.B. unerwartet/ungültige Calls)
• verlorene oder doppelte Events
• hohe Latenz / Timeouts
• Security-Attacken (z.B. DoS/DDoS)
• Personalisierte SLAs / Usage Plans
• unerwartete Workload Peaks
• …
169. “Run your business code
highly-available
in the cloud in response
to events and scale
without any servers to
manage.“*
*(AWS Lambda product description)
170. “Run your business code
highly distributed
and event driven in a non
transparent environment
with no single
point of control.“*
*(my personal interpretation)
173. Was, wann, wie und wo sollte ich testen, um …
• Vertrauen in meinen Code zu gewinnen
• das Risiko von Fehlern zu minimieren*
* vor allem in Produtktion
175. Testen in der Serverless Welt
„The biggest complexity is not within
the function itself, but in how it interacts
with other functions and services
(a.k.a. cloud components).“
176. Testen in der Serverless Welt
Ziele des Testens: „Risiko minimieren“
• Risiko Konfiguration
• Risiko technischer Workflow
• Risiko Businesslogik
• Risiko Integration
177. Testen in der Serverless Welt
Ziele des Testens: „Risiko minimieren“
• Risiko Konfiguration
• Risiko technischer Workflow
• Risiko Businesslogik
• Risiko Integration
181. „Welche Art von ‚Benchmarks‘ wollen wir für unser Testing?“
• funktionale Änderungen schnell/kosteneffizient testen
• integrative Änderungen schnell/kosteneffizient testen
• integrative Änderungen so „real“ wie möglich testen
• Use-Cases und User-Stories so „real“ wie möglich testen
Testing Best Practices
182. #1 Trennen von Businesslogik und Infrastruktur
Testing Best Practices
AWS CloudOn-Premise
handler
logic
Kandidat für Unit Tests
e
i
u
Kandidat für Integration Tests
Kandidat für End-to-Ende Tests
u
186. #2 Cloud-Infrastruktur Komponenten mocken
Testing Best Practices
AWS CloudOn-Premise
handler
logic u
um
Kandidat für Unit Tests
e
i
u
Kandidat für Integration Tests
Kandidat für End-to-Ende Tests
190. #3 Lokale Umgebung für funktionale Tests verwenden (z.B. SAM local)
Testing Best Practices
AWS CloudOn-Premise
handler
logic uvia SAM local
via SAM local
SAM
yaml
TEST
u
u
Kandidat für Unit Tests
e
i
u
Kandidat für Integration Tests
Kandidat für End-to-Ende Tests
191.
192. $ sam local invoke "Greetings" -e event-greeting.json --env-vars env.json
function name payload for function
193. $ sam local invoke "Greetings" -e event-greeting.json --env-vars env.json
function name payload for function
194. #4 Lokale Umgebung zum Triggern von Integration Tests verwenden
Testing Best Practices
AWS CloudOn-Premise
handler
logic uvia SAM local
via SAM local
SAM
yaml
TEST
u
u
i
i
Kandidat für Unit Tests
e
i
u
Kandidat für Integration Tests
Kandidat für End-to-Ende Tests
198. #5 Lokale Cloud-Komponenten für Integration Tests*
Testing Best Practices
AWS CloudOn-Premise
handler
logic u
via DynamoDB local
via FakeS3 via SAM local
via SAM local
SAM
yaml
TEST
u
u
i
i
i
i
WARNUNG: lokale Cloud
Komponenten können
lediglich funktionale
Korrektheit sicherstellen,
nicht aber infrastrukturelle,
wie z.B. DLQs, Timeouts,
Throttling, SLAs, …
Kandidat für Unit Tests
e
i
u
Kandidat für Integration Tests
Kandidat für End-to-Ende Tests
199. $ sam local generate-event [SERVICE] [OPTION]
Simulate Component Event to trigger Lambda
200. $ sam local genarte-event [SERVICE] [OPTION]
Simulate Component Event to trigger Lambda
204. #6 temporäre Integration-Cloud für partielle Integration Tests
Testing Best Practices
AWS CloudOn-Premise
handler
logic uvia SAM local
via SAM local
SAM
yaml
TEST
u
u
via DynamoDB local
via FakeS3
i
i
Temorary Intregration #Dev1
ii
INT
i
i
Kandidat für Unit Tests
e
i
u
Kandidat für Integration Tests
Kandidat für End-to-Ende Tests
205. #7 permanente Integration-Cloud für End-to-End Tests
Testing Best Practices
AWS CloudOn-Premise
handler
logic uvia SAM local
via SAM local
SAM
yaml
TEST
u
u
via DynamoDB local
via FakeS3
i
i
Permament IntregrationINT
e
e
e
e
i
i
Kandidat für Unit Tests
e
i
u
Kandidat für Integration Tests
Kandidat für End-to-Ende Tests
209. Testing in Produktion
Ziele des Testens: „Vertrauen gewinnen“
• Outages von Cloud & Cloud-Komponenten
• Outages von 3rd Party Apps
• Bugs / Probleme durch Skalierung
210. Testing in Produktion
Robustes Monitoring und Error Reporting
• Logging
• Tracing
• Metrics
• Alerting
Vorhersagen von Störungen
inklusive automatischer
Regenerierung!
213. Mit einem gut geplantes Monitoring sollten wir in der Lage sein, …
• aufkommende Probleme vorherzusagen
• schnell die Ursache von Problemen zu identifizieren
• automatische Recovery-Prozesse anzustoßen
• notwendige Alarme zu triggern
Real-Life Monitoring
215. Gut geplantes Monitoring berücksichtigt verschiedene Aspekte
• reliability: Komponenten und Kommunikation
• usage: funktional und nicht-funktional
• performance: Dauer, Latenz und Timeouts
• security: Zugriffsrechte, Attacken
• costs: aktuelle Kosten, Kostenentwicklung
Real-Life Monitoring
216. Die 4 Säulen des Monitorings
3
2 4
1
Tracing Metrics
Alerting
Logging
217. 3
2
Tracing Metrics
4
4
Alerting
Die 4 Säulen des Monitorings
Repräsentiert den State
einer Anwendung.
Wenn etwas schiefläuft
benötigen wir LOGs, um
herauszufinden, welche
Änderungen am State den
Fehler verursacht haben.
1
Logging
Logging
218. 3
Metrics
4
1
Alerting
Logging
Die 4 Säulen des Monitorings
Tracing
2
Repräsentiert eine
einzelne „User‘s Journey“
durch den gesamten
Stack der Anwendung.
Tracing wird oft zur
Optimierung des Systems
genutzt.
Tracing
219. 2
Tracing
4
1
Alerting
Logging
Die 4 Säulen des Monitorings
3
Metrics
Repräsentiert einen über
einen Zeitraum
aggregierten Messpunkt.
Hilft dabei, den aktuellen
„Health-Status“ des
Systems sowie dessen
Entwicklung festzustellen.
Metrics
220. 3
2
Tracing Metrics
1
Logging
Die 4 Säulen des Monitorings
4
Alerting
Die Komponente des
Monitorings, die
basierende auf Metriken,
Aktionen auslöst.
Meist zur automatischen
„Selbstheilung“ verwendet
oder im zuständige
Personen zu informieren.
Alerting
221. Für ein gut geplantes Monitoring, sollten man daher …
• Events loggen, die eine State Transformation anstoßen
• Standard-Metriken sammeln
• Custom-Metriken definieren und sammeln
• Distributed Tracing ermöglichen
• Alarme auf individuellem und aggregierten Level definieren
Serverless Application Monitoring
239. Monitoring: Lessons Learned
Was haben wir gelernt …
• ein gut durchdachtes Monitoring besteht aus 4 Säulen
• das Logging zum Festhalten von State Transformation
• das Tracing zum Verfolgen einzelner User Journeys
• die Metriken zur Feststellung des Systemzustands
• das Alerting zum (autom.) Auslösen von „heilenden“ Aktionen
242. „Welche Art von ‚Benchmarks‘ wollen wir für unser Monitoring?“
• Sammeln von umfangreichen System- und Anwendungsmetriken
• Metriken und Logs sollten keine User-facing Latency verursachen
• Metriken und Logs sollten in Real-Time verfügbar sein
• Metriken und Logs sollten granular und korreliert vorliegen
Monitoring Best Practices
243. #1 User-facing Latency vermeiden
Monitoring Best Practices
AWS Cloud
My Lambda logs
log
stream
log
data
async
sync
Log Aggregator
log
data
1
very fast and cheap
2
3
time consuming and “expensive”
parse
log stream
244. #2 umfangreiche System-/Anwendungsmetriken sammeln
Monitoring Best Practices
AWS Cloud
My Lambda logs
log
stream
log
data
async
sync
Log Aggregator
metrics
custom
metrics
custom
metrics
log
data
2
3
1
very fast and cheap
parse
log stream
custom
metrics
245. #3 unnötige Kosten vermeiden
Monitoring Best Practices
AWS Cloud
My Lambda logs
log
stream
log
data
async
sync
Log Aggregator
metrics
custom
metrics
custom
metrics
log
data
archive
logs
1
2
custom
metrics
246. #4 Logs und Metriken korrelieren / aggregieren
Monitoring Best Practices
AWS Cloud
My Lambda logs
log
stream
log
data
async
sync
Log Aggregator
metrics
custom
metrics
custom
metrics
log
data
archive
logs
1
correlation
ID
custom
metrics
247. #5 Logging via ENV Vars an Edge Server enablen/disablen
Monitoring Best Practices
AWS Cloud
My Lambda logs
log
stream
log
data
async
sync
Log Aggregator
metrics
custom
metrics
custom
metrics
log
data
archive
logs
DEBUG
on/off
ENV var
1
2
custom
metrics