Cloud Architekturen - von "less Server" zu Serverless

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

ÜBER OPEN KNOWLEDGE
Branchenneutrale Softwareentwicklung & IT-Beratung

Ü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)

Mein Server
und ich ...
„The Nightmare“

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

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

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

#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

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

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

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

„Kein Server ist
einfacher zu
verwalten, als
kein Server.“
SERVERLESS

The Road to the Cloud ...
Der Serverless Showcase

Road to less Server
Self-Managed Cloud-Managed

Road to less Server
Provisioning
Security
Maintenance

Road to less Server
Sieht irgendwie kompliziert
aus! Muss ich mich darum
kümmern?
Provisioning
Security
Maintenance

Road to less Server
Elastic
Beanstalk
Elastic
Kubernetes
Elastic
Container
Provisioning
Security
Maintenance
Scaling

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

Road to less Server
IaaS
ECS : elastic container service

Road to less Server
IaaS
EKS : elastic container service for kubernetes

Road to less Server
Provisioning
Security
Maintenance
Scaling

Road to less Server
Provisioning
Security
Backup/Recovery
Scaling
Provisioning
Security
Maintenance
Scaling

Road to less Server
IaaS

Road to less Server
PaaS
(Platform as a Service)

Business Logic
(... as a Service)

Das Versprechen
von Serverless

“Run YOUR business
code in the cloud.“

Das klappt niemals!
Warum nicht?

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

Road to less Server
API Key Mgmt
Throtteling
Zero-Downtime
Region Availability
Provisioning
Security
Backup/Recovery
Scaling
Provisioning
Security
Maintenance
Scaling

Road to less Server
BaaS
(Backend as a Service)

PaaS IaaS
Road to less Server
?

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

#2:
No servers to
provision or manage

#3:
Build in high availability
and disaster recovery

#4:
Scale with usage
by design

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

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

„Kein Server ist
einfacher zu
verwalten, als
kein Server.“
out-of-the-box self-scaling
out-of-the-box
self-scaling
cloud-based
super-backend
Remember
„your“ dreams?

Functions als Basis für
Deployment
& Skalierung

Road to less Server
FaaS
(Function as a Service)

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

Cloud Architekturen - von "less Server" zu Serverless

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

Was ist die Idee
von Serverless?

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

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

AWS Cloud
1
trigger
request
Hands-on: Hello World

AWS Cloud
hello world serverless context
1
trigger
request

AWS Cloud
hello world serverless context
HelloWorld
Logs
1
trigger
request
2

Was passiert da
unter der Haube?

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

HelloWorld
ZIP
1
trigger
request
Download
Function Code
ZIP
Cloud Storage
S3
AWS Cloud
2

HelloWorld
ZIP
1
trigger
request
Download
Function Code
Setup
Runtime
ZIP
Cloud Storage
S3
AWS Cloud
2 3

HelloWorld
ZIP
1
trigger
request
Download
Function Code
Setup
Runtime
Init
Function
ZIP
Cloud Storage
S3
AWS Cloud
2 3 4

HelloWorld
ZIP
1
trigger
request
Download
Function Code
Setup
Runtime
Init
Function
ZIP
Cloud Storage
S3
AWS Cloud
2 3 4
COLD START

trigger
request
Download
Function Code
ZIP
AWS Cloud
Setup
Runtime
Init
Function
COLD START

trigger
request
Download
Function Code
ZIP
AWS Cloud
Setup
Runtime
Init
Function
COLD START
Execute
Handler

trigger
request
Download
Function Code
ZIP
AWS Cloud
Setup
Runtime
Init
Function
COLD START
Execute
Handler
Terminate
Function

trigger
request
ZIP
AWS Cloud
COLD START
Terminate
Function
Execute
Handler

trigger
request
ZIP
AWS Cloud
COLD START
Terminate
Function
Execute
Handler
Execute
Handler
trigger
request

trigger
request
ZIP
AWS Cloud
COLD START
Execute
Handler
Terminate
Function
Execute
Handler
Execute
Handler
trigger
request
trigger
request

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

AWS Cloud
1
upload
image

