© Enkel/Shutterstock.com
Sichtbare und nicht sichtbare Vorteile des Serverless-Paradigmas

FaaS or not to FaaS


In Zeiten, in denen immer größere Datenmengen verarbeitet werden und die Entwicklungsgeschwindigkeit in der IT – um mit der Konkurrenz mithalten zu können – einen zunehmenden Stellenwert hat, wird es immer wichtiger, skalierbar auf ein wachsendes Geschäftsvolumen reagieren zu können und einen schnellen Entwicklungs- und Innovationszyklus zu etablieren. Genau dabei kann Serverless helfen, da ein großer Teil der Komplexität des Betriebs entfällt und man dadurch Geschwindigkeit in die Entwicklung bringen kann.

Natürlich braucht es auch für Serverless noch Server, doch diese sind aus Anwendersicht so weit abstrahiert, dass man sich um Provisionierung und Skalierung nicht mehr kümmern muss. Doch Serverless ist nicht für jede Applikation geeignet. In unserem Artikel gehen wir auf Vor- und Nachteile ein und geben eine Entscheidungshilfe in Form einer Liste mit sechs Punkten, die zu beachten sind, wenn man auf das Serverless-Paradigma setzen möchte. Ebenso zeigen wir, wann es nicht die richtige Wahl ist.

Was macht Serverless in unseren Augen so besonders? Ist es nur ein weiterer Hype, der bald schon wieder vorbei ist? Wir glauben das nicht. Entwickler und Systemadministratoren wissen, wie hart es ist, eine Infrastruktur zu verwalten, und wie viel man dabei wissen und berücksichtigen muss. Viele Versuche, Microservices im Unternehmen einzuführen, sind vor allem im Rechenzentrum gescheitert, weil der Bedarf an unterschiedlicher Infrastruktur deutlich gewachsen ist („Nutze das richtige Werkzeug für deine Arbeit“) und Unternehmen den Betrieb selbst leisten wollten. Eine NoSQL-Datenbank selbst zu betreiben, ist jedoch beispielsweise gar nicht so einfach.

Zudem richtet sich der Fokus oft auf (natürlich wichtige) Themen wie Betreibbarkeit, statt sich erst einmal die Frage zu stellen, welches Problem das Unternehmen eigentlich lösen will. Oft lautet die Antwort darauf, dass Unternehmen in dieser schnelllebigen Zeit der Digitalisierung in hohem Tempo qualitativ hochwertige Features in den Kernbereichen ihrer Anwendungen ausliefern wollen. Natürlich gehören die nichtfunktionalen Anforderungen wie Betreibbarkeit dazu, die Kunden nehmen diese jedoch als gegeben hin.

Die Anwendung muss in den Augen des Kunden einfach nur laufen. Selten ist die Infrastruktur und deren Betrieb das, was das Kerngeschäft des Unternehmens ausmacht, es sei denn, es ist Cloud- oder Rechenzentrumsanbieter. Serverless hilft, den Fokus wieder auf die Businesslogik zu legen. Ein weiterer Vorteil des Serverless-Paradigmas ist die automatische Skalierung zusammen mit dem Pay-per-use-Modell. Wir haben in unserem Unternehmen ip.labs GmbH die schmerzvolle, aber auch wertvolle Erfahrung gemacht, was es bedeutet, eine Infrastruktur selbst zu managen und selbst für die Skalierung zu sorgen. Wir erleben während des Weihnachtsgeschäfts große Peaks (denn genau zu dieser Zeit werden die meisten Fotoprodukte bestellt, wie zum Beispiel Fotobücher mit den Highlights des Jahres oder Jahreskalender). Da unser Unternehmen im Business-to-Business-Segment tätig ist, sind wir zudem auf Forecasts unserer Kunden angewiesen, die naturgemäß ungenau sind. Die Planung für ein Rechenzentrum muss jedoch vorab vorgenommen werden, was mit großen finanziellen Risiken verbunden ist. Eine Kapazitätsplanung ist eine echte Herausforderung und ebenfalls selten das Kerngeschäft des Unternehmens. Es ist eine riesige Hilfe, wenn der Cloud-Anbieter diese übernimmt. Mit Serverless versuchen wir typischerweise Serverless-Dienste miteinander zu verknüpfen, um so wenig Code wie möglich schreiben zu müssen. Und je weniger Code man selbst schreibt, desto weniger muss man selbst warten, desto niedriger sind technische Schulden und desto mehr neue Funktionalität kann man mit dem gleichen Team schaffen.

Paul Johnston fasst das mit seinem Zitat zusammen: „Whatever code you write today is always tomorrow’s technical debt [1].“ Wie oft haben wir erlebt, dass Entwickler bereits nach einem Jahr nur wenig Ownership in Bezug auf ihren eigenen Code verspüren, weil veraltete Paradigmen, Frameworks oder Programmiersprachen verwendet wurden. Für Upgrades hat man selten Zeit, und sie sind gegenüber dem Management nur schwer zu verargumentieren, es sei denn, es entsteht eine Sicherheitslücke oder es ist irgendeine wichtige Komponente im Status End of Support. Man bleibt bei der Wartung des eigenen Codes auf lange Sicht stecken.

Wenn man aber zum Upgrade gezwungen ist, gestaltet sich dieses oft schwierig und aufwendig. Denn meist ist nicht nur das Upgrade der Programmiersprachenversion fällig, sondern oft auch dasjenige der Version des Applikationsservers und der meisten Abhängigkeit, die häufig wiederum selbst Abhängigkeiten mitbringt. Product Owner fragen dann zu Recht, inwieweit es das Produkt verbessert.

