Believing the analysts Serverless Computing will be the “next big thing”. Thanks to NoOps, writing a serverless function and bringing it to production is quite easy. And also combining some of them to build up a more complex system seems to be not too complicated at all. But what are suitable scenarios for Serverless Computing? When to favor serverless over other architectural approaches and when not? Are there any specific patterns to be aware of when applying serverless? How does the serverless paradigm influence the software lifecycle, e.g. testing and monitoring? A lot of open questions to be answered!

1. #WISSENTEILEN
Serverless
Lars Röwekamp | open knowledge GmbH
@_openKnowledge | @mobileLarson
The Missing Manual

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. Was ist die Idee
von Serverless?

5. #WISSENTEILEN
Run code, not servers
Serverless Function: Entwickler schreibt eine Business-
Funktion, „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.
“

6. #WISSENTEILEN
No machines, VMs or containers*
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).
“

8. > Hands-On

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

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

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

13. #WISSENTEILEN
“Run your business code
highly-available
in the cloud in response
to events and scale
without any servers to
manage.“*
* AWS Lambda Advertising

14. #1:
Run your
business code

15. #2:
No servers to
provision or manage

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

17. #4:
Scale with usage
by design

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

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

20. Big
Players?

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

23. Serverless
Szenarien

24. Szenario
#1

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

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

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

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

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

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

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

32. Szenario
#2

33. Szenario #3: Stream Processing
Regelmäßiges Abarbeiten von Streaming Data
• Social Media Trendanalysen
• Sensor Data Monitoring / Anomaly Detection

34. AWS Cloud
1
sensor data stream is
uploaded to Kinesis
in real-time
Szenario #3: Stream Processing
tons of
very important
sensor data

35. AWS Cloud
1
sensor data stream is
uploaded to Kinesis
in real-time
Szenario #3: Stream Processing
tons of
very important
sensor data

36. 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 #3: Stream Processing
tons of
very important
sensor data

37. 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 #3: Stream Processing
tons of
very important
sensor data

38. 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 #3: Stream Processing
tons of
very important
sensor data

39. Szenario
#3

40. Szenario #4: Web Application
Serverless „all in“ einer Anwendung…
• Ausliefern von statischem Content via CDN
• Authentication / Autorization via BaaS
• Businesslogik via FaaS (unter Verwendung von PaaS)

41. Szenario #4: Web Application
AWS Cloud
Web Client
region aware
web app
delivery
1

42. Szenario #4: Web Application
AWS Cloud
Web Client
region aware
web app
delivery
1
login via id/pwd
returns JWT
2

43. Szenario #4: Web Application
AWS Cloud
Web Client
region aware
web app
delivery
1
login via id/pwd
returns JWT
2
3
REST
call

44. Szenario #4: 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

45. Szenario #4: 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

46. Szenario #4: 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

47. Szenario #4: 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

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

49. Web Image Gallery
(easy version)
GET ../images/{imageId}
PUT ../images/{imageId}
DELETE ../images/{imageId}
POST ../images/

50. Web Image Gallery
(not so easy version)
GET ../images/{imageId}
PUT ../images/{imageId}
DELETE ../images/{imageId}
POST ../images/

51. Web Image Gallery
(real life version)
GET ../images/{imageId}
PUT ../images/{imageId}
DELETE ../images/{imageId}
POST ../images/

52. Reality Check

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

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

55. AWS Cloud
Store raw Image
1
Use-Case: Upload Image
upload image
with additional
information

56. AWS Cloud
Store raw Image
Store Image Information
1
2
Use-Case: Upload Image
upload image
with additional
information

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

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

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

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

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

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

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

64. „Was kann
da schon
schiefgehen?“

65. AWS Cloud
AWS Step Functions workflow: Store Image
Create Thumbnail
Inform Subscribers
Store raw Image
Store Image Information
1
2

66. AWS Cloud
AWS Step Functions workflow: Store Image
Create Thumbnail
Inform Subscribers
Store raw Image
Store Image Information
1
2

67. AWS Cloud
AWS Step Functions workflow: Store Image
Create Thumbnail
Inform Subscribers
Store raw Image
Store Image Information
1
2

