report.tex

\documentclass[12pt, a4paper]{article}
\usepackage[utf8]{inputenc}
\usepackage{hyperref}
\usepackage[dvipsnames]{xcolor}
\usepackage{graphicx}
\usepackage{listings}
\usepackage{float}
\usepackage{natbib}
\usepackage{acronym}

\graphicspath{{images/}}

% don't allow to split words over separate lines
% \hyphenpenalty 10000
% \exhyphenpenalty 10000
\raggedright

\renewcommand{\figurename}{Figur}



\title{Function as a Service}
\author{Xiang Rong Lin}
\date{06.01.2022}

\begin{document}

\maketitle



\newpage
\tableofcontents

\newpage

\section{Was ist Function as a Service?}
\ac{FaaS} ist einer der neueren Aufteilungen der Verantwortlichkeiten zwischen einem selber und dem Anbieter.
In dieser neuen Form muss man selber nur noch die individuelle Businesslogik implementieren und der Anbieter kümmert sich um die Standardlogik und den Betrieb in der Cloud.
Genauer beschrieben hatte man zuvor drei unterschiedliche Aufgabenbereiche\cite{serverless2017roewekamp}.
\newline
Ersteres ist die Ablaufsteuerung meist in Form eines UI Controller der die Aktionen des Users entgegennimmt und die weitere Geschäftslogik aufruft.
Dies wird direkt vom Anbieter übernommen in Form von unterschiedlichen Triggern.
\newline
Für die standardisierte Geschäftslogik gibt es bereits viele Anbieter, wie Auth0\footnote{https://auth0.com/} für Authentifizierung und Autorisierung oder Phrase\footnote{https://phrase.com/} für die Verwaltung von lokalisierten Texten.
Mit diesen hat man auch hier selber keine direkten Entwickleraufwände.
\newline
Zuletzt hat man dann noch die individuelle Geschäftslogik.
Also die eigentliche Logik mit dem man den Nutzen für die eigenen Kunden schaffen will.
Dieser Teil muss von einem selber implementiert werden.
Als Beispiel kann nach dem Hochladen von Katalogdaten eines Herstellern in ein Amazon S3 Bucket ein Event versendet werden.
Dieser startet den eigenen \ac{FaaS}, welcher den Katalog in das von den Händlern gewünschte Format konvertiert.
Entweder selber oder indirekt indem es einen Konvertierungsservice wie Lobster Data\footnote{https://www.lobster-world.com/en/lobster-data/} mit entsprechenden Parametern triggert.

\subsection{Abgrenzung}
\ac{FaaS} teilt mit den anderen Servicemodellen wie \ac{PaaS}, \ac{BaaS} oder \ac{SaaS} viele Gemeinsamkeiten.
So beginnt es bei \ac{PaaS}, dass man sich keine Gedanken mehr um die Bereitstellung der Laufzeitumgebung sowie das darunterliegenden Betriebssystem und die Hardware machen muss.
Also man muss keine Server physikalisch kaufen und aufbauen, diese nicht einrichten und warten, sowie keine Virtualisierungsumgebung bereitstellen mit der entsprechend benötigten Laufzeitumgebung.
Unterschiede gibt es in der Ausprägung einiger Eigenschaften.
Wo man bei Heroku \cite[pro Monat]{heroku_pricing} abgerechnet wird, geschieht es bei AWS Lambda \cite[pro Millisekunde]{aws_lambda_pricing}.
Dieser Unterschied kommt daher, dass \ac{FaaS} Instanzen sehr kurzlebig sind.
Also sie verarbeiten eine \cite[einzige Anfrage]{aws_lambda_scaling} und werden dann nach einiger Zeit ohne weitere Anfragen wieder gestoppt, wohingegen der Service bei \ac{PaaS} durchgehend läuft.
Diese kurzen Laufzeiten werden zusätzlich noch durch Timeouts erzwungen.
So darf bei \ac{GCP} eine Funktion maximal \cite[9 Minuten]{gcp_timeout} aktiv sein bevor sie beendet wird.
\newline
In der nächsten Stufe \ac{BaaS} übernimmt der Anbieter nun komplett das ganze Backend mit seinen Aufgabenbereichen.
Also Grundlegende Sachen wie der Betrieb selber, aber auch die Skalierung, die Lastverteilung und auch die globale Verfügbarkeit werden übernommen und man selber muss nur noch das Frontend dazu entwickeln.
Dafür verliert man aber auch jegliche Möglichkeit individuelle Anpassungen zu machen, die vom Anbieter nicht durch Konfiguration vorgesehen sind.
\newline
In der letzten Stufe \ac{SaaS} wird der gesamt Service samt Frontend vom Anbieter übernommen.
Man hat also keinerlei Entwickleraufwand mit Ausnahme der Integration in die eigene Systemlandschaft, hat aber noch weniger, bis gar keine Anpassungsmöglichkeiten.
\newline
In diese Lücke der fehlenden Anpassbarkeit kommt genau \ac{FaaS} ins Spiel.
Es bietet eine sehr leichtgewichtige Lösung, da es einem die Anpassbarkeit wie bei \ac{PaaS} bietet, man aber wie bei \ac{BaaS} oder \ac{SaaS} den Aufwand des Serverbetriebs nicht hat.
\newline
In diesem Kontext wird der Begriff Serverless sehr oft mit \ac{FaaS} austauschbar verwendet, was nicht ganz korrekt ist.
\ac{FaaS} ist ein Ausschnitt von Serverless, da es nur compute Ressourcen anbietet.
Kombiniert mit anderen \ac{BaaS} wie Firebase\footnote{https://firebase.google.com/} für Datenbank oder Amazon Simple Queue Service\footnote{https://aws.amazon.com/sqs/} für Messaging kann man erst richtig sagen, dass man Serverless arbeitet.

\section{Wie funktioniert Function as a Service?}
\subsection{Anwendungsentwicklersicht}
Die Funktionsweise aus Sicht des Anwendungsentwicklers wird im \cite[Developer Guide von \ac{AWS}]{awsLambda_devGuide} sehr detailliert dargestellt.
Grundlegend muss man selber nur die Funktion implementieren und einen entsprechenden Trigger festlegen.

Im Java Beispiel implementiert man die Funktion indem man eines der unteren beiden Interfaces implementiert.

\begin{figure}[h]
    \lstinputlisting[language=Java]{code/RequestHandler.java}
    \caption{RequestHandler.java}
    % https://github.com/aws/aws-lambda-java-libs/blob/master/aws-lambda-java-core/src/main/java/com/amazonaws/services/lambda/runtime/RequestHandler.java
\end{figure}

\begin{figure}[h]
    \lstinputlisting[language=Java]{code/RequestStreamHandler.java}
    \caption{RequestStreamHandler.java}
    % https://github.com/aws/aws-lambda-java-libs/blob/master/aws-lambda-java-core/src/main/java/com/amazonaws/services/lambda/runtime/RequestStreamHandler.java
\end{figure}

Der Eingabetyp muss ein primitive Datentyp, String, ein \ac{POJO}, eine Collection davon, ein Stream oder ein AWS spezifisches Event sein und wird per Konfiguration in einer `Event.json' definiert.
Benötigt man zusätzlich noch Zugriff auf Datenbanken, Dateisystem oder andere Services bietet \ac{AWS} Lambda noch zusätzliche Bibliotheken für den Zugriff.
\newline\newline
Als Trigger kann man HTTP Anfragen, Queue Nachrichten, Streams oder andere \ac{AWS} Services verwendet werden.
Tritt nun eines dieser Ereignisse ein, so wird der Handler aufgerufen.
Dies kann synchron ablaufen in welchem Fall das Ereignis direkt vom Client an den Handler weitergegeben wird.
Dies wird beispielsweise bei HTTP Anfragen oft benötigt, da der Benutzer am anderen Ende aktiv auf die Antwort wartet.
\newline
Die bevorzugte Arbeitsweise ist aber asynchron.
Hier wird das Event in eine Warteschlange eingereiht und der Client wartet nicht auf eine Antwort.
Diese Events werden dann nach und nach von den Handlern abgearbeitet.
Diese asynchrone arbeitsweise wird auch als \emph{Event-Driven Architecture} bezeichnet, was viele Vorteile sowie Nachteile mit sich bringt\cite{awsEventDrivenArchitecture}.
Viele davon sind allgemein gültig und nicht nur auf für \ac{FaaS} bezogen.
Die wichtigsten davon sind aber dass die Komponenten unabhängig voneinander entwickelt, betrieben und skaliert werden können.


\subsection{Anbietersicht}
Wie arbeitet aber ein \ac{FaaS} Anbieter, dass dieser den Codestück von oben zum laufen kriegen kann?
\newline
Hierfür kann man sich das Open Source Projekt \cite[OpenFaaS]{openfaas_github} genauer anschauen.
Es verspricht eine viel weniger restriktive Lösung gegenüber den kommerziellen Lösungen von Amazon, Google und co.
Kubernetes wird als Grundtechnologie verwendet, was einem erlaubt jegliche Anwendung zu verwenden, die in einem Container laufen kann.
Mit Kubernetes kommt auch die automatische Skalierung, aber vor allem auch die Unabhängigkeit von Cloud Anbieter, da Kubernetes verglichen mit \ac{FaaS} ein viel älteres und somit stärker standardisiertes Modell ist.
\newline
Vor allem hat man aber vollen Zugriff zum Source Code und kann anhand des \emph{Template Store}\cite{openfaas_templateStore} genau sehen wie ein \ac{FaaS} Provider implementiert ist.
Die Templates bestehen aus 4 Teilen aus denen ein lauffähiges Docker Images erstellt wird, welche am Java 11 HTTP Beispiel \cite{openfaas_templateStore_java11} hier aufgeführt werden.
\newline
Als erstes hat man das Dockerfile mit der die Applikation gebaut wird und anschließend in einer minimalen Laufzeitumgebung gestartet wird.
\newline
Dabei erhält die Applikation Anfragen nicht direkt sondern über den \emph{of-watchdog}\cite{openfaas_ofWatchdog}.
Dies ist ein HTTP Server von OpenFaaS, der als reverse proxy zum ausführen der Funktionen dient.
Es gibt verschiedene Operationsmodi die entweder dynamisch skaliert werden können über Systemprozesse und dann über STDIO kommunizieren oder in unseren Fall eine 1:1 Beziehung haben und über http auf dem localhost kommunizieren.
Der Vorteil des \emph{of-watchdog} im HTTP Modus ist, dass einmalige Initialisierungen und langlebige Verbindungen wie eine Datenbank für die komplette Lebenszeit des Containers nur einmal Kosten verursachen und nicht für jede Anfrage.
\newline
Als zweites hat man einen \emph{Entrypoint}, welches die Anfragen vom \emph{of-watchdog} entgegennimmt. Im Java 11 Beispiel ist es ein sehr leichtgewichtiger HTTP Server, welches die Anfragen an den \emph{Handler} weiterreicht.
\newline
Dieser Handler ist der dritte Teil, welcher vom Anwendungsentwickler implementiert werden muss, wie zuvor beschrieben.
\newline
Der letzte Teil ist die \emph{Package list}.
Hier werden die Abhängigkeiten der Applikation definiert mithilfe des jeweiligen Paketmanagement System der Sprache.
In diesem Fall Gradle für Java.
\newline
Genutzt werden die Templates wenn man sich ein Vorlage generieren lässt mit dem CLI von OpenFaaS.
Mit "faas-cli new --lang java11 <name>" erhält man ein Java/Gradle Projekt mit den obigen Teilen in Gradle als Abhängigkeiten definiert und einer leeren Handler Klasse.
Also genau so wie es bei  auch der Fall ist.
\newline
Insgesamt ist es also wie ein Microservice, wo einem aber viele Entscheidungen schon abgenommen wurden, sodass man sich nur auf die individuelle Businesslogik konzentrieren muss.

\section{Einschränkungen}
\subsection{Latenz}
Wie man zuvor gesehen hat, ist die Funktion im Endeffekt auch Microservice, aber auf das extreme minimiert.
Hier muss also zum bearbeiten einer weiteren Anfrage, eine neuen Instanz und somit ein komplett neuer Service hochgefahren werden, statt wie in einem üblichen Servermodell, nur einen weiteren Thread zu starten.
\newline
Dieser Overhead muss entsprechend bezahlt werden.
Bei AWS wird es erfreulicherweise von AWS selbst übernommen, da man selber nur für die Zeit zahlt in der der Code ausgeführt wird \cite{aws_lambda_pricing}, was also nicht die Zeit zum Hochfahren beinhaltet.
Dieser Fall ist der worst case und wird als \emph{Cold Boot} bezeichnet.
Im besten Fall gibt es bereits eine Instanz, die nur inaktiv ist, womit man somit den ganzen Overhead durch das starten vermeidet.
Die Kosten der inaktiven Instanz übernimmt man auch nicht, dafür hat aber AWS selbst die Kontrolle wie lange eine Instanz inaktiv bleiben darf, bevor sie beendet wird.
Benchmarks von 2019 zufolge kann dies bis zu einer Stunde sein \cite{aws_lambda_idle_timeout}, was aber nur Funktionen mit kleineren Speicherbedarf erreichen.
\newline
Muss die Latenz konsistent gering sein, so kann man bei AWS mit \emph{Provisioned Concurrency} sicherstellen, dass eine Mindestanzahl an Funktionen immer initialisiert sind\cite{aws_lambda_provisioned_concurrency}.
Dies ist aber mit extra Kosten verbunden und macht den Kostenvorteil der Skalierung nach unten zu Nichte.

\subsection{Memory overhead}
Ein weiterer Nachteil dadurch, dass es effektiv Microservices sind, ist der Speicherverbrauch.
In der Java Welt ist es allseits bekannt, dass die \ac{JVM} sehr viel Arbeitsspeicher benötigt.
Dies ist hier sehr ausschlaggebend, wo jede Anfrage seine eigene Instanz der Funktion hat mit seiner eigenen \ac{JVM}.
Eine simple Funktion, welche nur mit "Hello World" antwortet, benötigt bei OpenFaaS während der Inaktivität mit Java 11 50MB Arbeitsspeicher, wohingegen GO, welches zu nativen Maschinen Code kompiliert, nur 5MB Arbeitsspeicher benötigt.
\newline
Dieser Overhead der JVM zeigt sich höchstwahrscheinlich auch im CPU Verbrauch bei der Initialisierung, was aber nicht überprüft wurde.
Nichts desto trotz zahlt man selbst für diese extra 45MB Arbeitsspeicher während der Ausführung und der Anbieter während der Inaktivität.

\subsection{Tests}
Tests sind ein wichtiger Bestandteil fast aller gut wartbarer Software.
Vor allem, dass man sie auch jederzeit lokal und aus der Build Umgebung ausführen kann.
Unit Tests lassen sich relativ einfach umsetzen mit etwas Aufwand bei der Abstraktion der Interfaces des Anbieters.
\newline
Integrationstests hingegen sind da etwas schwerer bei kommerziellen Anbietern, da man selber nur den Handler implementiert und alles außen herum vom Anbieter bereitgestellt wird.
Vor allem also die Konvertierung der HTTP Anfrage in das vom Handler gewünschte Datenformat und das Aufrufen davon mit dem korrekten Kontext.
Hierfür haben die verschiedenen Anbieter aber Emulatoren bereit gestellt.
Im Beispiel von AWS, ist es ein leichtgewichtiger Webserver, welche die HTTP Anfragen in JSON Events umwandelt\cite{aws_lambda_rie}.
Dieser umfasst aber nicht die Orchestrierung, Security und Authentifizierung, welche aber teilweise aus dem Arbeitsbereich der Integrationstests hinausfällt.
\newline
Will man in einer Umgebung testen, die der Produktion gleich ist, so bleibt einem nur übrig direkt gegen den Anbieter zu testen.
Dies birgt viele Schwierigkeiten, da man eventuell eigene Microservices lokal laufen hat, die Funktion aber beim Anbieter läuft und sich mit der lokalen Instanz verbinden muss.
Des Weiteren bezahlt man nun jedes Mal wenn ein Tests durchläuft.
\newline
Dies ist allgemein aber kein neues Problem, sondern schon bei \ac{BaaS} und \ac{SaaS} der Fall, von wo man sich auch Lösungsansätze abschauen kann.

\subsection{Asynchronität}
Es wird empfohlen \ac{FaaS} für asynchrone statt synchrone Services zu verwenden.
Ein Grund hierfür ist die zuvor erwähnte Latenz von einem \emph{Cold Boot}, also wenn eine Instanz komplett neu hochgefahren werden muss.
Verbunden damit dass man oft weitere Funktionen/Services aufrufen muss, wartet und bezahlt man somit diese Latenz.
Diese Kosten können sehr schnell sehr hoch werden, da die Preise bei \ac{FaaS} höher sind, aber durch die Skalierung nach unten man trotzdem insgesamt weniger zahlt.
Wenn man die Preise pro Stunde für jeweils zwei GB RAM und einer virtuellen CPU für AWS Lambda und AWS EC2 On-Demand vergleicht, so hat man bei AWS Lambda einen fast fünffach höhere Kosten (0,11988\$/h vs 0,0255\$/h)\cite{aws_lambda_pricing}\cite{aws_ec2_pricing}\cite{aws_lambda_memory_cpu}.

\subsection{Koreographie vs Orchestration}
Mit der asynchronen Arbeitsweise kommen eine Reihe weiterer Einschränkungen.
So sollte man statt der Orchestrierung der Services durch eine zentrale Stelle, diese selber agieren lassen basierend auf Events.
Dies hängt teils mit oberen Punkt zusammen, da der orchestrierende Service durchgehend laufen muss, Anbieter aber einen Timeout von wenigen Minuten haben (9 Minuten bei \ac{GCP}\cite{gcp_function_timeout}).
So triggert ein zentraler Service nicht Service B nachdem Service A fertig ist, sondern Service A versendet ein Event, welches Service B empfängt und damit arbeitet.
Dies bietet eine sehr lose Koppelung mit seinen Vorteilen wie der besseren Wartbarkeit und Austauschbarkeit.
Aber hiermit kommt auch eine enorme Erhöhung der Komplexität, da man eben nicht mehr diese zentrale Stelle hat um sich einen Überblick vom Gesamtprozess zu schaffen.
Dazu gibt es auch viele neue Arten von Fehlern, wie Teilausfälle und nicht Erreichbarkeit.
Dies ist aber allgemein ein Problem von der Ereignisorientierten Entwicklung, wofür es bereits Lösungsansätze gibt.

\subsection{Begrenzte Laufzeitumgebungen}
Verwendet man nicht einer der populären Programmiersprachen in einer aktuellen Version, wird man bei manchen Anbietern auf Probleme stoßen.
Wie man OpenFaaS gesehen hat sind Funktionen im Endeffekt Microservices für die der Anbieter ein Template erstellt hat.
Gibt es kein Template in der gewünschten Sprache und Version hat man oft wenige Möglichkeiten außer auf diese zu wechseln.
So bietet zum Beispiel \ac{GCP} Java nur in der Version 11 an \cite{gcp_function_runtimes} und \ac{AWS} gar kein PHP\cite{aws_lambda_runtimes}.
\newline
\ac{AWS} bietet dafür alternativ einen Möglichkeit an einen eigene Runtime zu entwickeln, ähnlich zu OpenFaaS.
Dies bringt aber mit sich den Entwicklungsoverhead, den man sich durch \ac{FaaS} eigentlich sparen will.

\subsection{Komplett Zustandslos}
Dass ein Service selber keinen Zustand speichern soll ist nichts Neues, sondern war schon beim Umstieg von Monolithen auf Microservices, eines der großen Anpassungen, die man machen sollte.
Bei Microservices hatte man aber trotzdem noch die Möglichkeit diese Empfehlung zu ignorieren, da man selber die Kontrolle hatte über den Start und Stopp des Service.
Mit \ac{FaaS} hat man nicht nur diese Möglichkeit nicht mehr, sondern hat auch effektiv keinen lokalen temporären Speicher mehr, der als Cache verwendet werden kann.

\subsection{Vendor Lock in}
Die Gefahr, dass man sich bei der Implementierung zu sehr auf anbieterspezifische Eigenschaften einlässt ist schon bei anderen Servicemodellen vorhanden, hier aber besonders groß.
So stellt der Anbieter das Interface für die Funktion und die entsprechenden Bibliotheken zur Verfügung, um sehr komfortabel mit weiteren System im Ökosystem des Anbieters zu kommunizieren.
Dieses Risiko kann aber umgangen werden, indem man die Anbieterspezifischen Details abstrahiert und somit der Kern der Businesslogik beliebig auf andere Portale übertragen werden kann und nur die Integration an den Anbieter anpassen muss.
Ob dieser Aufwand auf gerechtfertigt ist, ist eine andere Frage.
Ansonsten hat man auch schon bei OpenFaaS gesehen, dass es alternativen gibt mit Docker und Kubernetes.

\section{Vorteile}
Alle Eigenschaften von Cloud Computing, wie sie von \ac{NIST} beschrieben werden, treffen zu\cite{mell2011nist}.
\subsection{On demand self service}
Wie auch bei anderen Servicemodellen kann man selbstständig neue Funktionen hinzufügen um somit lange Wartezeiten zu vermeiden.
Dies verbunden mit dem verringerten Overhead der Serverimplementation und Konfiguration bieten einem eine sehr schnellen Entwicklungszyklus und somit eine viel kürzere Zeit um Produkte auf dem Markt zu bringen und Ihre Werthaltigkeit auszutesten.

\subsection{Broad network access}
Für die Interaktion mit andere Services innerhalb des Ökosystems des Anbieters gibt es auch Bibliotheken und zahlreiche Ressourcen.
Für Unternehmen die sich nicht vor dem \emph{Vendor Lock In} fürchten, bietet dies eine enorme Zeitersparnis.
Ansonsten kann man mit den Funktionen über standardisierte HTTP Schnittstellen oder Events kommunizieren.

\subsection{Rapid Elasticity}
Gegenüber anderen Modellen ist die Skalierung bei \ac{FaaS} schon direkt mit inbegriffen und sogar der Möglichkeit auf Null Instanzen herunter zu skalieren.
Das Hochskalieren ist leicht schneller durch die Leichtgewichtigkeit der Services und beim herunterskalieren, bezahlt man selber bereits nach dem eintreten der Inaktivität nicht mehr.

\subsection{Measured Services}
Die verwendeten Ressourcen werden viel feingranularer abgerechnet.
Vergleicht man AWS Lambda mit AWS EC2 On-Demand, so wird einerseits in Millisekunden statt Sekunden abgerechnet.
Andererseits kann man bereits mit einer Instanz mit nur 128MB RAM und umgerechnet circa \(\frac{1}{14}\) einer virtuellen CPU starten, statt mit 500MB RAM und einer ganzen virtuellen CPU.
Also ein riesiger finanzieller Vorteil für Services mit unregelmäßigen oder sehr geringen Lastprofilen oder zum initialen austesten von Prototypen.

\subsection{Resource Pooling}
Die benötige Hardware für die Maximalkapazität braucht man selber auch nicht bereitstellen.
Dies wird komplett von Anbieter übernommen, welche aber diese Maximalkapazität für alle Kunden bereitstellen muss.
Trotzdem kann der Anbieter einen Vorteil hieraus ziehen durch den Skaleneffekt.
Durch die Masse an benötigter Hardware kann er individuelle Vereinbarung mit Herstellern treffen und auch den physikalischen Standort günstig wählen, um von kühleren Klima oder günstigen Strom zu profitieren.

\section{Fazit}
Insgesamt ist Function as a Service also nur ein weiteres Servicemodell wie die anderen auch mit seinen eigenen Vorteilen auf Kosten gewisser Einschränkungen.
Diese muss man je Situation gegeneinander abwägen und selber eine Entscheidung treffen ob \ac{FaaS} das richtige Mittel zum Zweck ist.
Allgemein ist es besser geeignet für kurze Aufgaben, welche sich asynchron abarbeiten lassen und einen unregelmäßiges Lastprofil haben um von der automatischen Skalierung profitieren zu können.
Es steht einen aber offen mit \ac{FaaS} zu experimentieren, da man nur ein sehr geringes finanzielles Startkapital benötigt, durch die feingranulare Abrechnung und der extrem niedrigen Funktionsgrößen.

\newpage

\section{Abkürzungen}
\begin{acronym}
 \acro{NIST}{National Institute of Standards and Technology}
 \acro{SaaS}{Software as a Service}
 \acro{PaaS}{Plattform as a Service}
 \acro{BaaS}{Backend as a Service}
 \acro{FaaS}{Function as a Service}
 \acro{POJO}{plain old Java object}
 \acro{AWS}{Amazon Web Services}
 \acro{GCP}{Google Cloud Plattform}
 \acro{JVM}{Java Virtual Maschine}
\end{acronym}
\newpage

\bibliography{./sources}
\bibliographystyle{abbrv}

\end{document}

% Wie ist die Architektur zwischen verschiedenen Funktionen

% potentielle Ansätze
% 	Vorteil von Cloud Anbietern/Cloud Kunde
% 	was ist asynchrone schlecht
% 	komplexizitätsgrenze von Programme zb durch Asynchronität

% Einleitung muss nicht entfernt werden, aber besser erklären bzgl cloud computing eigenschaften

% Begrenzungen bei AWS:
% 	bestimmte sprachen

% Design Pattern für Serverless suchen

% 15m präsentation 5-8slides