Die Situation mit der Wartung frustriert viele Entwickler, vor allem auch dann, wenn ihre Kollegen durch eine andere Vorgehensweise mit modernen und wertschöpfenden Technologien in Berührung kommen. Oft übersehen Unternehmen einen wichtigen Aspekt: Die Kosten für die Wartung der Software über deren gesamten Lebenszyklus übersteigen die Entwicklungskosten deutlich. Der Ausweg heißt hier: So wenig Code zur Erfüllung der Aufgabe schreiben und so wenige externe Abhängigkeiten nutzen, wie es nur geht. Das ganze Drumherum (Infrastruktur, Skalierbarkeit, Konfiguration und Fehlertoleranz) sollte dem Anbieter der Plattform überlassen werden. Was die Unternehmen aber dadurch gewinnen, ist immens – der Fokus auf das Wesentliche, eine schnelle Time to Market und mehr Zeit für Innovation. Genau das wollen alle Unternehmen und genau das ist das Versprechen des Serverless-Paradigmas (über die Hürden sprechen wir noch). Für diese Vorteile kann man auch erhöhte Kosten beim Anbieter in Kauf nehmen (Abb. 1).

bannes_kazulkin_faas_1.tif_fmt1.jpgAbb. 1: Total Cost of Ownership (TCO) des Serverless-Paradigmas

FaaS or not to Faas? Die Entscheidungsliste

Wir haben eine Liste vorbereitet, die bei der Entscheidung hilft, ob Serverless das richtige Paradigma für eure Organisation, euer Business, eure Anwendung oder euren Use Case ist. Dabei ist es nicht unser Ziel, alle Fragen für euch zu beantworten, sondern auf gewisse Herausforderungen aufmerksam zu machen, die es zu meistern gilt. Für allgemeine Herausforderungen skizzieren wir mögliche Lösungsansätze. Dabei werden wir vor allem bei den Begrifflichkeiten und Lösungen auf AWS Cloud setzen, da wir dort das meiste Wissen und die meiste Erfahrung haben.

Die Entscheidungsliste besteht aus den folgenden Punkten:

  1. Applikationslebenszyklus

  2. Architektur und Eigenschaften der Anwendung

  3. Plattform- und Serviceeinschränkungen

  4. Unternehmenswissen

  5. Kostenstruktur von Serverless-Applikationen

  6. Plattform- und Tooling-Reife

Applikationslebenszyklus

Starten wir mit dem Verständnis des Applikationslebenszyklus. Er besteht im Grunde aus zwei Phasen (Abb. 2): Forschung (explore) und Nutzung (exploit) [2]. Für die Forschungsphase ist wichtig:

  • Hypothesen schnell validieren

  • Schnell experimentieren

  • Experimente so günstig wie möglich ausführen

Das Serverless-Paradigma passt hier ideal, da einerseits Geschwindigkeitsvorteile ausgespielt (die meiste infrastrukturelle Arbeit liegt beim Cloud-Anbieter unserer Wahl), andererseits auch die Kostenvorteile ins Feld geführt werden können. Es wird nur das bezahlt, was tatsächlich genutzt wird. Es müssen nicht die recht teuren On-Demand-Preise für die Infrastruktur bezahlt werden, oder die Reservierung der Infrastruktur (typischerweise für ein Jahr oder drei Jahre), die im Vergleich zu On-Demand-Instanzen günstiger ausfällt, aber dafür vorab geplant werden muss. Wir wissen selbst nicht, ob sich unsere Hypothesen bewahrheiten.

bannes_kazulkin_faas_2.tif_fmt1.jpgAbb. 2: Applikationslebenszyklen

Sehen wir, dass wir aus unseren Ideen und Hypothese ein profitables Produkt bauen können (Nutzungsphase), stellen sich für uns folgende Fragen: Wie viel von meinem Stack sollte ich selbst besitzen, um einen geschäftlichen Wert zu erzielen? Will das Unternehmen SLA, Einhaltung gesetzlicher Bestimmungen, Preis, Support und Roadmap an meinen Diensteanbieter komplett auslagern? Viele Unternehmen fühlen sich nicht komfortabel damit, auf viele Managed Services zu setzen und die genannten Punkte nicht unter Kontrolle zu haben. Vor allem wenn das eigene Produkt eine gewisse Marktreife erreicht und bereits viele Benutzer hat.

Dazu gehört eine sehr große Portion Vertrauen in die ausgewählten Anbieter, und diese müssen dieses Vertrauen auch rechtfertigen können. Sollte man bei einem der Features an die Grenzen der Skalierbarkeit eines der Serverless Services stoßen, kann man sich entweder nach vergleichbaren Alternativen beim gleichen Anbieter umschauen oder auf ein anderes Paradigma setzen. Eine Kostenkontrolle in Serverless-Applikationen ist nicht mehr so trivial, denn diese Kosten können extrem hoch sein, wenn man die entsprechenden Prozesse nicht etabliert.

In der Nutzungsphase werden die meisten Unternehmen eine ausgewogene Balance zwischen Serverless und anderen Architekturen und Paradigmen suchen. Außerdem haben viele Unternehmen bereits Anwendungen im Einsatz und können sich das komplette Umschreiben nicht leisten. Jedoch ist es der Wunsch jedes einzelnen Unternehmens, in seinen Kernbereichen Geschwindigkeit aufzubauen. Paradigmen wie Serverless tragen zu einer solchen Modernisierung der bestehenden Anwendung durchaus bei.

Eine der etablierten Methoden dabei ist das Strangler Pattern [3], das Martin F...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang