© Mikhail Starodubov, 123RF

Der Trend der Stunde in der IT ist eindeutig das Serverless Computing, das sich bei genauerem Hinsehen als gar nicht “serverless” entpuppt. Was meint der Begriff genau? Eine Einführung.

Wer für einen IT-Dienstleister tätig ist und dieser Tage Vorträge auf Konferenzen hält, landet mit der Aussage “Wir betreiben die Server, die unsere Kunden für Serverless Computing brauchen” einen Lacher. Der Begriff “Serverless Computing” ist die dickste Marketing-Sau, die aktuell durchs IT-Dorf getrieben wird. Doch wie so oft ist es für die meisten eine Worthülse. Was meint Serverless Computing, worauf bezieht sich der Begriff und was müssen Anbieter wie Kunden tun, damit Serverless Computing möglich wird? Dieser Artikel gibt einen Überblick.

Managed Hosting

Eine der größten Herausforderungen, die mit der Verbreitung des Internets einhergeht, ist, dass fast jede Firma irgendwie im Internet vertreten sein möchte. Aber längst nicht jede Firma hat die Leute, um komplexe Online-Auftritte zu bauen und zu betreiben. Mehr noch: Betrachtet ein Unternehmen Onlinedienste lediglich als Mittel zum Zweck, wird es das entsprechende Know-how oft genug auch gar nicht aufbauen wollen.

Die Anbieter von Managed Hosting füllten diese Lücke: Sie entwickelten zusammen mit ihren Kunden das Konzept für die Plattform und ließen sie anschließend von Entwicklern und Designern in die Praxis umsetzen. Die nötige Infrastruktur in Form von Servern, Hosting Space und anderen Faktoren stellten die Anbieter gleich selbst, und Kunde wie Anbieter hatten am Ende, was sie wollten.

Zeitenwende

Vor rund zehn Jahren kam Unruhe in eben diesen Markt, denn die ersten Ideen zum Thema “Cloud Computing” machten die Runde. Die Idee der Cloud war tatsächlich revolutionär: Statt spezifische Setups aus Hard- und Software für einen einzelnen Kunden zu bauen, würde der Anbieter eine große Plattform für alle (potenziellen) Kunden betreiben, in der eben jene sich dynamisch und nach Bedarf Ressourcen reservieren. Mehr noch: Der zweite zentrale Aspekt von Clouds ist die Möglichkeit der Selbstbedienung (Self Servicing). Per Website legt der Kunde sich also überhaupt erst einen Account bei einem Cloudanbieter an, zieht seine Kreditkarte virtuell durch dessen Lesegerät – und los geht die Party.

Im Vorbeigehen änderte sich das Business der Hosting-Anbieter radikal – sie wurden zu Plattformbetreibern, hatten aber nicht mehr zwangsläufig etwas mit der technischen Umsetzung der Kundenumgebungen zu tun – Teile des ganz klassischen Managed Hosting entfielen. Denn nun konnten auch Drittanbieter Kunden auf Cloudplattformen Dienstleistungen anbieten, sodass die klassische Automatik nicht mehr existierte, nach der der Kunde Onlinedienste bei derselben Firma kauft, die ihm auch die Infrastruktur zur Verfügung stellt.

Daran, dass der Kunde Hilfe eines anderen Unternehmens brauchte, wenn er selbst nicht sonderlich Internet-affin war, änderte die Cloud jedoch nichts. Der erste prominente Dienst, den die meisten Clouds anboten, war Infrastructure as a Service (IaaS). Letztlich geht es hierbei darum, dem Kunden Computing- und Storage-Ressourcen zur Verfügung zu stellen, meist in Form vollvirtualisierter Systeme. Die sind aber ebenso zu warten wie physische Server, beide Ansätze unterscheiden sich zumindest in dieser Hinsicht nicht voneinander.

Abbildung 1: Open Stack ist eine klassische IaaS-Lösung, bietet mittlerweile aber auch diverse “aaS”-Komponenten und kann so die Grundlage für eine Serverless-Lösung sein.

Wer eine Webumgebung samt Datenbank bauen wollte, musste sich nach wie vor um die händische Installation von MySQL oder einer anderen Datenbank kümmern – und nicht zuletzt auch Konzepte für den sicheren Betrieb der Lösung entwerfen. Wer IaaS-Dienstleistungen konsumiert, streift lediglich das Thema Hardwarebeschaffung ab, nicht aber alle anderen Aspekte des Betriebs von IT-Diensten (Abbildung 1).

Stetige Evolution