AWS Cloud
1 2
upload
image

AWS Cloud
Store raw Image
StoreImage
Logs
1 2
3
upload
image

AWS Cloud
Store raw Image
StoreImage
Logs
S3 Object
created1 2
3
4
upload
image

AWS Cloud
Create ThumbnailStore raw Image
StoreImage
Logs
CreateThumbnail
Logs
S3 Object
created1 2
3
4
5
upload
image

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

Szenario #2: Stream Processing
Regelmäßiges abarbeiten von Streaming Data
• Social Media Trendanalysen
• Sensor Data Monitoring / Anomaly Detection

AWS Cloud
1
sensor data stream is
uploaded to Kinesis
in real-time
tons of
very important
sensor data

AWS Cloud
Data Stream Analysis
StreamAnalyzer
Logs
1
uploaded to Kinesis
in real-time
2
Lambda runs code to
detect anomalies
tons of
very important
sensor data

AWS Cloud
StreamAnalyzer
Logs
store anomalies
extracted by lambda
function
1
uploaded to Kinesis
in real-time
2
3
Lambda runs code to
detect anomalies
tons of
very important
sensor data

AWS Cloud
StreamAnalyzer
Logs
Real-Time Monitoring / Querying
store anomalies
extracted by lambda
function
1
uploaded to Kinesis
in real-time
2
3
Lambda runs code to
detect anomalies
4
data immediately
available for interested
parties to query
tons of
very important
sensor data

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

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)

AWS Cloud
Web Client
region aware
web app
delivery
1

AWS Cloud
Web Client
region aware
web app
delivery
1
login via id/pwd
returns JWT
2

AWS Cloud
Web Client
region aware
web app
delivery
1
login via id/pwd
returns JWT
2
3
REST
call

AWS Cloud
Web Client
region aware
web app
delivery
1
login via id/pwd
returns JWT
2
3
REST
call
4
translated
lambda
trigger

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

AWS Cloud
Web Client
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

AWS Cloud
Web Client
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

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

Web Image Gallery
(not so easy version)
POST ../images/

Web Image Gallery
(real life version)
POST ../images/

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

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

AWS Cloud
Wofür ist ein API Gateway gut?
• Security
• API Key Handling
• Throttling
• Proxying
• Logging / Tracing
• Request / Respons Mapping
• Staging

AWS Cloud
1
Szenario #4: API Gateway
GET ../resources/{resourceId}
PUT ../resources/{resourceId}
DELETE ../resources/{resourceId}
POST ../resources/

AWS Cloud
21
POST ../resources/

AWS Cloud
read
create
delete
update
21
3
POST ../resources/

AWS Cloud
read
create
delete
update
56 4
POST ../resources/

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

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

AWS Cloud
Store raw Image
1
upload image
with additional
information

AWS Cloud
Store raw Image
Store Image Information
1
2
upload image
with additional
information

AWS Cloud
AWS Step Functions workflow: Store Image
Store raw Image
1
2
upload image
with additional
information

AWS Cloud
Create ThumbnailStore raw Image
1
2
upload image
with additional
information

AWS Cloud
Create Thumbnail
Inform Subscribers
Store raw Image
1
2
upload image
with additional
information

„Was kann
da schon
schiefgehen?“

AWS Cloud
Create Thumbnail
Inform Subscribers
Store raw Image
1
2

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
• …

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

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

Wie teste ich?
meine Serverless Application

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

Testen in der traditionellen Welt

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

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

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

„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

#1 Trennen von Businesslogik und Infrastruktur
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

#2 Cloud-Infrastruktur Komponenten mocken
AWS CloudOn-Premise
handler
logic u
um
e
i
u

fake infrastructure component (Context)

mock infrastructure component (Context)

#3 Lokale Umgebung für funktionale Tests verwenden (z.B. SAM local)
AWS CloudOn-Premise
handler
logic uvia SAM local
via SAM local
SAM
yaml
TEST
u
u
e
i
u

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

#4 Lokale Umgebung zum Triggern von Integration Tests verwenden
AWS CloudOn-Premise
handler
via SAM local
SAM
yaml
TEST
u
u
i
i
e
i
u

