Das Serverless Computing Paradigma folgt einem Programmiermodell und einer Architektur, bei der kleine Softwarekomponenten basierend auf einem Event aktiviert und ausgeführt werden. Der Kunde hat dabei jedoch keinerlei Kontrolle darüber, auf welchem Server beispielsweise sein Programm ausgeführt wird. Die Bezeichnung "Functions" in einigen Produktnamen deutet schon an, dass die Softwarekomponenten nicht besonders groß und komplex sind. Vielmehr geht es um die Konzipierung von kleinen Bausteinen, die eine spezifische Aufgabe erfüllen können, beispielsweise ein Bild verkleinern und beschneiden, bevor es dann wieder gespeichert wird.
Foto: Billion Photos - shutterstock.com
Serverless Computing aus Anbietersicht
Aus der Perspektive der Cloud-Anbieter ist eine Serverless-Infrastruktur eine zusätzliche Möglichkeit, einen kompletten Anwendungsstack für den Endkunden zur Verfügung zu stellen. Dies ermöglicht ihm, die eigenen Ressourcen und die Auslastung der Systeme entsprechend zu optimieren. Damit können Kosteneinsparungen einhergehen, wenn man die Nutzung der Infrastruktur entsprechend gut prognostizieren kann.
Im November 2014 stellte AWS mit dem Produkt AWS Lambda die erste Public-Cloud-Version von Serverless Computing bereit. Es folgten im Februar 2016 Google mit Google Functions und im März 2016 Microsoft mit Azure Functions. Mittlerweile bieten alle großen Public-Cloud-Provider diese Möglichkeit für die eigenen Kunden an.
Serverless-Ansatz aus Nutzersicht
Aus Sicht des Nutzers ergibt sich zunächst ein vereinfachtes Programmiermodell, welches so ziemlich alles abstrahiert, was zur Ausführung des Programms notwendig ist. Der Nutzer braucht sich keinerlei Sorgen machen über Rechner, Firewalls, Netzwerkkonfigurationen, Installationen, Updates und ähnliches. Auch entstehen für den Nutzer nur dann Kosten, wenn der Programmcode tatsächlich ausgeführt wird. Ansonsten steht der Zähler still. Dies ist besonders in solchen Einsatzszenarien sinnvoll, wo die Last nicht permanent auf einer Architektur liegt. Im Falle der Nutzung kann sie aber schon sehr hoch sein. Ein Beispiel sind persönliche Assistenten wie Siri, Alexa und Co. Sie werden durch ein Aktivierungswort hellhörig und stellen dann erst die Anfrage an den Server. Wenn die Interaktion fehlt, entstehen auch keine Kosten. Auf den ersten Blick klingt dies zu gut für den Kunden, um wahr zu sein. Doch mit den Vorteilen gehen natürlich auch Nachteile einher, wie weiter unten beschrieben wird.
Foto: Quelle: Crisp Research 2017
Serverless-Komponenten
Wie baut man sich als Anbieter eine Serverless-Architektur?
Man benötigt die folgenden Zutaten:
Möglichkeit zur Entgegennahme von Events
Warteschlange zum Sammeln von Events
Möglichkeit zur Festlegung einer bestimmten Strategie für die mittel- und langfristigen Prozessorzuteilung
Rechner, die den Programmcode bzw. die kurze Funktion ausführen können
Mit diesen "simplen" Zutaten kann man dann eine recht performante Serverless Architektur aufbauen.
Foto: Quelle: Crisp Research 2017
Eine Quelle von Ereignissen löst dabei den Ausführungswunsch von Programmcode, basierend auf diesem Ereignis, aus. Die Ereignisse werden in eine Warteschlange gelegt und von dort abgerufen. Der Dispatcher oder Scheduler verteilt dann den Ausführungswunsch auf die zur Verfügung stehenden Ressourcen. Die kleinen Funktionen oder sehr kleinen Microservices werden dann im letzten Schritt ausgeführt.
Mit dieser Basisrezeptur können Hersteller dann weitere Dienste im eigenen Portfolio abseits der reinen Rechenleistung anreichern und beispielsweise Abfragedienste, Warteschlangen, Benachrichtigungsdienste, Datenbanken etc. so präparieren, dass die Nutzung mittels einer sehr kurzen Reaktionszeit erfolgen kann.
Charakteristiken
Die Charakteristiken von Serverless-Architekturen sind nicht auf die Programmlogik fokussiert. Weitere Charakteristika offenbaren nicht nur Vorteile, sondern auch Einschränkungen:
Kosten: Diese entstehen tatsächlich nur bei der Nutzung des Dienstes und ggf. für die Persistenz nach der Ausführung
Performance: Da die Ressourcen in geeignetem Umfang vorgehalten werden und die Funktionen möglichst direkt ausgeführt werden können, ist die Performance entsprechend hoch.
Limitierungen: Bei der Programmierung und der Nutzung ist der Entwickler beschränkt in der vertikalen Ausgestaltung der genutzten Ressourcen. Beispielsweise sind CPU und Memory entsprechend beschränkt und können nicht beliebig aufgestockt werden.
Programmiersprachen: Auch hier sind die Entwickler auf ein kleineres Set von Programmiersprachen festgelegt. In der Regel werden von den Plattformen Node.js, Python, Go und C# unterstützt. Damit sind jedoch auch schon viele populäre Sprachen inbegriffen und dementsprechend viele Entwickler zufrieden.
Programmiermodell: Da es sich in der Regel um eine kleine Funktion oder einen sehr kleinen Microservice handelt, muss der Entwickler sich dementsprechend bei der Architektur der Anwendung darauf einstellen, mehr Komponenten zu verteilen und parallel ausführen zu lassen.
Komposition: Die Komposition von einzelnen Serverless-Komponenten ermöglicht dem Entwickler auf der anderen Seite eine gute Möglichkeit, ganze Architekturen aus Serverless-Komponenten zu komponieren.
Sicherheit: Serverless Plattformen sind, wie in der Grafik weiter oben zu sehen, als Multi-tenant-Umgebung konzipiert, um den gewünschten Kosten- und Ressourcenvorteil auf Anbieterseite zu erzielen. Daher muss der Entwickler für die Sicherheit und Isolation der Daten und der Nutzer entsprechend Rechnung tragen.
Monitoring und Debugging: Eine Serverless Architektur zu debuggen ist nicht so trivial, wie man vielleicht bei allen Vorteilen vermuten könnte. Ein einfaches Debugging ist bei vielen der großen Plattformen bereits integriert, dies ist aber weit entfernt von den Möglichkeiten, die Entwicklertools heutzutage bieten. Jedoch beschränkt sich der Umfang des Codes natürlich auch auf weniger Zeilen, als bei komplexen Anwendungen.
Frameworks für Serverless-Architekturen
Die Vorteile überwiegen bei der Nutzung von Serverless Architekturen, wenn man die Einsatzbereiche für diese mächtige Technologie verstanden hat. Unternehmen profitieren neben der automatischen Skalierung und Fehlertoleranz auch von einer schnellen Bereitstellung der Ressourcen und einer exakten nutzungsabhängige Abrechnung der Ressourcen. Zu den Gefahren zählt dagegen ein Vendor Lock-in auf einem sehr hohen Level.
Um diesen Nachteil zu minimieren, gibt es einige Initiativen und Anbieter, die versuchen, ein Framework zur Portierung von Code über verschiedene Anbieter hinweg zu ermöglichen. Exemplarisch sei hier das Node.js-basierte Serverless Framework angeführt. Dieses bietet Unterstützung für AWS, Microsoft Azure, Apache OpenWhisk und Google Cloud Functions. Der Vorteil der Portabilität wird hier zwar mit dem Nachteil des Lock-ins auf Ebene der Programmiersprache erkauft. Dennoch ist es ein sehr sinnvoller Ansatz - zumindest für eine Komponente von Serverless-Architekturen.