Drei verbreitete Überzeugungen über Serverless, die Sie ignorieren können

Serverlos ist der aufsteigende Liebling der Cloud-Welt . Mindestens jede dritte (33 %) Organisation hat im letzten Jahr serverlose Apps bereitgestellt. (Quelle: Digital Ocean Q2 2018-Entwicklerumfrage ) Von den Teilnehmern einer CNCF-Umfrage 2018 gaben 38 % an, heute Serverless zu verwenden. Weitere 26 Prozent planen, die Technologie in den nächsten zwölf Monaten zu nutzen.

Diese noch junge Cloud-Option erfreut sich nicht nur großer Beliebtheit, sie wird auch oft missverstanden und mit nahezu übernatürlichen Kräften ausgestattet, Kosten zu senken, die Wertschöpfung zu beschleunigen und Ihnen Frühstück ans Bett zu bringen. 

Und als ob das noch nicht genug Verwirrung gestiftet hätte, gibt es noch die Vermischung von Function as a Service (FaaS) und Serverless. Da diese beiden Begriffe nicht identisch sind, kommt es zu weiteren Missverständnissen darüber, wie ein typisches Unternehmen von dieser tollen neuen Technologie profitieren könnte.

Deshalb werden wir heute mit drei weit verbreiteten Mythen aufräumen, die mir in den letzten sechs Monaten immer wieder von Kunden und Konferenzteilnehmern zu Ohren gekommen sind. Denn Sie müssen verstehen, was die Technologie ist – und was nicht –, bevor Sie herausfinden können, ob es sich lohnt, sich mit ihr zu befassen.

Lassen Sie uns zunächst den Unterschied zwischen Serverless und FaaS klären. 

Mythos: Serverlos === FaaS

Serverlos ist ein System. Eine Plattform. Ein Rahmen. Es lässt sich am besten als eine Just-in-Time-Umgebung mit elastischer Ausführung beschreiben. Serverless versucht, den Betriebsaufwand und die Reibungsverluste zu beseitigen, indem etwas bei Bedarf in einer Art isolierter Umgebung ausgeführt wird. Bei dieser isolierten Umgebung handelt es sich normalerweise um einen Container, es gibt jedoch auch Angebote, die virtuelle Maschinen und Web Assembly verwenden. Der Kürze halber werde ich mit dem Begriff „Container“ im weitesten Sinne alle drei bezeichnen.

Serverlos ist ereignisgesteuert . Dies bedeutet, dass die Bereitstellung und Verarbeitung durch eine Art Auslöser eingeleitet wird, beispielsweise durch das Eintreffen einer API-Anforderung oder wenn die Uhr 14:07 Uhr anzeigt. Es kann sich um ein automatisch generiertes oder interaktives Ereignis handeln, beispielsweise das Drücken einer Schaltfläche in einem Formular in einer Webanwendung. In einem serverlosen Modell initiiert das Ereignis die Ausführung von etwas , das in einem „Container“ vorhanden ist . 

Der „Container“ wird häufig direkt bei der Anforderung aus einem Repository geladen (Kaltstart) oder wartet bereits (Warmstart). Was auch immer in diesem „Container“ vorhanden ist, wird ausgeführt und gibt eine Antwort an das System zurück, das seine Ausführung ausgelöst hat.

Das Serverless-Geschäftsmodell basiert normalerweise darauf, nur für die während der Ausführung des „Containers“ verbrauchten Ressourcen zu zahlen. Das Betriebsmodell besteht darin, alles, was mit dem Betrieb der Umgebung zu tun hat, aus dem Bild zu streichen und den Leuten die Sorge zu überlassen, „etwas“ aufzubauen.

Das ist Serverless. Function as a Service ist eine spezielle Serverless-Nutzung, die „etwas“ als „eine Funktion“ definiert. 

FaaS ermöglicht uns, die Zerlegung von Anwendungen, die mit Microservices begann, bis zu ihrem endgültigen Abschluss – den Funktionen – voranzutreiben.

Zu wissen, dass es einen Unterschied zwischen Serverless und Function as a Service gibt, ist wichtig, um unseren nächsten Mythos zu entlarven.

Mythos: Refactoring erforderlich 

Aufgrund der Zusammenführung von FaaS und Serverless haben viele Marktteilnehmer den falschen Eindruck, dass man seine Anwendung in ihre zusammengesetzten Funktionen umstrukturieren muss, um die Vorteile von Serverless nutzen zu können.

Serverlos erfordert nicht, dass Sie Ihre Anwendung umgestalten oder neue Apps auf funktionaler Ebene entwerfen. Serverlos kann genauso einfach einen „Container“ mit jeder Art von Anwendung, Prozess, Daemon oder Funktion ausführen. Solange es in einem „Container“ verpackt und aufgerufen werden kann, kann es in einem serverlosen Kontext ausgeführt werden.

Ich habe auch erfolgreiche Implementierungen gesehen, die die Vorteile von Serverless nutzen, um bestehende Anwendungsarchitekturen zu erweitern (modernisieren). Die Batch- und Out-of-Band-Verarbeitung von Registrierungen, Auftragserfüllungen und anderen Prozessen des nicht kritischen Pfads kann in einem Serverless-Modell implementiert werden, ohne dass herkömmliche Anwendungen vollständig umgestaltet werden müssen. Für Anwendungen, die für solche Zwecke bereits die Vorteile einer externen, API-basierten Integration nutzen, ist Serverless die bessere Lösung. Bei etablierten Client-Server-basierten Anwendungen sind mit ziemlicher Sicherheit einige Änderungen erforderlich, um die Vorteile von Serverless nutzen zu können. Dies ist jedoch nicht so umfangreich wie bei einer vollständigen Umgestaltung. 

Auch Prozesse, die nur gelegentlich ausgeführt werden – basierend auf bestimmten Ereignissen, die sporadisch oder unvorhersehbar auftreten – können für Serverless gut geeignet sein. Es ist weitaus kosteneffizienter, einen „Container“ regelmäßig zu starten, um etwas auszuführen, als diesen „Container“ ständig laufen zu lassen. Dies gilt sowohl für öffentliche als auch für lokale Serverless-Umgebungen.

Dies bringt uns zum dritten unserer Mythen, bei dem es um den Standort geht.

Mythos: Serverless existiert nicht vor Ort

Ich habe sowohl von IT-Leuten aus aller Welt als auch von Experten diese Behauptung aufgestellt gehört. Dies ist ebenso offensichtlich falsch wie die Vorstellung, dass man die „Cloud“ nicht vor Ort ausführen könne. Das können Sie mit Sicherheit, und laut dem Bericht „State of the Developer Nation“ von Developer Economics trifft dies auch auf einen beträchtlichen Prozentsatz von Organisationen zu.

Auch größere, häufiger genutzte Anwendungen können von einer sehr effizienten Skalierung profitieren, da nur für die speziellen Teile der Anwendung, die stark ausgelastet sind, zusätzliche Ressourcen bezahlt werden müssen und diese auch leichter identifiziert und optimiert werden können. Dieser Vorteil für größere Anwendungen ist wahrscheinlich ein Hauptgrund dafür, dass 17 % der aktuellen Anwender von Serverless Computing eine Lösung in ihrem eigenen Rechenzentrum betreiben.

Die Kosteneffizienzgewinne einer serverlosen Implementierung vor Ort gehen über die Skalierbarkeit hinaus. Die Möglichkeit, dieselben Ressourcen wiederzuverwenden und sie für mehrere Anwendungen gemeinsam zu nutzen, die nur sporadisch genutzt werden, ist nicht unerheblich. Serverless bietet außerdem die Möglichkeit, Anwendungen und Betriebsfunktionen mit Mehrwertfunktionen auszustatten, indem man sich seinen ereignisgesteuerten Kern zunutze macht. Der Einsatz vor Ort sollte nicht leichtfertig abgetan werden, ohne zu verstehen, dass die Vorteile serverloser Architektur weit über die Beseitigung betrieblicher Reibungspunkte im Alltag der Entwickler hinausgehen. Das ist sicherlich ein Segen, aber nicht der einzige Nutzen und sicherlich nicht der einzige Grund, warum Unternehmen vor Ort mit Serverless experimentieren.  

Die Realität sieht also so aus, dass Serverless vor Ort implementiert werden kann und wird. Die oben erwähnte CNCF-Umfrage befasst sich mit den beliebtesten „installierbaren“ Serverless-Plattformen:

• Kubeless (42 % statt 2 %)
• Apache OpenWhisk (25 % statt 12 %)
• OpenFaas (20 % statt 10 %)

Es gibt noch mehr davon, und mit Sicherheit werden noch mehr dazukommen, da sich diese Technologie immer weiter durchsetzt.

Sowohl Serverless als auch Function as a Service erfreuen sich unglaublicher Akzeptanzraten, da Unternehmen an der Technologie herumbasteln, mit ihr experimentieren und sie für den Einsatz sowohl in neuen, Cloud-nativen Anwendungen als auch bei Modernisierungsbemühungen auswerten. Das Erkennen und Ignorieren gängiger Missverständnisse ist ein wichtiger erster Schritt bei der Entscheidung, ob die Technologie für die Anwendungen in Ihrem Unternehmen geeignet ist.