Mysterium Serverless – Ein Ausflug in die Welt von Serverless-Architekturen – Teil 1

  • Serverless-Architekturen drängen sich zunehmend auch in IT-Landschaft
  • Serverless ist weit mehr als reines Ausführen von Programmiercode und mittlerweile auf viele Komponenten erweitert worden
  • Alle großen Cloud-Anbieter stellen mittlerweile mindestens einen Serverless-Dienst bereit
  • Serverless Frameworks versuchen die Portabilität zwischen den Anbietern zu erhöhen

Wer träumt nicht davon, jederzeit Programme ausführen zu können und Rechenleistung zu konsumieren, ohne vorher dafür Server zu provisionieren oder Kapazität reservieren zu müssen? Diesem Traum ein Stück näher kommt man mit dem Serverless Computing/Infrastruktur Ansatz - so das Versprechen der großen Cloud-Plattformen. Das Serverless Computing Paradigma folgt dabei 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 kleinen Softwarekomponenten nicht besonders groß und komplex sind. Vielmehr geht es um die Konzipierung von kleinen Bausteinen, die eine spezifische Aufgabe erfüllen können, wie das gerne genutzte Beispiel ein Bild zu verkleinern und zu beschneiden, bevor es dann wieder gespeichert wird.

Die zwei Seiten der Medaille

Was ist es für die Cloud Anbieter?

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 eigene Ressourcen und die Auslastung der Systeme entsprechend zu optimieren. Damit können dann Kosteneinsparung 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 für die breite Nutzerschicht bereit. Es folgten dann 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.

Was ist es für die Nutzer?

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, etc. 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 sinnvoll für Einsatzszenarien, wo ich die Last nicht permanent auf meiner Architektur habe, diese aber dann schon sehr stark sein kann, wenn die Nutzung erfolgt. Ein Beispiel ist die Nutzung von persönlichen Assistenten wie Siri, Alexa und Co.. Diese werden durch ein Aktivierungswort hellhörig und stellen dann erst die Anfrage an den Server. Wenn die Interaktion fehlt, dann 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.

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.

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 preparieren, dass die Nutzung mittels einer sehr kurzen Reaktionszeit erfolgen kann.

Charakteristiken

Die Charakteristiken von Serverless Architekturen sind nicht auf die Programmlogik fokussiert. Weitere Charakteristika reihen sich ein:

  • 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. Man bekommt neben automatischer Skalierung und Fehlertoleranz, der schnellen Bereitstellung der Ressourcen eine exakte nutzungsabhängige Abrechnung der Ressourcen. Die Gefahren auf der anderen Seite beinhalten den 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 geht hier zum Nachteil des Lock-ins auf Ebene der Programmiersprache. Dennoch ist es ein sehr sinnvoller Ansatz - zumindest für eine Komponente von Serverless-Architekturen.