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 an dieser Sau ist jedoch, dass sie Verwirrung stiftet. Ist das Ende der Server tatsächlich angebrochen? Bei weitem nicht – viel mehr verschiebt sich mal wieder etwas innerhalb des Cloud-Stacks weiter nach oben. Dieser Analyst View klärt die Mythen rund um das Thema „Serverless“, beschreibt dessen Vorteile und macht auf die Risiken aufmerksam.
Was ist eine „Serverless Infrastructure“?
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 bzw. virtuelle Ressource selbstverständlich weiterhin im Hintergrund, schließlich muss der Programmcode und die Daten irgendwo gespeichert und betrieben werden. Allerdings muss sich ein Entwickler nicht mehr direkt mit ihnen beschäftigen bzw. kann diese 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 dem ersten Blick erscheint das „Serverless“-Konzept wie der Ansatz des Platform-as-a-Service (PaaS). Betrachtet man den Ansatz 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 sicherstellen, indem die darunterliegende (für ihn nicht sichtbare) Serverinfrastruktur entsprechende Ressourcen hinzufügt und anschließend wieder freigibt. Er muss somit 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 kümmert sich hierbei u.a. um die automatische Skalierung der Server-Infrastruktur, des Speichers, 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 reagiert werden soll, dass eintritt (z.B. das Hochladen eines Bildes) und wie darauf reagiert werden soll (z.B. automatisch einen bestimmten Filter darauf anwenden). So lassen sich z.B. auch vom Anbieter bereitgestellte Microservices bzw. 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.
Wer über Programmiererfahrung verfügt, 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 zur darunterliegenden Infrastruktur besitzen, wodurch sich innerhalb kürzester Zeit viele Kopien einer einzelnen Funktion starten lassen, die es benötigt, um die notwendige Skalierbarkeit zu einem bestimmten Zeitpunkt als Reaktion auf ein Ereignis zu erreichen. So ist es z.B. 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 Deploymentvariante besitzt allerdings ihre speziellen Eigenschaften, die es zu berücksichtigen gilt und welche maßgeblich von dem gewünschten Kontroll-Level sowie für die Nutzung notwendigen Kenntnisstand abhängt. (Lesen Sie hierzu auch IaaS vs. PaaS vs. Container: Moderne Anwendungsentwicklung in der Cloud.)
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 Applikation zu verwalten. Für IaaS ist somit ein breiter Kenntnisstand erforderlich, da der gesamte Stack bedient werden muss, inkl. der Installation, Konfiguration, Wartung und Betrieb der gesamten virtuellen Infrastruktur sowie der Betriebssysteme etc. 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 zur Entwicklung, dem Test und Deployment dient und Funktionen für das Konfigurationsmanagement beinhaltet, um damit die Continuous Integration und das Continuous Development zu unterstützt. Diese Erleichterung im Rahmen der Anwendungsentwicklung und dem Management kommen mit dem Kompromiss einher, 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 z.B. 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
Die Vorteile einer „Serverless Infrastructure“, wie die automatische Skalierung und das Kapazitätsmanagement, kommen zusammen mit dem Kompromiss einher, dass ein Entwickler einen Großteil seiner Kontrolle verliert. Er hat z.B. nicht mehr die Möglichkeit, auf die virtuelle Maschine zuzugreifen oder Änderungen an dem Betriebssystem oder der Laufzeitumgebung vorzunehmen. Der Freiheitsgrad ist für ihn 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 Kontrolle über seinen Infrastruktur-Stack behalten will oder gar muss und vorsichtig mit dem Thema Lock-in umgeht, der sollte eine Serverless Architektur zunächst als PoC 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
- iron.io
- Serverless
Amazon Web Services Kunden wie Thomsen Reuter, Periscope und Associated Press setzen Lambda bereits in Produktion 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: Wird der 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 (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 allerdings der Job des IT-Betriebs. Unternehmen, die sich für einen PaaS oder eine „Serverless Architecture“ entscheiden sind maßgeblich auf Entwickler angewiesen, die sich um die Entwicklung der Kernapplikation verantwortlich zeigen. Die vollständige Plattform und der Stack, den die Anwendungen benötigen, wird durch den 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 bzw. wird, kann daher nur einmal mehr lauten: Lernen Sie Programmieren. Entwicklerkenntnisse sind ein wichtiger Bestandteil der zukünftigen Überlebensstrategie.