So entstehen Vorteile etwa im Hinblick auf Innovationschancen und Skalierungspotenziale, die vielversprechend sind, sich jedoch auch als kontextspezifisch erweisen. Eine präzise Abwägung in Bezug auf die individuellen Unternehmensziele ist somit unabdingbar. Ebenso geht Serverless Computing auch mit zusätzlichen Herausforderungen einher. Wo es an bestimmten Punkten Komplexität verringert, erhöht es sie an anderer Stelle. In Ermangelung übergreifender Kompatibilitätsstandards zwischen den einzelnen Plattformen ist zudem eine gewisse Anbieterabhängigkeit unvermeidbar.
Umso wichtiger, dieses nunmehr viel beschworene Modell näher zu beleuchten. Dabei soll zunächst dessen Potenzial genauer unter die Lupe genommen werden: Für wen ergeben sich welche Vorteile? Im Anschluss analysieren wir die bei einer Migration zu beachtenden Risiken sowie die Möglichkeiten zu deren Verringerung, bevor wir uns den Kernfaktoren bei der Auswahl eines geeigneten Anbieters und einem Ausblick für die kommenden Monate widmen.
Code ausführen, nicht Server
Grundsätzlich gilt auch bei Serverless Computing das XaaS-Prinzip, auf Verbrauchsbasis berechnete Dienstleistungen von einem externen Anbieter zu erwerben. Zumindest auf reiner Wortebene wird es jedoch anfänglich paradox: Ganz ohne Server kommt nämlich auch Serverless nicht aus. Schließlich sind diese sehr wohl noch involviert, allerdings lediglich aufseiten des Cloud-Anbieters, der sie zur Verfügung stellt. Dieser zeichnet dabei auch für die dynamische Zuteilung von Ressourcen zu einzelnen Anwendungen und Aufgaben verantwortlich.
Genau an dieser Stelle beginnt auch schon das Mantra von Serverless Computing: Den Anwendungen selbst hat alle Aufmerksamkeit zu gelten. Per se eine höchst erstrebenswerte Vorstellung, gestaltet sich das Thema Infrastruktur entlang des gesamten Lebenszyklus von Anwendungen doch üblicherweise recht aufwandsintensiv. Kann es nun verstärkt in den Hintergrund treten, sorgt dies für einiges an Entlastung, der Fokus kann verstärkt auf die Anwendungen selbst gelegt werden.
Hier mag sich nun direkt die Frage stellen, welcher Unternehmenstypus am meisten von diesen Möglichkeiten profitiert. Dabei gilt es jedoch zu beachten, dass das Zünglein an der Waage vielmehr die spezifischen Vorteile der für Serverless geeigneten Computing-Varianten sind. Je relevanter diese sich im jeweiligen Unternehmenskontext erweisen, desto größer sind die Chancen, die eine Migration eröffnet. Diese lassen sich in drei Rubriken kategorisieren, auf die wir im Folgenden näher eingehen.
Einfachere, schnellere Innovation
Die Vorteile bezüglich der Infrastruktur sind hier Dreh- und Angelpunkt. Denn nicht nur der Erwerb bedarf einiges an Ressourcen, auch ihre Skalierung und Absicherung sind aufwendig. Umso interessanter kann es sein, diese Abläufe auszulagern und zeitgleich die Qualität aller Prozesse rund um die Anwendungen selbst intern zu optimieren.
In Sachen Serverless gilt es dabei, zwischen drei Ausprägungen zu unterscheiden:
- Serverless-Funktionen wie AWS Lambda,
- Serverless-Cloud-Services wie Datenspeicher (S3, DynamoDB) und andere Tooling-Optionen (z. B. SQS, SNS, SMS, Route453),
- vollständiges Serverless Computing.
Die größten Gewinne sind bei der dritten Ausprägung zu erzielen. Hier werden gesamte Anwendungen über eine eigene Infrastruktur ausgeführt. Da diese in ihrer Gänze vom Cloud-Anbieter gestellt wird, entfällt auch das Aufsetzen der Server seitens des Kunden. Er muss noch nicht einmal mit der Struktur der Server vertraut sein, auf denen die Anwendungen laufen.
Container-Orchestrierung und Mesh-Management per Serverless-Methodik verändern das Tagesgeschäft unternehmensinterner Teams in der Infrastruktur-Verwaltung grundlegend, definieren ihre Zielsetzung neu: Sie sind nun Nutznießer einer für sie optimal justierten Infrastruktur und müssen diese nicht mehr selbst aufbauen, skalieren und sichern. Stattdessen verwenden sie ihre Kapazitäten darauf, für bestens funktionierende Anwendungen zu sorgen (s. Abb. 1). Ein entscheidender Faktor, um Innovationspotenziale zu nutzen und schneller zutage zu fördern.
Abb. 1: Distributed Tracing
Sofortige Skalierbarkeit
Erhebliche Vorteile verspricht Serverless auch bei der Skalierung. Ein hohes Maß an Konfigurationsvorarbeit ist hierbei nicht vonnöten, und so erweist es sich auch als weitaus agiler als die herkömmliche Skalierung auf Basis von Cloud-Servern. Gerade AWS Lambda hat sich bei der Skalierung beliebig vieler kurzläufiger Aufgaben bewährt. Dabei spielt es keine Rolle, ob es sich um Hunderte Events oder mehrere Milliarden handelt – alles ist machbar. Am hypothetischen Anwendungsfall eines Fußballstatistik-Dienstleisters lässt sich das sehr gut beobachten. Nehmen wir an, dieser hat seine Applikationen ursprünglich on-premise entwickelt und angesichts seiner Monolith-Serverstruktur nun ein klassisches Skalierungsdilemma. Im Zuge einer Modernisierung könnte er alles neu schreiben und mit Lambda erweitern. Bei jedem einzelnen Spielzug auf dem Spielfeld – kurzen, ereignisorientierten Aufgaben, bei denen sich Lambda ideal präsentiert – wird ein Datenobjekt erstellt, zu den Servern weitergeleitet und von diesen verarbeitet. Das Ergebnis: Serverless-Skalierung in Höchstform.
EffizientereZugriffsvalidierung
Serverless punktet bei kurzen, voneinander unabhängigen Aufgaben mit hohen Volumina. Dies zeigt sich perfekt etwa bei der Zugriffserteilung für Kunden auf eine spezifische Ressource. Betrachten wir das Beispiel mobiler Videospiele für Smartphones: Um den Benutzern die Highscores anzuzeigen, benötigen diese Zugang zu den Daten auf den Backend-Servern. Dabei wird eine Reihe verschiedener kurzläufiger Aufgaben im App-Backend angefragt. Von wie vielen Instanzen aus ist dabei teils gar nicht genau bekannt.
Im konkreten Fall von Pokémon Go etwa konnten die Entwickler den massiven Erfolg des Spiels wahrscheinlich nicht erahnen. Dennoch waren sie in der Lage, die Loads hervorragend zu skalieren und zu verarbeiten, da sie das Backend von Beginn an auf schnelle Skalierung ausgelegt hatten. Serverless-Technologien wie AWS Lambda machen dies bestens möglich.
Herausforderungen
Jeder einzelne dieser drei Vorteile kann sich als Ansatzpunkt gerade bei der digitalen Transformation eines Unternehmens enorm bezahlt machen. Doch auch mit einer gut ausgearbeiteten Strategie und solidem Budget wollen für eine Serverless-Migration einige Abwägungen getroffen werden, um die ihr inhärenten Risiken langfristig zu verringern. In drei Hauptkategorien unterteilt wird erläutert, welche Herausforderungen dies genau sind und wie ihnen begegnet werden kann.
Komplexität in neuen Facetten
So sehr es Infrastrukturthemen vereinfacht, bedeutet Serverless Computing an anderer Stelle auch mehr Komplexität. Seine hervorragende Eignung für viele, kurzläufige Aufgaben führt automatisch zu einer signifikant höheren Anzahl dieser. Jede dieser Aufgaben mag in sich selbst stark vereinfacht sein, doch die nun erhöhte Anzahl an Übergängen und Schnittstellen macht in ihrer Gesamtheit auch die Systemstruktur komplexer: Beispielhaft seien etwa erhöhter Konfigurationsaufwand und zusätzliche Deployment-Skripte und Tooling-Artefakte genannt.
In der Konsequenz verläuft die Entwicklung von Software somit zwar de facto effizienter, jedoch gestaltet sich nunmehr das Monitoring der Anwendungen komplizierter. Wir treffen dabei auf unterschiedliche Programmiersprachen und eine große Menge an Services; verschiedene Pfade verlaufen durch das Gesamtsystem und machen so die Architektur einer einzelnen Anwendung als solche bedeutend komplexer.
Performance-Fragezeichen auf Anfragenebene
Der Serverless-Vorteil schlechthin in Sachen Performance ist seine Skalierbarkeit. Egal ob Hunderte Anfragen oder mehrere Millionen, die alle gleichzeitig verarbeitet werden müssen, das System kann völlig problemlos entsprechend skaliert werden.
Die individuelle Performance bei den einzelnen Anfragen selbst ist mit Serverless allerdings weitaus weniger planbar. Für eine Anfrage mögen drei Millisekunden notwendig sein, für eine andere hingegen das Einhundertfache und für wiederum eine weitere lediglich ein Drittel. Präzise Performance-Prognosen sind somit weitaus schwieriger.
Spannend dabei allerdings: Mit zunehmender Skalierung einer Anwendung wird auch die Performance prognostizierbarer. Auf den ersten Blick ist das alles andere als schlüssig und komplett kontraintuitiv, Performance-Ausreißer nach unten zeigen sich jedoch insbesondere bei weniger verwendeten Funktionen (s. Abb. 2). Mit ein Grund hierfür ist im Daten-Caching anzusiedeln. Je mehr Daten sich im Cache befinden und je öfter auf diese zugegriffen wird, desto besser wird die Performance. Beim Zugriff auf Daten, die bisher noch eher ungenutzt geblieben sind, vermag das Caching im Umkehrschluss keinen Beitrag mehr zu leisten.
Abb. 2: Fehleraufschlüsselung
Ganz ähnlich verhält es sich mit Lambda – nicht verwendete Funktionen werden ins Cold Storage verbracht. Für eine erneute aktive Nutzung müssen sie erst aus diesem „aufgewärmt“ und neu gestartet werden. Da dieser Aufwärmprozess und andere Abläufe bei Serverless mit ins Gewicht fallen, sollte dem Kunden das Modell bekannt sein, welches der Infrastrukturpartner zur Planung von Funktionen nutzt.
Signifikante Kostenspannen
Im Gegensatz zu einer klassischen, serverbasierten Anwendungsinfrastruktur variieren die Kosten im Falle von Serverless Computing teils erheblich. Prognosen dafür, wie die Ausführung einer Anwendung finanziell zu Buche schlagen wird, sind daher schwieriger. Eine Investition in etwa Lambda kann sich im drei-, aber auch im siebenstelligen Euro-Rahmen bewegen. Je nach Ausgangslage und für den Anwendungsfall verfügbaren Alternativen kann es sich dementsprechend als äußerst kosteneffizient herausstellen, ebenso aber als finanztechnisch nicht umsetzbar.
Statt die Aufwendungen für Lambda als nominell höher oder niedriger zu beziffern, sind sie also als zusätzliche Variable zu betrachten, deren Planbarkeit gewissen Einschränkungen unterliegt. An dieser Veranschaulichung zeigt sich ganz ausgezeichnet, warum eine Entscheidung für Serverless immer vor allem eine Kontextfrage ist: Vorteilsmerkmale und Parameter müssen im Rahmen des jeweiligen Unternehmens ganz individuell betrachtet, Anwendbarkeit und Potenzial spezifisch abgewogen werden.
Auswahl des geeigneten Anbieters
Der globale Markt für Serverless-Architektur wächst weiter rasant. Mit Amazon, Microsoft, Google, Alibaba, Rackspace, IBM, Oracle und CA Technologies seien an dieser Stelle nur einige Branchenschwergewichte genannt, die enorme Investitionen in Serverless tätigen. Betrachtet man aktuelle Prognosen, verwundert dies wenig. KBV Research [KBV] etwa geht davon aus, dass der Markt für Serverless-Architektur bis 2024 einen Gesamtwert von 14 Milliarden US-Dollar aufweisen wird – dies entspricht einer Wachstumsrate von durchschnittlich 23,4 Prozent im Verlauf der kommenden Jahre.
Serverless Computing ist ein Trend, der auch global zunehmende Aufmerksamkeit erfährt, denn die Entwicklung von Anwendungen per Function-as-a-Service (FaaS)-Methodik als noch modulareres XaaS-Prinzip erweist sich durchaus als probater Wegbereiter einer Serverless-Umgebung. Weniger Klarheit besteht hingegen noch nach wie vor bei der Auswahl eines FaaS-Serverless-Anbieters. Worauf es dabei ankommt, kommentieren wir in vier Parameter aufgeteilt.
Hand aufs Stack-Herz
Zunächst will der Tech-Stack eingeordnet werden: Basiert er etwa zu einem großen Teil auf Microsoft und .NET kommt viel zur Anwendung, ist Azure eine nahe liegende Wahl. Seine Produktionsumgebung ist für Microsoft-Technologien optimiert, die Entwicklungsumgebung besser mit diesen integrierbar.
Wer es eher mit einer der anderen relevanten Programmiersprachen wie Node oder Go hält, ist womöglich mit AWS Lambda besser beraten. Es zeichnet sich aus durch seine Optimierung für eine Vielzahl an Sprachen und hohe Flexibilität bei der Integration seiner Entwicklungsumgebung (s. Abb. 3).
Abb. 3: API Gateway
Ausrichtung auf Business-Anforderungen
Die bestmögliche Serverless-Architektur fußt auf dem Prinzip der Zweckmäßigkeit. Die Frage nach dem Zweck darf also keinesfalls übersprungen oder ungenau beantwortet werden. Geht es etwa darum, eine komplexe Anwendung basierend rein auf Serverless-Services zu entwickeln? Oder soll Serverless lediglich im Rahmen einiger wichtiger Aspekte zur Anwendung kommen (und falls ja, um welche handelt es sich dabei)?
Serverless-Cloud-Technologien wie zum Beispiel AWS Lambda basieren auf Containern. Der Hauptvorteil: Diese muss das Kundenunternehmen nicht verwalten, denn auf einer Serverless-Infrastruktur basierende Anwendungen skalieren automatisch mit ihm.
Zur Ausführung von Code werden idealerweise Serverless-Computing-Services wie AWS Lambda, Azure Functions, Auth0 WebTask oder Google Cloud Functions genutzt. Zudem sollte Anwendungscode in einer Serverless-Architektur so nah wie möglich am Endbenutzer ausgeführt werden, um die Latenz zu minimieren.
Auswahl des richtigen Anbieters
Bei der Entscheidung für einen Serverless-Anbieter gilt es, etwa folgende Fragen zu bedenken:
- Wie verbindlich ist die Entscheidung für einen bestimmten Anbieter?
- Kommt in Zukunft ein neuer Wechsel infrage oder wird dieser in absehbarer Zeit sogar nötig sein?
- Inwieweit können bei weiterem Unternehmenswachstum Konfigurationen, Richtlinien, Technologien usw. modifiziert werden?
- Sind Integrationen mit anderen Anbietern möglich? Können neue innovative Services problemlos hinzugefügt werden?
Natürlich kann die Abhängigkeit von Anbietern durch einige wenige Anpassungen reduziert werden: Wenn der gewünschte Anbieter nur in begrenztem Umfang proprietäre Technologie einsetzt, kann dies helfen. Sie können auch die Nutzung von Diensten einschränken, die einer Migration oder einem möglichen Wechsel zu einem anderen Anbieter im Wege stehen könnten. Für wichtige Dienste sollte der Markt im Voraus auf Alternativen mit vergleichbaren Eigenschaften und Kosten untersucht werden.
Während de facto noch keine Standards für Serverless-Technologien existieren, wurden bereits Frameworks entwickelt, die Kompatibilität zwischen einzelnen Serverless-Plattformen bieten, wie serverless.com. Andere Konsortien, wie die Cloud Native Computing Foundation, arbeiten bereits an der Entwicklung eines übergreifenden Serverless-Standards. Unternehmen, die die Einführung von Serverless in Betracht ziehen, sollten diese Optionen genauer bewerten, um eine besser informierte Entscheidung treffen zu können.
Priorisierungder Umgebung
Bedacht muss ebenfalls werden, ob der Fokus auf der Umgebung für die Entwicklung liegt oder auf der für die Produktion, denn Azure etwa bietet eine Entwicklungsumgebung mit tiefer Integration. AWS Lambda hingegen eignet sich optimal für die Produktion, schneidet jedoch in puncto Entwicklung schwächer ab.
In diesem Zusammenhang spielen insbesondere auch die Art der mit Serverless auszuführenden Anwendung, ihre Skalierung sowie Entwicklungsprozesse und weitere Parameter eine tragende Rolle.
Standort als Performance-Faktor
„Wo sollen die Skripte ausgeführt werden? In welchem Land und in welchem Teil dieses Landes?“ – zwei wichtige, eng miteinander verknüpfte Fragen. Dabei sind Themen wie Latenz und Datenhoheit unbedingt mit einzubeziehen. Da in jedem Land unterschiedliche Gesetze und Vorgaben gelten, ist es wichtig, zu wissen, von wo aus Anbieter die Serverless-Funktionen ausführen und wie sich dies auf die Speicherung der Daten der Kunden sowie auf deren Performance-Erfahrung auswirkt.
Die Einhaltung der DSGVO kann unter anderem durch Partnerschaften mit Kunden zur Nutzung von Services unterstützt werden. So können Kunden beispielsweise relevante Daten in Übereinstimmung mit geltenden Datenschutzgesetzen in den Produkten des jeweiligen Anbieters verarbeiten. Lokale europäische Rechenzentren inklusive Backup-Rechenzentren in der Region für die Notfallwiederherstellung sind hierbei von besonderer Wichtigkeit. Für ein angemessenes Verfahren aller Übertragungen personenbezogener Daten außerhalb des europäischen Wirtschaftsraums geben zum Beispiel Zertifizierungen wie der Swiss-US- als auch des EU-US-Privacy-Shield Aufschluss über die Prozesse von Anbietern.
Serverless: Ein Ausblick
Serverless Computing ist Treiber eines Paradigmenwechsels, bei dem der Fokus weg von der Infrastruktur auf die Anwendungen selbst geleitet wird. Zwei Zahlen signalisieren, dass dieser sich im Jahresverlauf 2020 mit einer gewissen Dynamik festigen wird: Zum einen war da die Zunahme um 206 Prozent bei den wöchentlichen Funktionsaufrufen allein in den vergangenen 12 Monaten. Ebenso erhöhten Unternehmen, die Serverless in der Produktionsumgebung verwenden, die Summe ihrer Funktionen pro Konto um durchschnittlich 178 Prozent [NewR].
Auffällig sind zudem die Spitzen bei den Aufrufen während der Weihnachtszeit als typischer Anwendungsfall für die mit Serverless mögliche Autoskalierung, dessen verstärkte Ausprägung wir sicher nicht zum letzten Mal beobachtet haben. Gerade Branchen wie dem Einzelhandel, der Medienindustrie und der Logistik kommt dies enorm zupass (s. Abb. 4).
Abb. 4: Serverless Dashboard
Viele der größeren technischen Herausforderungen bei Serverless dieses Jahr sind allen verteilten und Microservice-basierten Architekturen gemein. Eine Unmenge an Altsystemen und Codebasen wartet nach wie vor darauf, umgeschrieben zu werden, und die dabei zur Anwendung kommenden Tools sind oft nicht so adäquat, wie erhofft, oder so funktionsreich, wie beworben.
Dabei sollte man sich keinesfalls dazu verleiten lassen, das Konzept Serverless per se als rein technische Entscheidung zu verstehen. Vielmehr geht es schließlich um eine Transformation des Gesamtunternehmens, bei der verschiedenste Geschäftsbereiche sich zu einem Teil auch selbst in einem neuen Licht begreifen sollten. Dies beginnt freilich bei den Entwicklungsteams, die sich vollends auf ihre Metamorphose von Codern zu Problemlösern und Gestaltern hochwertiger Kundenerlebnisse einlassen müssen. Dank Managed-Service-Integrationen und APIs von Drittanbietern kann dieser Wandel auf Rollenebene sogar mit weniger Code bewältigt werden denn je, auch im Falle von FaaS. Mit seinem Ursprung vor einigen Jahren und von manchen bereits als Serviceful und Alternative zu Serverless bezeichnet, wird dieser Aspekt in den kommenden Monaten weiter an Gewicht gewinnen.
Die Umstellung auf Serverless erfordert auch eine Schulung der Mitarbeiter. Allerdings wird der Prozess dadurch deutlich vereinfacht, dass sich Serverless mit Leichtigkeit in Java integrieren lässt. Viel wichtiger ist somit die Ausrichtung der Mentalität auf die neue Technologie.
Eine einfache Funktion strukturiert zur Ausführung zu bringen, ist an sich kein kompliziertes Unterfangen. Die Konzipierung komplexer Anwendungen, die mit mehreren Managed Services kommunizieren, hingegen schon eher.
Obgleich immer mehr Verwaltung der Infrastruktur extern bei Cloud-Providern realisiert wird, benötigen die Entwickler dennoch weiterhin ein klares Verständnis von Anwendungsfällen und Einschränkungen. Dafür sind nicht nur Einblicke in die Funktionsweise der relevanten Managed Services vonnöten, auch mögliche Performance-Optimierungen per Feinjustierung wollen bedacht werden.
Am wichtigsten für den Ernstfall bleibt jedoch die Kenntnis, wie mit den unvermeidbaren Ausfällen und Problemen bei verteilten Systemen umzugehen ist. Hierbei ist zu erwarten, dass mehr und mehr Unternehmen Abstraction as a Service anbieten und dabei Best Practices und Compliance-Anforderungen in Komponenten auf höherer Ebene zusammenfassen, die dann von der Community und Teammitgliedern verwendet werden können.
So zeigt sich: Serverless wird als Thema zunächst komplizierter werden, bevor es sich wieder entzerrt. Dabei eröffnet die Entwicklung nicht nur einen Paradigmenwechsel, sondern wie so oft eine spannende Verzweigung potenzieller innovativer Neuerungen.
Links
[KBV]
Serverless Architectur Market Size, KBV Research, 2018,
https://www.kbvresearch.com/serverless-architecture-market/
[NewR]
For the Love of Serverless, New Relic, 2020,
https://newrelic.com/resources/ebooks/serverless-benchmark-report-aws-lambda-2020
[Rob18]
M. Roberts, Serverless Architectures, 22.5.2018,
https://martinfowler.com/articles/serverless.html