Teil 1. Geschichte des Serverless Cloud-Computings
Die meisten heute verwendeten Web-Anwendungen werden von Systemen mit sehr leistungsstarken, diverse Berechnungen und Aufgaben durchführende Backends sowie mit Frontends, die meist nur die Oberfläche für den Endbenutzer beinhalten, die wiederum im Webbrowser oder auf einem mobilen Gerät vom Benutzer konsumiert werden, unterstützt und bereitgestellt. Die typische Web-Anwendung wird eine HTTP-Anforderung an den Server stellen, die von ihm empfangen und weiterverarbeitet wird. Die Daten werden meistens durch verschiedene Ebenen der Anwendung durchgereicht und lösen unterschiedliche Logiken und Verarbeitungsmustern aus, bevor sie final in einer Datenbank gespeichert werden. Nach der Verarbeitung und potenziellen Speicherung der Daten gibt das Backend eine Antwort in unterschiedlichen Formaten – json, xml oder als vorgerenderte HTML-Seite, die dann zum Client, also zum Webbrowser, zurückgeschickt wird.
Üblicherweise sind die sich im produktiven Betrieb befindenden Systeme viel komplexer als das auf der Abbildung 5 dargestellte System und beinhalten zusätzliche Komponenten und Komplexitätsebenen wie Load Balancing, Transaktionen, Clusters, Cache, Messaging Queues. Alle diese Komponenten werden auf einem oder auf mehreren Servern ausgeführt, die sich entweder in einem On-Premise-Rechenzentrum oder in der Cloud befinden. In beiden Fällen müssen das Betriebssystem und die Konfiguration dieser Komponenten und Server verwaltet, konfiguriert, gewartet und gepatcht werden.
Zur Gewährleistung eines stabilen Servers muss sich jemand – das kann ein Mitarbeiter oder sogar ein ganzes Team sein – um die Bereitstellung, Verwaltung und das Patching des Servers kümmern. Das ist eine zeitintensive Aufgabe und verlangt zusätzlich eine Vielzahl an Fähigkeiten der jeweiligen Mitarbeiter. Jede nicht triviale Server-Umgebung wird schwer einzurichten und zu pflegen sein. Sowohl die Hardware als auch die Infrastruktur als solche sind wichtige und unabdingbare Teile eines IT-Systems, die aber gleichzeitig auch eine Ablenkung von der Kernaufgabe des Unternehmens, der Lösung des eigentlichen Geschäftsproblems,
sein können.
In den letzten Jahren sind Technologien wie Cloud-Computing und Container entstanden, um Probleme mit der Inkonsistenz der Infrastruktur und verschiedenen Umgebungen und Server-Verwaltungen zu beheben. Das Cloud-Computing-Paradigma ist bereits in IT-Landschaften vieler Unternehmen weltweit adaptiert worden. Die Vorteile davon sind unter anderem Kosteneinsparungen durch ein nutzungsabhängiges Preismodell sowie eine größere Flexibilität dank der Möglichkeit, die IT-Ressourcen on demand in Anspruch zu nehmen. Der quantitative Vergleich der Kosten von klassischen On-Premise-Architekturen und Cloud-basierten Architekturen ist nicht trivial und erfordert ein hohes Maß an Genauigkeit in den Berechnungen sowie den Einsatz spezieller mathematischer Modelle, zum Beispiel das Modell von Kratzke (2011) für die Ex-ante-Kostenschätzung eines Cloud-Systems 41.
Dennoch konnte in mehreren Studien bewiesen werden, dass der Einsatz von Cloud-Computing die Gesamtbetriebskosten senken und die Markteinführung von neuen Produkten oder Diensten beschleunigen kann.42
Das meistverbreitete Cloud-Modell ist die Public Cloud (öffentliche Cloud). Es ermöglicht den Unternehmen, Serverflotten und die darauf ausgeführten Anwendungen wesentlich leichter zu erstellen und zu verwalten. Zum größten Teil basieren die Cloud-Systeme heute auf gemieteten Servern oder VMs. Das ist aber nicht die einzige Möglichkeit, um die Anwendungen in der Cloud bereitzustellen. Während bei der Nutzung von klassischen Cloud-Diensten der Kauf und das Verwalten von Hardware entfallen, ist der Kunde immer noch für die Bereitstellung des Betriebssystems, für laufende Updates des Systems sowie für Sicherheitspatches und andere administrative Aufgaben verantwortlich.43
Darüber hinaus müssen Unternehmen ihre Systeme in Eigenverantwortung während der Spitzenzeiten hochund außerhalb davon herunterskalieren, um damit zum einen die Stabilität der Systeme auch während Peak-Zeiten zu gewährleisten und zum anderen kein Geld durch nicht voll ausgelastete Server zu vergeuden. Dass dies des Öfteren nicht gelingt, haben Studien wie „Revolutionizing Data Center Energy Efficiency“ von McKinsey (2008) gezeigt.44 Die Verfasser der Studie schätzen, dass bis zu 94% der eingesetzten Server nicht voll ausgelastet sind.45 Das geht ein großer wirtschaftlicher Schaden einher.
Eines der Cloud-Computing-Modelle ist das PaaS-Modell, das dem Entwickler eine serverähnliche Umgebung zur Verfügung stellt, in der er seine Software laufen lassen kann ohne sich mit der infrastrukturellen Komplexität des Servers, die sich hinter Schnittstellen und Tools der PaaS-Lösung versteckt, befassen zu müssen. Damit der Entwickler das Potenzial von PaaS optimal ausschöpfen kann, muss er seinen Code an die Eigenschaften der ausgewählten PaaS-Lösung anpassen. Die Migration einer bestehenden Enterprise-Anwendung in PaaS ist initial mit einem
zusätzlichen Entwicklungsaufwand verbunden, den man nicht unterschätzen darf.
Nichtsdestotrotz ist der Einsatz einer PaaS-Plattform für viele Anwendungsfälle die richtige Entscheidung, weil PaaS in der Konfiguration immer noch weniger Aufwand verlangt als klassische dedizierte Server.46
Containerization ist eine weitere Möglichkeit, um Anwendungslayer und Umgebung voneinander zu trennen. Im Gegensatz zur Virtualisierung ist es ein leichtgewichtiger Ansatz, weil die Container zwar isoliert sind, aber auf einen bestehenden Server eingespielt werden müssen, dessen Ressourcen zwischen allen aktivenContainern geteilt werden. Zu dem greifen die Container direkt auf das Betriebssystem des Servers zu, während bei der Virtualisierung jede VM ein eigenes Gastbetriebssystem beinhaltet, welches unabhängig von dem Betriebssystem des Servers funktioniert. Die Container eignen sich am besten für jene Einsatzfälle, bei denen es auf der Server-Ebene viele Abhängigkeiten zu unterschiedlichen Paketen gibt, die aber standardisiert sind, zum Beispiel eine LAMP-Umgebung. Auf der anderen Seite sind Container bei der initialen Inbetriebnahme aufwendiger und auch umständlicher während der Programmierung als es die Entwicklung direkt auf einem Cloud-System wäre.47
Der Drang nach der Optimierung der umständlichen Serverarchitekturen hat letztendlich zur Entstehung von serverlosen Ansätzen wie AWS Lambda geführt. Die Besonderheit an Lambda ist, dass sie den Code unter Verwendung von parallelen Aufrufen ausführt, sodass sie auch mit sehr großem Traffic gut umgehen kann. Außerdem fallen in Zeiten, in denen es keine oder nur eine geringe Nutzung der Dienste gibt, keine Kosten an. Die Ausführung des Codes in serverlosen Architekturen findet gänzlich ohne Bereitstellung und Konfiguration von Servern oder Containern statt. Im Hintergrund wird von AWS eine Elastic-Compute-Cloud-Instanz (EC2) bereitgestellt und verwaltet, die den eigentlichen Code ausführt und sich um die automatische Skalierung kümmert, ohne dass der Entwickler noch etwas machen muss. Diese Architektur wird mit dem Begriff serverless bezeichnet, der auf den ersten Blick irreführend sein kann, denn es bedeutet nicht, dass bei diesem Ansatz keine Server mehr im Spiel sind, sondern dass der Entwickler keinen direkten Zugriff auf das Betriebssystem des Servers hat und ihn auch nicht benötigt. Was AWS an der Stelle macht, ist genau das, was ein Entwickler selbst mit einem Server machen würde, aber komplett automatisiert und hoch skalierbar. Unter Verwendung von zahlreichen für bestimmte Zwecke entwickelten Services und Schnittstellen kann ein Entwickler innerhalb kurzer Zeit lose gekoppelte, flexible, skalierbare und effiziente Architekturen aufsetzen.48
Dieser Ansatz ermöglicht es Unternehmen, das Anwendungsdesign anders anzugehen, was nachweislich zu einer Kostensenkung und zur Beschleunigung der Markteinführung führt. AWS Lambda wurde im Jahr 2014 von Amazon als weltweit erste Plattform für die Bereitstellung der serverlosen Anwendungen vorgestellt. Seitdem sind ähnliche Angebote anderer großer IT-Unternehmen wie Google (Google App Engine), IBM, Microsoft (Azure Functions) auf den Markt gekommen, AWS Lambda ist aber nach wie vor Spitzenreiter. Die von AWS am stärksten beworbenen Vorteile von AWS Lambda sind die extreme Vereinfachung der Serververwaltung auf allen Ebenen der Technologieplattform sowie die Einführung eines wirklich nutzungsabhängigen Abrechnungsmodells, bei dem keine Gebühren fällig werden, wenn die Anwendung unbenutzt bleibt – ein großer Unterschied zu anderen Cloud-Computing-Modellen wie SaaS, IaaS und PaaS. Die Lambda-Funktionen (eine Funktion ist die Haupt-Entwicklungseinheit in Lambda-basierten Anwendungen) vereinfachen auch stark die Nutzung von Microservices.
Wirtschaftlich profitieren die Unternehmen durch die Einführung des Lambda-Modells und die
Eliminierung der Verwaltung der Infrastruktur auf zweifache Weise:49
- Es gibt keine sich im Leerlauf befindlichen Server mehr, die das Unternehmen wirtschaftlich beeinträchtigen. Serverlose Datenverarbeitung-Services wie AWS Lambda sind zu jedem beliebigen Zeitpunkt effizient, weil die Gebühren auf die Millisekunden der tatsächlichen Nutzung abgerechnet werden.
- Hohe IT-Ressourcen-Einsparungen (auch beim IT-Personal) sind möglich, da die gesamte Flottenverwaltung für Server-Flotten entfällt. Entwicklung und Installation von Sicherheits-Patches, Serverüberwachung und Verwaltung der damit verbunden Tools und Verfahren gehören somit der Vergangenheit
an. Unternehmen, die zum Beispiel ihre Microservices mit Lambda
erstellen, können deutlich agiler werden und die knappen IT-Ressourcen für Aufgaben einsetzen, die unmittelbar mit ihren Geschäftszweck zusammenhängen.50
Zusammenfassend lässt sich die Hauptmotivation hinter der Entwicklung von serverlosen Architekturen als der Versuch definieren, die Infrastruktur fern von dem Entwickler zu halten, um ihm die volle Konzentration auf seine Geschäftsziele zu ermöglichen. Der Einsatz von serverlosen Architekturen kann für das Unternehmen einen wesentlichen Wettbewerbsvorteil bedeuten, der sich in erhöhter Agilität und Produktivität bei gleichzeitig verminderten Infrastrukturkosten widerspiegelt. Wie das in Zahlen aussehen kann, wird in Kapitel 4 und 5 dieser Arbeit erläutert.