Lohnt sich Serverless? Fallstricke und Chancen

Was bedeutet Serverless?

Serverless Computing (oder Function as a Service, manchmal auch Lambda Functions genannt) gibt es schon eine ganze Weile. Falls ihr es noch nicht wusstet, kommt hier die Überraschung: Serverless-Technologien laufen tatsächlich auf einem Server! Serverless bedeutet aber, dass dieser Server abstrahiert wird – er wird euch als Service bereitgestellt. Ähnlich wie eine virtuelle Maschine die Hardware abstrahiert.

Die ausgereiftesten Serverless-Technologien gibt es in der Public Cloud. Google App Engine, Amazon Lambda und Azure Functions sind sehr leistungsstarke Tools. Im Open-Source-Bereich ist Apache OpenWhisk die beliebteste Lösung.

Wie funktioniert eine Serverless-Architektur?

Bei Serverless erhaltet ihr vom Anbieter ein Framework, um eine Anwendung zu entwickeln. Wenn ihr mit diesem Framework eine Anwendung entwickelt, übernimmt der Anbieter den Betrieb dieser Anwendung in einer vollständig verwalteten Umgebung – daher der Name Serverless.

Und deshalb heißt es Serverless: Eure Anwendung läuft nicht, wenn sie niemand nutzt! Das führt ganz natürlich zu Kosteneinsparungen und vereinfacht den Betrieb etwas, da ihr nicht mehr selbst für die Ausführung eures Codes verantwortlich seid.

Da die Cloud oft die beste Wahl ist, um Ressourcen zu sparen, wird eure Anwendung nur bei Bedarf ausgeführt. Die folgende Abbildung erklärt, was passiert:

1. Ein Entwickler lädt Code in die Cloud hoch

2. Ein Nutzer ruft den Service auf

3. Die Cloud startet eine Instanz des Codes und stellt dem Nutzer die Anwendung bereit

4. Der Nutzer hat die Anwendung nicht mehr geöffnet

5. Die Cloud fährt den Service herunter, bis der nächste Nutzer ihn aufruft

Solltet ihr auf Serverless setzen? Einige Punkte, die ihr beachten solltet

Wie jede Technologie hat auch Serverless einige Einschränkungen. Ich denke gerne, dass jedes technische Problem eine versteckte Chance ist. Sehen wir uns einige Herausforderungen von Serverless an – und wie ihr sie in Chancen verwandeln könnt.

Fakt Nr. 1: Bringt eure Monolithen nicht in die Serverless-Welt!

Das funktioniert einfach nicht und ergibt keinen Sinn. Ein großer Vorteil von Serverless ist, dass es euch dazu zwingt, Cloud Native Software zu entwickeln. Ihr müsst damit rechnen, dass eure Anwendung jederzeit plötzlich heruntergefahren werden kann.

Versucht also nicht, eure zustandsbehaftete Anwendung in Serverless zu bringen, wenn ihr nicht bereit seid, wirklich in die Cloud-Native-Welt zu wechseln. Diese Veränderung ist nicht nur technischer Natur, sondern verändert auch die Art, wie ihr Software entwickelt.

Fakt Nr. 2: Es wird langsamer sein

Serverless ist nicht darauf ausgelegt, maximale Performance zu liefern. Wenn die erste Anfrage eingeht, muss der Code in den Speicher oder auf einen virtuellen Server geladen werden, der eure Anfrage bearbeiten soll und zunächst hochfahren muss. All das kann eure Anwendung verlangsamen.

Die Lösung? Nutzt Serverless nicht für Anwendungen, die geringe Latenzen erfordern. Wenn eure Antwortzeiten durch Serverless langsamer werden, sind Serverless-Technologien wahrscheinlich nicht die richtige Wahl für euch.

Fakt Nr. 3: Monitoring und Logging sind problematisch

Serverless zeichnet sich dadurch aus, dass eure Anwendungsinstanzen nur kurz leben. Was passiert, wenn es ein Problem mit eurer Anwendung gibt? Vielleicht habt ihr ein gutes Logging eingerichtet, doch weil die Instanzen so kurzlebig sind, sind die Logs längst verschwunden, wenn ein Nutzer sich bei euch beschwert.

Das eröffnet eine weitere Chance: Investiert in Cloud-Native Logging. Sendet eure Logs sofort an eine Plattform wie AWS CloudWatch oder Google Stackdriver, die genau dafür ausgelegt ist.

Fakt Nr. 4: Serverless führt zu Vendor Lock-in

Vendor Lock-in ist grundsätzlich ein Thema, das ihr berücksichtigen müsst, wenn ihr euer Geschäft auf einer Cloud-Plattform aufbaut. Je stärker ihr in Serverless-Technologien eines Public-Cloud-Anbieters investiert, desto stärker bindet ihr euch an diesen Anbieter.

Es gibt kein Allheilmittel gegen Vendor Lock-in. In gewisser Weise befindet ihr euch immer in irgendeiner Form von Lock-in. Schon die Wahl eines Frameworks für eure Anwendung oder eures Betriebssystems führt gewissermaßen zu einem Lock-in.

Am wichtigsten ist, dass ihr euch bewusst seid, dass ihr euch in einem Lock-in befindet, und ihn entsprechend abmildert, wenn ihr darin ein Problem seht. Bei Serverless könnt ihr beispielsweise Cloud-agnostische Lösungen wie Apache OpenWhisk nutzen.

Fakt Nr. 5: Ihr müsst euch weiterhin um die Sicherheit kümmern

Sicherheit ist keine Blackbox, die ihr einfach von der Stange kaufen könnt (ich wünschte wirklich, es wäre so!). Das gilt auch für Serverless.

Wenn eure Serverless-Anwendung Cloud-Funktionen wie Blob Storage nutzt, solltet ihr bei der Definition der Berechtigungen eurer Anwendungen für eure Ressourcen besonders sorgfältig vorgehen. Stellt außerdem sicher, dass ihr versteht, wie eure Serverless-Deployments erfolgen, damit problematischer Code tatsächlich durch eure Korrekturen ersetzt wird.

Verlasst euch bei der Sicherheit außerdem nicht auf den Cloud-Anbieter. Meiner Meinung nach sollte das niemand für euch übernehmen.

Serverless: einfach eine weitere Möglichkeit, Kunden Mehrwert zu bieten

Alles in allem ist Serverless einfach ein weiteres Tool. Es soll nichts ersetzen.

Es ist kein Ersatz für Container. Es ist kein Ersatz für Microservices. Es ist einfach ein weiterer Ansatz, um euren Kunden ein großartiges Erlebnis zu bieten.

Die Ergänzung bestehender Cloud-Infrastruktur durch intelligente Serverless-Technologien kann ein vielversprechender Ansatz sein, wenn ihr Services für eure Kunden entwickelt. Oder wenn ihr ein Greenfield-Projekt aufbaut: Denkt an das große Ganze und fragt euch, ob Serverless zu eurer Vision passt.