So skeptisch viele Beobachter dem Thema Cloud anfangs gegenüberstanden, eines steht fest: Die Cloud hat sich in den vergangenen Jahren zum Innovationstreiber innerhalb der IT gemausert, und Amazon hat daran einen erheblichen Anteil. Das Unternehmen hat sich “Everything as a Service” auf die Fahnen geschrieben: Wer eine Datenbank braucht, sich mit deren Betrieb aber nicht befassen möchte, findet mit DBaaS eine fertige Lösung.

Database as a Service: Per Mausklick startet der Admin eine Datenbankinstanz – und kurze Zeit später zeigt Amazon eine IP-Adresse und Login-Daten an, die der Admin bloß noch in eine Applikation einträgt. Je nach Konfiguration kümmert sich AWS auch um Datenbankbackups sowie um die Benutzerverwaltung der Datenbank selbst.

Das hat dazu geführt, dass diverse neue Lösungen entstanden sind, die entsprechende Funktionen ausgiebig nutzen oder sogar auf diesen basieren – die diversen Baukästen und Frameworks sind dafür ein gutes Beispiel. Wer heute einen Webshop, eine Social-Media-Seite oder ähnliche Apps für das Internet entwickeln möchte, fängt in der Regel nicht mehr bei Adam und Eva an, sondern greift auf bestehende Basistechnologien wie Node.js zurück.

Auf diese Weise haben sich etwaige Umgebungen zu einer Abstraktionsschicht gemausert und dabei selbst einen Dienstleistungsmarkt geschaffen – eben so, wie DBaaS letztlich auch eine Abstraktionsschicht ist, die Teile der Komplexität des Betriebs von Datenbanken ausblendet. Auf Basis fertiger Frameworks und entsprechender Features in der Cloud war es nicht mehr weit zum Prinzip der Platform as a Service, kurz PaaS.

Abstraktion ist alles

Der Kernaspekt von Abstraktionsschichten ist es bekanntlich stets, die nach außen sichtbare Leistung unabhängig von Ressourcen im Hintergrund zu machen – die Bande zwischen Infrastruktur und konkreter Lösung also zu lockern und am Ende zu trennen. Das ist die Wurzel von Platform as a Service: Hier steht die einzelne virtuelle Maschine nicht mehr im Vordergrund. Stattdessen bucht der Kunde eine Umgebung, die ihm eine bestimmte Technologie bereitstellt, etwa einen Websever mit PHP oder eine Umgebung zum Betrieb von Services nach dem Microarchitektur-Modell – Stichwort Kubernetes.

PaaS versteht sich auch deshalb als logische Evolution von IaaS, weil es die Einheit “Server” zwar aus der Gleichung nicht vollständig entfernt, die Bedeutung einzelner Server – ob virtuell oder physisch ist unwichtig – aber verwässert. Der Server ist nach diesem Mantra keine eigene Einheit des Setups mehr, sondern lediglich ein Mittel zum Zweck, um die eigentlichen Dienste zu betreiben.

Abbildung 2: Bei PaaS steht der Gedanke im Vordergrund, für eine bestimmte Applikation eine Umgebung bereitzustellen.

Anbieter und Kunden müssen bei PaaS-Anwendungen Hand in Hand arbeiten: Der Anbieter steht in der Verantwortung, entsprechende PaaS-Umgebungen anzubieten, und der Kunde tut gut daran, seine Applikationen an die Anforderungen der konkreten Umgebung anzupassen oder anpassen zu lassen. Findet diese Kooperation zwischen Anbieter und Kunde (oder dem jeweiligen Dienstleister des Kunden) statt, profitieren beide Seiten enorm (Abbildung 2).

Serverless geht noch weiter

Ganz perfekt ist die Welt im PaaS-Umfeld allerdings nicht. Zwar sind hier weite Teile der Komplexität großer Setups für den Kunden nicht mehr sichtbar, ein paar zentrale Fragen muss der Kunde (möglicherweise zusammen mit seinem Dienstleister) aber trotzdem beantworten, etwa die Frage, bis zu welcher Größe das Setup skalieren soll. Und wenn das entschieden ist, muss sich der Kunde in PaaS-basierten Setups um diese Skalierung tatsächlich auch selbst kümmern, ein Automatismus existiert nämlich nicht. Hier wird erkennbar, dass der Server als Einheit aus dem Setup eben nur beinahe verschwindet, im Hintergrund gibt er aber weiter den Ton an (Abbildung 3).

Abbildung 3: Anders als bei PaaS kümmert sich bei Serverless Computing der Kunde nur noch um die Verwaltung der Applikation.

