Das Dokument thematisiert Cloud-Architekturen im Kontext von serverlosen Konzepten, wobei der Fokus auf den Vorteilen der Vermeidung von Serververwaltung liegt. Es werden verschiedene Ansätze zur Implementierung von serverlosen Technologien skizziert, einschließlich IaaS, PaaS und FaaS, sowie Beispiele für spezifische Anwendungsfälle wie Datenbearbeitung und Streaming. Die Präsentation betont die Agilität, Kostenersparnis und Innovationsmöglichkeiten, die mit der Nutzung serverloser Lösungen verbunden sind.

1. #WISSENTEILEN
Cloud Architekuren
Von „less Server“ zu Serverless
Lars Röwekamp | open knowledge GmbH
@_openKnowledge | @mobileLarson

2. ÜBER OPEN KNOWLEDGE
Branchenneutrale Softwareentwicklung & IT-Beratung

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)

4. Mein Server
und ich ...

5. Mein Server
und ich ...
„The Nightmare“

6. #WISSENTEILEN
Server Q&A„Dinge, über die ich mir Gedanken machen sollte!“

7. #WISSENTEILEN
#Servers:
#Customer:
#Traffic:
#Security:
Anzahl? OS? Storage? CPU? Memory?
Start small! Grow fast! Die faster?
Moderat, aber mit Peaks?
OS? Patches? Access Control?

8. “We have to be great at a number of things…
operating data centers is not one of those things.”

9. I had a
dream ...

10. #WISSENTEILEN
#LaborCost:
#Risk:
#ResourceCost:
#Scaling:
#LeadTime:
DIY? Nein, danke!
Risiko liegt zu 100% beim Provider
nur zahlen, was ich nutze
on-the-fly Up- und Down-Scaling
neue System stehen „sofort“ zur Verfügung

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

12. Aber warum
ICH?

13. #1
Agilität

14. #2
Plattform

15. #3
Kosten

16. #4
Innovationen

17. “We are a hospitality management
organization, not an IT services company.”

18. 80 Mio Gäste / 1500 EC2
„We have a 5 person operations team.”

19. „Kein Server ist
einfacher zu
verwalten, als
kein Server.“
(Werner Vogels, CTO Amazon)
SERVERLESS

20. The Road to
less Server?

21. The Road to the Cloud ...
Der Serverless Showcase

22. Road to less Server

23. IaaS
Road to less Server

24. Road to less Server
Self-Managed Cloud-Managed

25. Road to less Server
Self-Managed Cloud-Managed
Provisioning
Security
Maintenance

26. Road to less Server
Self-Managed Cloud-Managed
Provisioning
Security
Maintenance

27. Road to less Server
Sieht irgendwie kompliziert
aus! Muss ich mich darum
kümmern?
Self-Managed Cloud-Managed
Provisioning
Security
Maintenance

28. Road to less Server
Self-Managed Cloud-Managed
Elastic
Beanstalk
Elastic
Kubernetes
Elastic
Container
Provisioning
Security
Maintenance
Scaling

29. Road to less Server
IaaS
(Infrastructure as a Service)
EBS: elastic beanstalk

30. Road to less Server
IaaS
(Infrastructure as a Service)
ECS : elastic container service

31. Road to less Server
IaaS
(Infrastructure as a Service)
EKS : elastic container service for kubernetes

32. IaaS
Road to less Server

33. IaaSPaaS
Road to less Server

34. Road to less Server
Self-Managed Cloud-Managed
Provisioning
Security
Maintenance
Scaling

35. Road to less Server
Self-Managed Cloud-Managed
Provisioning
Security
Backup/Recovery
Scaling
Provisioning
Security
Maintenance
Scaling

36. Road to less Server
IaaS
(Infrastructure as a Service)

37. Road to less Server
PaaS
(Platform as a Service)

38. IaaSPaaS
Road to less Server

39. Business Logic
(... as a Service)

40. Das Versprechen
von Serverless

41. “Run YOUR business
code in the cloud.“

42. Das klappt niemals!

43. Das klappt niemals!
Warum nicht?

44. Das klappt niemals!
Warum nicht?
Na, weil es
DEIN
Business
Code ist!

45. IaaSPaaS
Road to less Server

46. PaaS IaaS
Road to less Server

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)

51. Road to less Server
BaaS
(Backend as a Service)

52. Road to less Server
BaaS
(Backend as a Service)

53. Road to less Server
BaaS
(Backend as a Service)

54. PaaS IaaS
Road to less Server
?

55. PaaS IaaS
Road to less Server

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

57. #1:
Run your
business code

58. #2:
No servers to
provision or manage

59. #3:
Build in high availability
and disaster recovery

60. #4:
Scale with usage
by design

61. Management:
“Hmm, ich bin noch
nicht überzeugt!.”

62. #5:
Never pay idle
(Management: „Ok, I bin definitiv dabei!“)

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?

