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.

Hinter Serverless steht meist ein Geschäftsmodell, bei dem Sie nur für die Ressourcen zahlen, die während der Laufzeit des „Containers“ verbraucht werden. Im Betriebsmodell nehmen wir Ihnen alles rund um den Betrieb der Umgebung ab, damit Sie sich ganz darauf konzentrieren können, etwas zu schaffen.

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.

Größere, stärker genutzte Anwendungen profitieren ebenfalls von sehr effizienter Skalierung, indem Sie nur für die zusätzlichen Ressourcen zahlen, die die stark belasteten Teile der Anwendung tatsächlich benötigen, und diese leichter identifizieren und optimieren können. Dieser Vorteil für größere Anwendungen erklärt wahrscheinlich, warum 17 % der aktuellen Nutzer von Serverless Computing ihre Lösung im eigenen Rechenzentrum betreiben.

Die Kosteneffizienzvorteile einer serverlosen Implementierung vor Ort gehen über die reine Skalierbarkeit hinaus. Die Möglichkeit, Ressourcen mehrfach zu nutzen und sie mit Anwendungen zu teilen, die nur gelegentlich verwendet werden, ist keineswegs unerheblich. Serverless ermöglicht außerdem, Anwendungen und operative Funktionen durch den eventgesteuerten Kerncharakter um wertschöpfende Fähigkeiten zu erweitern. Wir sollten den Einsatz vor Ort nicht leichtfertig abtun, denn die Vorteile von Serverless reichen weit über die reine Beseitigung von Arbeitshemmnissen im Entwickleralltag hinaus. Das ist zweifellos ein Vorteil, aber es ist weder der einzige Nutzen noch der alleinige Grund, warum Unternehmen Serverless vor Ort erproben.  

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.