68. AWS Cloud
AWS Step Functions workflow: Store Image
Create Thumbnail
Inform Subscribers
Store raw Image
Store Image Information
1
2

69. AWS Cloud
AWS Step Functions workflow: Store Image
Create Thumbnail
Inform Subscribers
Store raw Image
Store Image Information
1
2

70. AWS Cloud
AWS Step Functions workflow: Store Image
Create Thumbnail
Inform Subscribers
Store raw Image
Store Image Information
1
2

71. AWS Cloud
AWS Step Functions workflow: Store Image
Create Thumbnail
Inform Subscribers
Store raw Image
Store Image Information
1
2

72. AWS Cloud
AWS Step Functions workflow: Store Image
Create Thumbnail
Inform Subscribers
Store raw Image
Store Image Information
1
2

73. AWS Cloud
AWS Step Functions workflow: Store Image
Create Thumbnail
Inform Subscribers
Store raw Image
Store Image Information
1
2

74. AWS Cloud
AWS Step Functions workflow: Store Image
Create Thumbnail
Inform Subscribers
Store raw Image
Store Image Information
1
2

75. „Run Code,
not Servers!“

76. “Run your business code
highly-available
in the cloud in response
to events and scale
without any servers to
manage.“*
*(AWS Lambda product description)

77. “Run your business code
highly distributed
and event driven in a non
transparent environment
with no single
point of control.“*
*(my personal interpretation)

79. Wie teste ich?
meine Serverless Application

80. Was, wann, wie und wo sollte ich testen, um …
• Vertrauen in meinen Code zu gewinnen
• das Risiko von Fehlern zu minimieren*
* vor allem in Produktion

81. Testen in der traditionellen Welt

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

83. Testen in der Serverless Welt
Ziele des Testens: „Risiko minimieren“
• Risiko Konfiguration
• Risiko technischer Workflow
• Risiko Businesslogik
• Risiko Integration

84. Testen in der Serverless Welt
Ziele des Testens: „Risiko minimieren“
• Risiko Konfiguration
• Risiko technischer Workflow
• Risiko Businesslogik
• Risiko Integration

85. Testen in der Serverless Welt

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

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

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

90. Infrastructure Business Logic

91. Infrastructure Business Logic

92. Business Logic Tests

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

94. Infrastructure

95. AWS agnostic logger (log4j2)

96. fake infrastructure component (Context)

97. mock infrastructure component (Context)

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

100. $ sam local invoke "Greetings" -e event-greeting.json --env-vars env.json
function name payload for function

101. $ sam local invoke "Greetings" -e event-greeting.json --env-vars env.json
function name payload for function

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

103. $ sam local start-api –p 8080

104. $ sam local start-api –p 8080

105. $ sam local start-api –p 8080

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

107. $ sam local generate-event [SERVICE] [OPTION]
Simulate Component Event to trigger Lambda

108. $ sam local generate-event [SERVICE] [OPTION]
Simulate Component Event to trigger Lambda

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

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

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

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

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

114. „Sind wir endlich
fertig?“

116. Testing endet nicht
in Produktion!

117. Testing in Produktion
Ziele des Testens: „Vertrauen gewinnen“
• Outages von Cloud & Cloud-Komponenten
• Outages von 3rd Party Apps
• Bugs / Probleme durch Skalierung

118. Testing in Produktion
Robustes Monitoring und Error Reporting
• Logging
• Tracing
• Metrics
• Alerting
Vorhersagen von Störungen
inklusive automatischer
Regenerierung!

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

120. Wie monitore ich?
meine Serverless Application

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

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

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

124. Die 4 Säulen des Monitorings
3
2 4
1
Tracing Metrics
Alerting
Logging

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

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

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

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

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

130. Monitoring Strategie
AWS Cloud
Logging
Tracing
Metrics
Alerting

131. Monitoring Strategie: Plattform Services
AWS Cloud
Logging
Logging
Tracing
Metrics
Alerting

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

133. Monitoring Strategie: Plattform Services
AWS Cloud
Alarm
Logging
Alerting
Metrics
Logging
Tracing
Metrics
Alerting

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

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

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

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

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

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

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

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

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

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

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

146. Schlussfolgerung: Spaß haben mit
Serverless?

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

148. ? ? ?

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