64. My Logic
(... as a Service)

65. Function
(... as a Service)

66. Functions als Basis für
Deployment
& Skalierung

67. Road to less Server
PaaS
(Platform as a Service)

68. Road to less Server
FaaS
(Function as a Service)

69. Run Code,
not Server?

70. No machines, VMs,
or containers.
*... are visible in the programing model

72. Big
Players?

73. AWS
Lambda Microsoft
Azure Functions
Oracle Functions
a.k.a. Project FN***
IBM Cloud Functions
a.k.a Apache OpenWhisk**
Google Cloud
Functions
Project Riff
sponsored by Pivotal

76. Serverless in a Nutshell

77. Was ist die Idee
von Serverless?

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

80. > Hands-On

82. AWS Cloud
1
trigger
request
Hands-on: Hello World

83. AWS Cloud
hello world serverless context
1
trigger
request
Hands-on: Hello World

84. AWS Cloud
hello world serverless context
HelloWorld
Logs
1
trigger
request
2
Hands-on: Hello World

85. Was passiert da
unter der Haube?

86. 1
trigger
request
Hello World „under the Hood“
AWS Cloud

87. HelloWorld
ZIP
1
trigger
request
Hello World „under the Hood“
Download
Function Code
ZIP
Cloud Storage
S3
AWS Cloud
2

88. HelloWorld
ZIP
1
trigger
request
Hello World „under the Hood“
Download
Function Code
Setup
Runtime
ZIP
Cloud Storage
S3
AWS Cloud
2 3

89. HelloWorld
ZIP
1
trigger
request
Hello World „under the Hood“
Download
Function Code
Setup
Runtime
Init
Function
ZIP
Cloud Storage
S3
AWS Cloud
2 3 4

90. HelloWorld
ZIP
1
trigger
request
Hello World „under the Hood“
Download
Function Code
Setup
Runtime
Init
Function
ZIP
Cloud Storage
S3
AWS Cloud
2 3 4
COLD START

91. trigger
request
Hello World „under the Hood“
Download
Function Code
ZIP
AWS Cloud
Setup
Runtime
Init
Function
COLD START

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

94. trigger
request
Hello World „under the Hood“
ZIP
AWS Cloud
COLD START
Terminate
Function
Execute
Handler

95. trigger
request
Hello World „under the Hood“
ZIP
AWS Cloud
COLD START
Terminate
Function
Execute
Handler
Execute
Handler
trigger
request

96. trigger
request
Hello World „under the Hood“
ZIP
AWS Cloud
COLD START
Execute
Handler
Terminate
Function
Execute
Handler
Execute
Handler
trigger
request
trigger
request

97. Serverless
Szenarien

98. Szenario
#1

99. Szenario #1: Datei-/Datenbearbeitung
Datei- oder Datenbearbeitung nach Ablage im S3 Storage System
• Bildbearbeitung
• Thumbnail-Erzeugung
• PDF-Generierung

100. AWS Cloud
Szenario #1: Datei-/Datenbearbeitung
1
upload
image

101. AWS Cloud
Szenario #1: Datei-/Datenbearbeitung
1 2
upload
image

102. AWS Cloud
Store raw Image
Szenario #1: Datei-/Datenbearbeitung
StoreImage
Logs
1 2
3
upload
image

103. AWS Cloud
Store raw Image
Szenario #1: Datei-/Datenbearbeitung
StoreImage
Logs
S3 Object
created1 2
3
4
upload
image

104. AWS Cloud
Store raw Image
Szenario #1: Datei-/Datenbearbeitung
StoreImage
Logs
S3 Object
created1 2
3
4
upload
image

105. AWS Cloud
Create ThumbnailStore raw Image
Szenario #1: Datei-/Datenbearbeitung
StoreImage
Logs
CreateThumbnail
Logs
S3 Object
created1 2
3
4
5
upload
image

106. > File Processing

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

109. Szenario
#2

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

116. > Stream Processing

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

119. Szenario
#3

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

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 …)
?

135. Szenario
#4

136. Scenarios
#3
API Gateway

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/

140. AWS Cloud
read
create
delete
update
21
Szenario #4: API Gateway
3
GET ../resources/{resourceId}
PUT ../resources/{resourceId}
DELETE ../resources/{resourceId}
POST ../resources/

141. AWS Cloud
read
create
delete
update
Szenario #4: API Gateway
56 4
GET ../resources/{resourceId}
PUT ../resources/{resourceId}
DELETE ../resources/{resourceId}
POST ../resources/

142. > API Gateway

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

145. Reality Check

146. The Road to the Cloud ...
Der Serverless Showcase

147. AWS Cloud
Use-Case: Upload Image
upload image
with additional
information

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

157. „Was kann
da schon
schiefgehen?“

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)

172. Wie teste ich?
meine Serverless Application

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

174. Testen in der traditionellen Welt

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