Genau hier kommt Serverless ins Spiel. Das Versprechen der Anbieter ist es, sich um den gesamten Betrieb der zugrunde liegenden Infrastruktur im Alleingang zu kümmern – dazu gehört auch das automatische Skalieren. Der Kunde bestellt bei einem Infrastrukturanbieter eine virtuelle Umgebung, die anhand ständiger Messungen Ressourcen dynamisch hinzufügt oder aus dem Setup streicht, ansonsten aber weitestgehend dem PaaS-Prinzip folgt.

Der einzelne Server – egal ob virtuell oder physisch – stellt für den Kunden tatsächlich keine relevante Kenngröße mehr dar, denn der Kunde denkt eher in den Dimensionen von Ressourcen als denen einzelner Server. Und in dieser Tatsache hat der Begriff Serverless Computing seinen Ursprung.

Zweischneidiges Schwert

Klar, aus Sicht eines typischen IT-Kunden ist das Serverless-Prinzip sehr verlockend. Denn im Kontext einer Serverless-Umgebung lassen sich Dienste und Anwendungen noch einfacher betreiben als in PaaS-Umgebungen. Alle Aspekte des Betriebs von IT-Infrastrukturen deckt der Plattformbetreiber über Funktionen in seiner Umgebung ab, sodass der Kunde sich im Idealfall gar nicht mehr selbst mit den entsprechenden Themen befassen muss. Und selbst wenn er völlig unbeschlagen in Sachen IT ist und das Thema lieber an einen externen Dienstleister auslagert, lohnt sich der Serverless-Ansatz für ihn – denn der Dienstleister muss im Rahmen einer Serverless-Umgebung weniger Zeit in die Planung und Umsetzung der Applikation stecken. Im Idealfall genügt es, den Code hochzuladen – fertig ist der Lack.

Wo IT-Dienstleister früher eine Heerschar von Admins beschäftigten, um Kundenprojekte umzusetzen, reichen jetzt wenige Entwickler, weil der Serverless-Anbieter das Thema Betrieb komplett abdeckt. Mittlerweile debattieren im Netz verschiedene Entwickler sogar, wie sie ihre Applikationen bestmöglich an die Voraussetzungen verschiedener Anbieter anpassen, etwa unter [1].

Was zu schön klingt, um wahr zu sein, ist es allerdings auch. Denn neben dem Komfort und der Einfachheit, die Serverless Computing auszeichnen, geht das Konzept auch mit erheblichen Risiken einher, von denen das größte wohl der latent drohende Kontrollverlust ist. Wer die Herrschaft über die für das eigene Geschäft kritischen Daten etwa komplett an den Anbieter überträgt, muss im Zweifelsfalle damit rechnen, dass die Daten weg sind – oder woanders.

Wo im IaaS-Prinzip die Daten zumindest noch auf einem System unter der eigenen Kontrolle liegen und mit Bordmitteln wie SCP woanders hinkopiert werden können, verschwinden sie beim Serverless-Ansatz in den Gedärmen des ISP und sind nur über Schnittstellen in dessen Software verfügbar.

Ähnliches gilt für Ausfälle: Wer IaaS nutzt, vertraut zwar auch darauf, dass der Anbieter seine Umgebung im Griff hat. Für IaaS genügt es in der Regel jedoch, wenn SDN, SDS und Virtualisierung funktionieren. Bei Serverless-Umgebungen gibt es deutlich mehr lose Teile, die kaputtgehen können. Tritt das ein, ist der Kunde dem Anbieter letztlich ausgeliefert – er hat keine wie auch immer geartete Möglichkeit, alleine wieder online zu kommen. Der Kunde vertraut dem Anbieter letztlich blind – und das ist nicht jedermanns Sache.

Fazit

Letztlich ist Serverless Computing die logische Weiterentwicklung des As-a-Service-Trends, der die IT in den vergangenen Jahren dominiert hat. Aus Kundensicht ist das Konzept einerseits verlockend: Man bekommt auf der einen Seite echte IT-Dienstleistung auf der Höhe der Zeit und muss sich auf der anderen Seite mit den Niederungen des klassischen IT-Betriebs nicht mehr auseinandersetzen. Ausfälle, Skalierung, Überwachung – um all das kümmert sich der Serverless-Anbieter. Eigentlich klingt das wie eine klassische Win-win-Situation.

Das Risiko, das mit der beinahe vollständigen Aufgabe der Kontrolle des eigenen IT-Setups einhergeht, ist allerdings beträchtlich. Gerade in Fällen, in denen es tatsächlich um sensible Daten geht, dürfte Serverless auch vor dem Hintergrund gesetzlicher Vorschriften eine Herausforderung sein.