Im Prinzip ist es nichts Besonderes, wenn Cloud-Anbieter ständig eine neue Sau durchs Dorf treiben. Die aktuelle Sau hört auf den Namen "Serverless Infrastructure" oder auch "Serverless Computing". Das Außergewöhnliche daran ist jedoch, dass sie einige Verwirrung stiftet. Ist nun das Ende der Server angebrochen? Bei weitem nicht - viel mehr verschiebt sich innerhalb des Cloud-Stacks mal wieder etwas weiter nach oben.
Serverless Infrastructure - was ist das eigentlich?
Wie der Name bereits vermuten lässt, wird im Rahmen einer "Serverless Infrastructure" tatsächlich auf den direkten Einsatz von Servern verzichtet. Diese arbeiten als physikalischer Host oder virtuelle Ressource selbstverständlich weiterhin im Hintergrund, schließlich müssen Programmcode und Daten irgendwo gespeichert und betrieben werden. Allerdings muss sich ein Entwickler nicht mehr direkt mit den Servern beschäftigen, er kann sie sogar vollständig vernachlässigen. Stattdessen übernimmt der Cloud-Service eines Anbieters in Form einer "Blackbox" die Arbeit. Der Entwickler lädt seinen Code hoch und der Cloud-Service übernimmt die vollständige Administration der dafür benötigten Serverinfrastruktur inklusive der Server- und Betriebssystemwartung.
Klingt bekannt, oder? Auf den ersten Blick erscheint das "Serverless"-Konzept wie der Ansatz des Platform-as-a-Service (PaaS). Betrachtet man es jedoch etwas genauer, fallen eindeutige Unterschiede zu einem PaaS auf.
Während der Nutzung eines PaaS muss ein Entwickler innerhalb seines Programmcodes mit den APIs des PaaS interagieren, um im Bedarfsfall die notwendige Skalierbarkeit und Ausfallsicherheit der Anwendung sicherzustellen. Konkret fügt die darunterliegende (für ihn nicht sichtbare) Serverinfrastruktur entsprechende Ressourcen hinzu und gibt diese anschließend wieder frei. Der Entwickler muss also eng mit der Plattform selbst kommunizieren. Innerhalb einer "Serverless Infrastructure" übernimmt dies vollständig eine Blackbox in Form eines Cloud-Service. Das bedeutet, dass der Serverless-Service sich um die Bereitstellung der notwendigen Server und weiterer Ressourcen kümmert und zu jeder Zeit sicherstellt, dass die Anwendung ständig ausreichend Ressourcen zur Verfügung hat, um performant Anfragen zu beantworten. Der Cloud-Service organisiert hierbei unter anderem die automatische Skalierung der Server-Infrastruktur, des Speichers, des Netzwerks und anderer Ressourcen und übernimmt somit eigenständig das Kapazitätsmanagement.
Neben dem Hochladen des eigenen Programmcodes muss ein Entwickler noch sogenannte "Funktionen" schreiben. Eine Funktion beschreibt, wie auf ein Ereignis, etwa das Hochladen eines Bildes, reagiert werden soll. Beispielsweise könnte automatisch ein bestimmter Filter darauf angewendet werden. So lassen sich etwa auch vom Anbieter bereitgestellte Microservices oder Platform-Services ansprechen sowie externe oder selbst entwickelte Services integrieren. Serverless Computing wird daher auch oft im selben Atemzug mit dem Begriff "Event-Driven" genannt.
Foto: Crisp Research AG, 2016
Wer über Programmiererfahrung verfügt, dem wird diese Idee bekannt vorkommen. Prozeduren und Funktionen werden schon seit jeher geschrieben, welche dann über einen Event-Handler auf Ereignisse reagieren und entsprechende Aktionen einleiten bzw. ausführen. Eine Serverless Infrastructure lässt sich daher gut als eine fertige "Event Processing Engine" innerhalb einer Blackbox beschreiben. Allerdings muss man festhalten, dass Serverless-Funktionen zustandslos sind. Das bedeutet, dass sie keine Abhängigkeit von der darunterliegenden Infrastruktur besitzen. Damit lassen sich innerhalb kürzester Zeit viele Kopien einer einzelnen Funktion starten, die man benötigt, um die notwendige Skalierbarkeit zu einem bestimmten Zeitpunkt als Reaktion auf ein Ereignis zu erreichen. So ist es etwa kein Geheimnis, dass der Support der Amazon Web Services (AWS) für eine extreme Skalierung den AWS Load Balancer (Amazon ELB) manuell "vorwärmen" muss, damit dieser große unerwartete Lastspitzen verarbeiten kann. Mit dem AWS Serverless-Service AWS Lambda lässt sich dieses Problem automatisiert lösen.
Eine weitere Eigenschaft eines Serverless-Service liegt in dessen Abrechnungsmodell. So werden die definierten Funktionen nur dann ausgeführt, wenn sie aufgerufen werden und nutzen auch nur dann die notwendigen Kapazitäten der darunterliegenden Infrastruktur.
"Serverless": Nichts für Kontrollfreaks
Für die Entwicklung und den Betrieb von Applikationen in der Cloud eignen sich neben dem "Serverless" Konzept sowohl IaaS (Infrastructure-as-a-Service), PaaS (Platform-as-a-Service) als auch Container-Technologien. Jede Deployment-Variante besitzt allerdings ihre speziellen Eigenschaften, die es zu berücksichtigen. Sie hängen maßgeblich vom gewünschten Kontroll-Level und vom benötigten Kenntnisstand ab. (Lesen Sie hierzu auch IaaS vs. PaaS vs. Container: Moderne Anwendungsentwicklung in der Cloud.
Foto: Crisp Research AG, 2016
IaaS
IaaS stellt Entwicklern Basis-Ressourcen wie Rechenleistung, Speicherplatz und Netzwerk zur Verfügung, mit denen sich eine eigene virtuelle Infrastruktur aufbauen lässt, um Applikationen zu betreiben. Eine IaaS-Umgebung bietet insofern einen hohen Kontrollgrad, da sich auf den virtuellen Maschinen alles selbst installieren und zu 100 Prozent konfigurieren lässt. Dennoch ist für jede IaaS-Umgebung ein spezielles Wissen über die Cloud-Infrastruktur eine Grundvoraussetzung, um anhand von Tools die Umgebung und Applikationen zu verwalten. Für IaaS ist somit ein breiter Kenntnisstand erforderlich, da der gesamte Stack bedient werden muss, inklusive Installation, Konfiguration, Wartung und Betrieb der gesamten virtuellen Infrastruktur sowie der Betriebssysteme. Weiterhin ist das Thema "Infrastructure as Code" ein wesentlicher Bestandteil während der Nutzung von IaaS. Mehr hierzu kann unter "Infrastructure as Code": Der Admin 1.0 klickt - Der Admin 2.0 programmiert nachgelesen werden.
PaaS
Ein PaaS abstrahiert die darunterliegende Infrastruktur von der Applikation. Dies führt dazu, dass sich Entwickler nicht um den Aufbau und die Verwaltung der Infrastruktur kümmern müssen, die für die Applikation erforderlich ist. Hierfür stellt eine PaaS-Umgebung eine standardisierte Plattform bereit, die der Entwicklung, dem Test und dem Deployment dient und Funktionen für das Konfigurationsmanagement beinhalte. Diesen Erleichterungen bezüglich Anwendungsentwicklung und Management steht allerdings der Nachteil gegenüber, dass die meisten PaaS-Umgebungen nur spezifische Funktionen eines Anbieters enthalten, um Applikationen zu entwickeln und bereitzustellen. Trotz eines einfachen und kontrollierbaren Entwicklungsprozesses müssen Entwickler auf andere Ressourcen und Tools wie zum Beispiel externe APIs und Microservices, Middleware und native APIs zurückgreifen.
Container
Container stellen Möglichkeiten bereit, um paketierte Software-Stacks portabel einzusetzen. Ein Großteil traditioneller PaaS-Umgebungen setzt auf Container-Technologien als Basis, um Multi-Tenant Applikationen auf einer Shared-Infrastructure zu ermöglichen. Hierbei nutzen sie in den meisten Fällen Web-Container für eine bestimmte Programmiersprache wie Java, Rails, Ruby, Python, Django oder NodeJS, um darin den Programmcode zu speichern. Technologien wie Docker oder LXC kommen zum Einsatz, um die Container zu verwalten und sorgen für die Isolation zwischen den einzelnen Web-Containern. Diese Form der Architektur bietet sich gut für Web-Applikationen an, die aus einem Web-Front-End und entsprechenden Datenbanken im Backend bestehen. Aber Container können nicht nur für Web-Applikationen eingesetzt werden, sondern bieten sich ebenfalls für jede Art von Applikation wie Microservices, Big Data, Analytics und auch Legacy Anwendungen an.
Vor- und Nachteile einer "Serverless Infrastructure"
Eine Serverless Infrastructure bringt grundsätzlich einige Vorteile hinsichtlich einer einfachen Nutzung mit sich. Allerdings sollten auch die Kompromisse beachtet werden, die dabei eingegangen werden.
Vorteile
Automatische Skalierung und Fehlertoleranz
Automatisches Kapazitätsmanagement
Flexible Ressourcenverwaltung
Schnelle Bereitstellung der Ressourcen
Exakte nutzungsabhängige Abrechnung der Ressourcen
Konzentration auf den Kern des Source-Codes
Nachteile
Kontrollverlust
Erhöhtes Lock-in Risiko
Den Vorteilen einer "Serverless Infrastructure", darunter die automatische Skalierung und das Kapazitätsmanagement, steht der Nachteil gegenüber, dass ein Entwickler einen Großteil seiner Kontrolle verliert. Er hat beispielsweise nicht mehr die Möglichkeit, auf die virtuelle Maschine zuzugreifen oder Änderungen am Betriebssystem oder der Laufzeitumgebung vorzunehmen. Seine Freiheitsgrade sind damit deutlich eingeschränkt.
Ein weiteres Risiko besteht in einem erhöhten Lock-in Risiko. Die Serverless-Services bzw. die Funktionen der Cloud-Anbieter sind proprietär und lassen sich nur in deren Umgebungen nutzen. Dennoch, ein Lock-in muss nichts Negatives sein, ein Nutzer muss sich nur bewusst darauf einlassen und sich mit den möglichen Konsequenzen auseinandersetzen.
Wer also weiterhin die Kontrolle über seinen Infrastruktur-Stack behalten will oder muss und gleichzeitig vorsichtig mit dem Thema Lock-in umgeht, der sollte eine Serverless Architektur zunächst als Proof of Concept prüfen.
Anbieter einer "Serverless Infrastructure"
Insbesondere in den Portfolios der großen Public Cloud-Anbieter finden sich bereits seit längerer Zeit Services für den Aufbau einer "Serverless Infrastructure" wieder. Hierzu zählen:
Amazon Web Services: AWS Lambda
Microsoft: Azure Functions
Google: Cloud Functions
IBM: Bluemix OpenWhisk
AWS-Kunden wie Thomson Reuter, Periscope und Associated Press setzen Lambda bereits produktiv ein. Die ProSieben-Tochter Glomex hat von einer Server-zentrierten auf eine Lambda-Umgebung umgestellt und verarbeitet darüber 5 Millionen Datensätze pro Tag.
Serverless: Das Ende des IT-Betriebs?
Die abschließende Frage, die bei der Betrachtung des Serverless Konzepts aufkommt, lautet: Wird der klassischer IT-Betrieb in Zukunft noch benötigt? Schließlich übernimmt ein Cloud-Anbieter in diesem Modell die vollständige Verwaltung der zugrundeliegenden Infrastruktur.
Klar ist: Entwickler sind in der Cloud nicht mehr maßgeblich auf den IT-Betrieb angewiesen, denn dieser wird durch den Anbieter dargestellt. Im Falle von IaaS (Infrastructure-as-a-Service) bleibt die Situation weitestgehend unverändert. Hier muss sich das Skillset (vgl. "Infrastructure as Code": Der Admin 1.0 klickt - Der Admin 2.0 programmiert) des Operations-Team jedoch maßgeblich ändern oder sie werden durch Entwickler ersetzt. Ein Vorbild hierfür ist Google, wo das "Mission Control" Konzept der NASA adaptiert wurde.
Ein Entwickler, der für die Produktentwicklung eines Google Produkts zuständig ist, muss für sechs Monate im Cloud Infrastruktur-Team arbeiten, um zu verstehen, wie Google's globale Cloud-Infrastruktur funktioniert: "Eat your own dog food" in Perfektion.
Je höher man jedoch im Cloud-Stack wandert, desto unbedeutender wird der Job des IT-Betriebs. Unternehmen, die sich für PaaS oder eine "Serverless Architecture" entscheiden, sind maßgeblich auf Entwickler angewiesen, die die Entwicklung der Kernapplikation verantworten. Die vollständige Plattform und der Stack, den die Anwendungen benötigen, werden vom Cloud-Anbieter bereitgestellt und gewartet. Er übernimmt somit den Betrieb der Infrastruktur.
Der Appell an Systemadministratoren in Unternehmen, in denen die Cloud Bestandteil der IT-Strategie ist oder wird, kann daher nur einmal mehr lauten: Lernen Sie Programmieren! Entwicklerkenntnisse sind ein wichtiger Bestandteil der zukünftigen Überlebensstrategie.