178. Testen in der Serverless Welt

179. „Don‘t let your users
test your code!“

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

183. Infrastructure Business Logic

184. Infrastructure Business Logic

185. Business Logic Tests

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

187. Infrastructure

188. fake infrastructure component (Context)

189. mock infrastructure component (Context)

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

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

195. $ sam local start-api –p 8080

196. $ sam local start-api –p 8080

197. $ sam local start-api –p 8080

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

201. Simulate Component triggered by Lambda
$ aws –endpoint-url=http://localhost:8000 dynamodb list-tables
$ java –jar DynamoDBLocal.-jar

202. Simulate Component triggered by Lambda
$ aws –endpoint-url=http://localhost:8000 dynamodb list-tables

203. Simulate Component triggered by Lambda
$ aws –endpoint-url=http://localhost:8000 dynamodb list-tables

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

206. „Sind wir endlich
fertig?“

208. Testing endet nicht
in Produktion!

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!

211. Testing in Produktion
Chaos Engineering
• bewusst kleine “Probleme“ und „Fehler“ in
das System einstreuen!

212. Wie monitore ich?
meine Serverless Application

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

214. Real-Life Monitoring
Business
KPI
UX
SLA
“Produkte
pro Bestellung”
“Durchschnittlicher
Bestellwert”
“Abbruchrate”
“Erste Darstellung
von Inhalten”
“Erste sinnvolle
Darstellung"
“Erste
Interaktion”
“Verfügbarkeit”
“Latenz”
“Beständigkeit”
“Konsistenz”

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

222. Monitoring Strategie
AWS Cloud
Logging
Tracing
Metrics
Alerting

223. Monitoring Strategie #1: DIY
AWS Cloud
Logging
Tracing
Metrics
Alerting

224. Monitoring Strategie #1: DIY
AWS Cloud
universal Log
Logging
Logging
Tracing
Metrics
Alerting

225. Monitoring Strategie #1: DIY
AWS Cloud
universal Log
Logging
DevOps
Logging
Tracing
Metrics
Alerting

226. Monitoring Strategie #1: DIY
AWS Cloud
universal Log
Archive
Logging
Tracing
DevOps
Logging
Tracing
Metrics
Alerting

227. Monitoring Strategie #1: DIY
AWS Cloud
universal Log
Archive
Logging Metrics
Tracing
DevOps
Logging
Tracing
Metrics
Alerting

228. Monitoring Strategie #1: DIY
AWS Cloud
universal Log
Alarm
Archive
Logging Metrics
Tracing
Alerting
DevOps
Logging
Tracing
Metrics
Alerting

229. Monitoring Strategie #2: Plattform Services
AWS Cloud
Logging
Logging
Tracing
Metrics
Alerting

230. Monitoring Strategie #2: Plattform Services
AWS Cloud
Logging
Alerting
Metrics
“BASIC ALERTING FOR FREE”
“BASIC METRICS FOR FREE”
Logging
Tracing
Metrics
Alerting

231. Monitoring Strategie #2: Plattform Services
AWS Cloud
Alarm
Logging
Alerting
Metrics
Logging
Tracing
Metrics
Alerting

232. Monitoring Strategie #2: Plattform Services
AWS Cloud
Logging
Alerting
Metrics
Tracing (still DIY)
Alarm
Metrics
Logging
Tracing
Metrics
Alerting

233. Monitoring Strategie #2: Plattform Services
AWS Cloud
Alarm
Logging
Tracing
Alerting
Tracing (DIY)
Metrics
Logging
Tracing
Metrics
Alerting

234. Monitoring Strategie #2: Plattform Services
Logging
Tracing
Metrics
Alerting

235. Monitoring Strategie #2: Plattform Services
Logging
Tracing
Metrics
Alerting

236. Monitoring Strategie #2: Plattform Services
Logging
Tracing
Metrics
Alerting

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

240. „Logging data is expensive,
so better log wisely!“

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

248. #WISSENTEILEN
Fazit

249. Schlussfolgerung: Spaß haben mit
Serverless?

250. “Find suitable
serverless workload
and apply the correct
integration patterns.”

251. “Eat your own
serverless dog food
for monitoring
and testing“

253. ? ? ?

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

255. © chanchai howharn – shutterstock.com (Folie 1)
© wavebreaker – shutterstock.com (Folie 4)
© Rich Vintage – iStockphoto.com (Folie 9)
© foxaon1987 - shutterstock.com (Folie 11)
© Guide van Nipsen – wikipedia.com (Folie 19)
© Zeeker2526 - shutterstock.com (Folie 20)
© CandyDuck - shutterstock.com (Folie 80)
© Myvisual - shutterstock.com (Folie 97)
© Rawpixel.com - shutterstock.com (Folie 241)
Alle weiteren Bilder der Präsentation sind entweder von pixabay.com
oder von mir selbst erstellt.
Bildernachweis