Serverless Computing: „All inclusive“ Services aus der Cloud

In diesem Artikel lesen Sie,

• was Serverless Computing bedeutet,  
• welche Vorteile Serverless Computing gegenüber Containern hat und  
• mit welchem Service Sie „serverless“ auf der Open Telekom Cloud arbeiten können.

Es sind nicht nur Autos, die immer häufiger „software-definiert“ über die Straßen rollen. Viele Funktionen in verschiedensten Endgeräten werden über Software realisiert. Diese kommt entweder aus dem Netz oder ist fest in den Geräten integriert. „Software makes the world go round“, möchte man resümieren oder wie Marc Andreessen formulierte: „Software is eating the world.“ 

In einer Welt, in der immer mehr Abläufe von Software gesteuert werden, wird die schnelle Bereitstellung von software-definierten Services zu einer Königsdisziplin für Unternehmen. Viele aktuelle IT-Trends zielen darauf ab, Entwickler zu entlasten und Software-Entwicklung effizienter sowie schneller zu machen. Dazu zählen beispielsweise agile Entwicklungsmethoden oder das Recycling von erfolgreichem Code. Auf der anderen Seite bedeutet DevOps, dass Software-Entwickler immer häufiger auch über den Entwicklungstellerrand in Richtung Betrieb schauen müssen. Das wiederum erhöht die Arbeitslast.

Die Cloud hat ihre Meriten, wenn es darum geht, Software modern zu entwickeln und schnell bereitzustellen. Nicht umsonst hat sie sich zuerst im Umfeld der Entwickler etabliert. Komplette Entwicklungs- und Testumgebungen minutenschnell bereitgestellt, justiert auf die Bedürfnisse des Entwicklers, oder Projektmanagement für kollaborative Entwicklung aus der Cloud sind heute gang und gäbe.

Entwicklung aus der Cloud ist eine Seite der Medaille, der Betrieb von Applikationen die andere. So elegant der Einsatz der Cloud ist: Immer müssen Entwickler auch einen Blick auf Infrastrukturen werfen. Welche Ressourcen sind für einen optimalen (d.h. leistungsfähigen und kosteneffizienten) Betrieb nötig? Wäre es nicht ein Riesenvorteil, diese Diskussion ein für alle Mal zu beenden? Ressourcen, die automatisch passend bereitgestellt werden, ohne dass Infrastrukturkomponenten ausgesucht, zugeordnet, konfiguriert etc. werden müssen?

„Serverless“ oder Function as a Service (FaaS) lautet die Antwort auf diese Frage. Mithilfe von FaaS oder Serverless greifen Entwickler (und später Nutzer) auf gebrauchsfertige Komplettservices zu. Sie können diese aus Bibliotheken auswählen und ihrer Applikation hinzufügen. Diese („all inclusive“) Services kümmern sich selbstständig um alles, was sie für einen optimalen Betrieb brauchen – auch um die passenden Infrastrukturen.

Abstraktion von Infrastrukturressourcen – dieser Wunsch ist so alt wie die Cloud selbst. Serverless Computing ist auch nicht die einzige Lösung, um sich von der manuellen Bereitstellung oder dem Klicken auf einer Management-Konsole zu lösen. Häufig haben sich dafür Container durchgesetzt. Doch Container und Serverless Computing sind zwei unterschiedliche Ansätze, um Applikationen in der Cloud bereitzustellen und zu betreiben. Beide haben ihre Vor- und Nachteile. Hier die Unterschiede:

• Beim Einsatz von Containern werden Container-Images erstellt und auf einer Container-Orchestrierungsplattform wie Kubernetes oder Docker bereitgestellt und verwaltet. Diese Aufwände entfallen beim Serverless Computing.
• Wer Container einsetzt, muss sich um die Verwaltung der Skalierung auf Cluster-Ebene kümmern. Serverless Computing automatisiert die Skalierung auf Funktionsebene („all inclusive“).
• Container sind optimal für kontinuierlich laufende Anwendungen und Prozesse, während „serverlose“ Funktionen in der Regel besser geeignet sind für kurze, ereignisgesteuerte Aufgaben mit begrenzten Ausführungszeiten („adhoc“).
• Für Container wird in der Regel entsprechend der zugewiesenen Ressourcen bezahlt, egal, ob diese gebraucht oder nicht gebraucht werden. Serverless Computing wird entsprechend der tatsächlichen Anfragen und der Dauer der Ausführung bezahlt.

Serverlose Funktionen können theoretisch beliebig komplexe Aufgaben übernehmen. In der Regel werden sie für Standard-Aufgaben in Bibliotheken wie GitHub oder in Software Development Kits vorgehalten. Darüber hinaus haben Entwickler jederzeit die Möglichkeit, eigene Funktionen der Bibliothek hinzuzufügen. 

Ein typisches Beispiel für eine mögliche Funktion: Eine Applikation wird in der Cloud betrieben. Im Rahmen der Nutzung müssen Anwender Bilder in einen Object Storage hochladen. Damit sie kontrollieren können, ob sie die korrekten Bilder hochgeladen haben, sollen sie eine Preview mit Thumbnails erhalten. Statt den Service selbst zu entwickeln, greift der Entwickler der Applikation auf eine Funktion aus einer Bibliothek zurück. Die Funktion wird ausgelöst, wenn Bilder hochgeladen werden („Trigger“). Sie wird mit dem Object Storage gekoppelt und zeigt die Thumbnails in Echtzeit an. Darüber hinaus könnte eine weitere Funktion an den Upload-Trigger gekoppelt werden: Die zweite Funktion hält einen KI-basierten Service für die Bilderkennung vor, der den Bildern automatisch Schlagworte hinzufügt. Nach dem Upload wird die Funktion direkt beendet. Alle damit verbundenen Ressourcen werden abgeschaltet.

Mit FunctionGraph bietet auch die Open Telekom Cloud die Möglichkeit, serverlose Funktionen „as a Service“ zu nutzen. In der Bibliothek werden Funktionen wie Kafka oder GaussDB standardmäßig vorgehalten.  

Aber FunctionGraph bietet vor allem Entwicklern die Möglichkeit, ihren eigenen Code ablaufen zu lassen, ohne dafür Server bereitstellen oder managen zu müssen. Entwickler müssen nur ihren Code hochladen und Bedingungen für dessen Ausführung einstellen. FunctionGraph besorgt den Rest.

• Code schreiben in Node.js, Python, Java, C#, PHP oder Go
• Code hochladen als zip- oder jar-Datei. Entwickler haben die Möglichkeit, den Code inline zu editieren
• Einstellen der Trigger-Funktionen entweder als API-Call oder als Cloud Service Event
• Auto Scaling: FunctionGraph skaliert automatisch auf Basis der Anfragen an die Funktion, ohne dass dafür irgendwelche Konfigurationen erforderlich wären
• Monitoring: Run-Logs der Funktionen werden im Log Tank Service gesammelt
• Über den Service Application Operations Management können die Logs vom Entwickler eingesehen und ausgewertet werden
• Die Abrechnung erfolgt auf Basis der Menge und der Dauer der Aufrufe der Funktion

Mit der Bereitstellung einer eigenen Funktion innerhalb einer Bibliothek gewinnen Entwickler nicht nur die Möglichkeit, selbst schneller und bequemer zu entwickeln, sondern auch eigene Funktionen als Services am Markt anzubieten. FunctionGraph wird so ein Wegbereiter für neue Geschäftsmodelle.