$ sam local start-api –p 8080

#5 Lokale Cloud-Komponenten für Integration Tests*
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, …
e
i
u

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

$ sam local genarte-event [SERVICE] [OPTION]
Simulate Component Event to trigger Lambda

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

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

#6 temporäre Integration-Cloud für partielle Integration Tests
AWS CloudOn-Premise
handler
via SAM local
SAM
yaml
TEST
u
u
via DynamoDB local
via FakeS3
i
i
Temorary Intregration #Dev1
ii
INT
i
i
e
i
u

#7 permanente Integration-Cloud für End-to-End Tests
AWS CloudOn-Premise
handler
via SAM local
SAM
yaml
TEST
u
u
via DynamoDB local
via FakeS3
i
i
Permament IntregrationINT
e
e
e
e
i
i
e
i
u

„Sind wir endlich
fertig?“

Testing endet nicht
in Produktion!

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

Robustes Monitoring und Error Reporting
• Logging
• Tracing
• Metrics
• Alerting
Vorhersagen von Störungen
inklusive automatischer
Regenerierung!

Chaos Engineering
• bewusst kleine “Probleme“ und „Fehler“ in
das System einstreuen!

Wie monitore ich?
meine Serverless Application

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

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”

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

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

3
2
Tracing Metrics
4
4
Alerting
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

3
Metrics
4
1
Alerting
Logging
Tracing
2
Repräsentiert eine
einzelne „User‘s Journey“
durch den gesamten
Stack der Anwendung.
Tracing wird oft zur
Optimierung des Systems
genutzt.
Tracing

2
Tracing
4
1
Alerting
Logging
3
Metrics
Repräsentiert einen über
einen Zeitraum
aggregierten Messpunkt.
Hilft dabei, den aktuellen
„Health-Status“ des
Systems sowie dessen
Entwicklung festzustellen.
Metrics

3
2
Tracing Metrics
1
Logging
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

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

Monitoring Strategie
AWS Cloud
Logging
Tracing
Metrics
Alerting

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

AWS Cloud
universal Log
Logging
Logging
Tracing
Metrics
Alerting

AWS Cloud
universal Log
Logging
DevOps
Logging
Tracing
Metrics
Alerting

AWS Cloud
universal Log
Archive
Logging
Tracing
DevOps
Logging
Tracing
Metrics
Alerting

AWS Cloud
universal Log
Archive
Logging Metrics
Tracing
DevOps
Logging
Tracing
Metrics
Alerting

AWS Cloud
universal Log
Alarm
Archive
Logging Metrics
Tracing
Alerting
DevOps
Logging
Tracing
Metrics
Alerting

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

AWS Cloud
Logging
Alerting
Metrics
“BASIC ALERTING FOR FREE”
“BASIC METRICS FOR FREE”
Logging
Tracing
Metrics
Alerting

AWS Cloud
Alarm
Logging
Alerting
Metrics
Logging
Tracing
Metrics
Alerting

AWS Cloud
Logging
Alerting
Metrics
Tracing (still DIY)
Alarm
Metrics
Logging
Tracing
Metrics
Alerting

AWS Cloud
Alarm
Logging
Tracing
Alerting
Tracing (DIY)
Metrics
Logging
Tracing
Metrics
Alerting

Logging
Tracing
Metrics
Alerting

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

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

„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

#1 User-facing Latency vermeiden
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

#2 umfangreiche System-/Anwendungsmetriken sammeln
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

#3 unnötige Kosten vermeiden
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

#4 Logs und Metriken korrelieren / aggregieren
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

#5 Logging via ENV Vars an Edge Server enablen/disablen
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

Schlussfolgerung: Spaß haben mit
Serverless?

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

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

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

© 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

Cloud Architekturen - von "less Server" zu Serverless

Weitere ähnliche Inhalte

Was ist angesagt? (20)

Ähnlich wie Cloud Architekturen - von "less Server" zu Serverless (20)

Mehr von OPEN KNOWLEDGE GmbH (18)

Cloud Architekturen - von "less Server" zu Serverless