Kolumne

Serverless vs. Less Server

Lars Röwekamp

© S&S Media

Nach IaaS, PaaS und BaaS ist FaaS das neueste Mitglied der stetig wachsenden „as-a-Service“-Familie in der Cloud. Eine verteilte Anwendung ganz ohne Server, so das Wunschbild. Aber kann das wirklich funktionieren? Und wenn ja, für welche Art von Anwendungen?

„Kein Server ist einfacher zu verwalten als kein Server“, so die Aussage von Werner Vogels, seines Zeichens CTO bei Amazon. Und der muss es ja schließlich wissen, ist Amazon doch aktuell mit AWS einer der führenden Cloud-Service-Anbieter weltweit. „Run Code, not Servers“. Oder etwas plakativer formuliert: „Kein Server, kein Stress“. Genau hier setzt die Grundidee des neuen Hypethemas Serverless an. Aber wie soll das funktionieren? Irgendwo muss der Code doch laufen!

Natürlich kommt auch die Wunderwelt der Function-as-a-Service (FaaS) nicht wirklich ohne einen Server aus. Allerdings ist er für den Anwendungsentwickler mehr oder minder transparent. Der Entwickler programmiert einen Teil der Anwendungslogik in Form einer Funktion, lädt sie hoch in die Cloud und fertig ist die FaaS. Ok, ganz so einfach geht es am Ende dann leider doch nicht. Auch wenn der Begriff Serverless suggeriert, dass es keinen Server gibt, existiert natürlich dennoch eine Laufzeitumgebung für die hochgeladene Funktion. Und die möchte konfiguriert werden – von wem auch immer. Adrian Cockcroft, ehemals Cloud Architect bei Netflix und heute VP Cloud Architectures bei Amazon, beschreibt das in einem seiner Tweets passend mit: „If your PaaS can efficiently start instances in 20ms that run half a second, then call it serverless“.

DevOps vs. NoOps

Es stellt sich also die Frage, was weiterhin in der Verantwortung des Entwicklers bzw. des Operators ist – und was nicht. Es gilt, die Funktion zu konfigurieren. Dazu gehört je nach Anbieter, dass man den zu allokierenden Speicher angibt, einen Time-out setzt, Zugriffsberechtigungen auf und für die Funktion vergibt, Dead Letter Queues für den Fehlerfall definiert und vieles mehr. Darüber hinaus kann und sollte der Entwickler verschiedene Versionen und Aliase für die Funktion verwalten, die er zum Beispiel für ein selbstdefiniertes Staging-Konzept verwenden kann. Schließlich wollen wir ja nicht am offenen Herzen operieren und jede Änderung gleich in Produktion bringen. Von NoOps zu sprechen, wäre also ein wenig zu viel des Guten. Einigen wir uns besser auf LessOps.

Sehen Sie auch im JAX TV: Weniger ist mehr: So baut man Serverless Cloud-Architekturen

Orchestration vs. Composition

Neben der eben erwähnten Konfiguration muss ebenfalls festgelegt werden, wie die Funktion überhaupt angestoßen wird, d. h. wer oder was der Trigger für die Funktion sein soll. Hier wird es jetzt spannend, da dieser Aspekt direkte Auswirkung auf die Architektur der Serverless Application hat. Serverless Functions werden entweder durch einen Request (synchron) oder ein Event (asynchron) angesprochen und im Anschluss abgearbeitet. Wenn möglich, sollte dabei die asynchrone Variante gewählt werden, da ansonsten durch einen verketteten Aufruf mehrerer Funktionen die aufrufenden Funktionen unnötig lange am Leben erhalten bleiben. Das kostet Rechenzeit und somit Geld. Dazu aber später mehr. Da die Funktionen stateless sind, müssen Request oder Event alle zur Abarbeitung notwendigen Informationen mitbringen. Mögliche Auslöser eines Events können – neben der Anwendung selbst – vor allem andere Cloud-Services, wie Datenbanken, File-Systeme, Streaming-Services oder Log-Watcher sein. Eine Serverless Function könnte z. B. darauf reagieren, dass ein Bild im File-System abgelegt oder ein neuer Kunde in der Datenbank angelegt wurde. Auch neue Events innerhalb eines Social-Media- oder Sensor-Daten-Streams oder Exception-Einträge im Logservice kommen als Trigger in Frage. Und auch eine Serverless Function selbst kann Events erzeugen und so indirekt der Auslöser für weitere Funktionen sein.

Anders als beim klassischen Request-Response-Modell kommt es bei der Verwendung von Events nicht zu einer zentralen Orchestrierung der Anwendung, sondern vielmehr zu einer dynamischen, selbstorganisierten Komposition der lose gekoppelten Funktionen. Neue Events und dafür passende Funktionen einzuführen oder die Anwendung um neue Funktionen für bestehende Events zu erweitern, ist denkbar einfach. Die Übersicht über das System zu behalten dagegen weniger. Hier bieten sich Tracing-Services und fachliche Logs an, die wiederum – richtig geraten – durch dafür registrierte Serverless Functions laufend beobachtet und in Hinblick auf Anomalien analysiert werden.

Don’t pay Idle

Sich operativ nicht mehr um die Serverinfrastruktur kümmern zu müssen, ist sicherlich schon einmal erstrebenswert. Fast noch wichtiger am Serverless-Paradigma ist allerdings die Tatsache, dass sich die zugrunde liegende Cloud-Infrastruktur dynamisch dem tatsächlichen Ressourcenverbrauch anpasst und man am Ende nur für eben diese verbrauchten Ressourcen bezahlt. Das macht sich insbesondere bei Anwendungen/Funktionen mit starken Peeks (z. B. im Saisongeschäft) oder nicht kalkulierbarem Wachstumsszenarien bezahlt. Natürlich hat jeder Anbieter auch hier seine Skalierungsgrenzen, die aber in der Regel recht hochgesteckt und im Zweifelsfall individuell verhandelbar sind.

Lesen Sie auch: Ist AWS Lambda das bessere Spring Boot?

Einhundert Prozent Serverless?

Einzelne Funktionen in die Cloud zu verlagern, wie das Generieren von Thumbnails für hochgeladene Bilder oder das Versenden einer Begrüßungsmail für einen neu registrierten Kunden, ist sicherlich noch vorstellbar. Eine Anwendung besteht aber in der Regel aus deutlich mehr. Wo sind also die Grenzen des Machbaren und Sinnvollen? Und wie sähe die passende Architektur aus, wenn eine Anwendung vollständig in die Cloud verlagert werden soll?

Werfen wir zunächst einen Blick auf die potenziellen Kandidaten für Serverless Functions. Bei der Logik einer Anwendung lassen sich grob drei Bereiche unterscheiden. Da ist zunächst einmal diejenige Logik, die zur Abarbeitung keine Serverinformationen benötigt bzw. sie einmalig vom Server bezieht. Diese lässt sich, eine entsprechende Single Page Application (Web) oder native App (Mobile) vorausgesetzt, problemlos auf den Client verlagern. Dann ist da noch die Logik, die auf Standardservices basiert und durch entsprechende Backend-as-a-Service-Funktionalitäten bedient werden kann. Hierzu zählen u. a. Dienste wie Autorisierung und Authentifizierung oder Payment. Was bleibt, ist also anwendungsspezifische Logik, die nicht auf den Client verlagert werden kann. Ursache hierfür ist in der Regel der notwendige Zugriff auf geteilte Ressourcen, z. B. Datenbanken und File-Systeme, Sicherheitsrestriktionen – Credientials haben auf dem Client nichts zu suchen! – oder aber der Zugriff auf 3rd Party Backend-Systeme jenseits der Firewall. Für alle genannten Szenarien käme die Verwendung von Serverless Functions in Frage. Eventuell nicht unbedingt in der öffentlichen Cloud. Aber im Rahmen einer VPC (Virtual Private Cloud) stünde der Verlagerung in die Cloud und somit der Schritt zu hundert Prozent Serverless nichts im Weg.

Ein entscheidender Faktor für Erfolg oder Misserfolg ist dabei die richtige Granularität der Funktionen sowie die bereits erwähnte Komposition, also das Zusammenspiel von Events und Funktionen inklusive einer damit verbundenen Strategie für das Erkennen und die Behandlung von Ausnahmesituationen. Ok, so weit, so gut. Aber was ist mit der Single Page Application selbst? Auch die muss ja irgendwo gehostet werden, damit der Endanwender auf sie zugreifen kann. Auch hier hilft die Cloud durch weltweit verfügbare Content Storage Services und Content Delivery Networks weiter.

Fazit

Mit Amazon (AWS Lambda), Google (Cloud Functions), Microsoft (Azure Functions) und IBM (OpenWhisk) sind mittlerweile nahezu alle großen Player auf den Serverless-Zug aufgesprungen. Dank Function-as-a-Service und der damit einhergehenden Möglichkeit, anwendungsspezifische Logik ohne Verwaltung eines eigenen Servers oder einer eigenen Laufzeitumgebung in die Cloud zu verlagern, ergeben sich völlig neue Möglichkeiten. Aus rein technologischer Sicht gibt es kaum noch Grenzen auf dem Weg zu hundert Prozent Serverless – die Bereitschaft zur Umgestaltung der eigenen Anwendungsarchitektur hin zu einer Event-driven Compute-Service-(aka FaaS-)basierten Architektur einmal vorausgesetzt.

Allerdings bringt der serverlose Ansatz auch neue Herausforderungen mit sich. So muss z. B. eine Strategie zur Erkennung und Behandlung von Ausnahmesituationen innerhalb der lose gekoppelten Cloud-Funktionen her. Gleiches gilt für ein automatisiertes Test- und Deployment-Konzept. Schließlich lässt sich die Cloud-basierte Ablaufumgebung nur schwer lokal simulieren. Dank stetig wachsender Community steht man aber zum Glück nicht allein mit diesen Herausforderungen da, sondern kann auf eine Reihe von Best Practices zurückgreifen. Es ist sicherlich nur eine Frage der Zeit, bis sich aus diesen Best Practices entsprechende Patterns und Frameworks entwickeln werden. In diesem Sinne: Stay tuned!

Geschrieben von
Lars Röwekamp
Lars Röwekamp
Lars Röwekamp ist Gründer des IT-Beratungs- und Entwicklungsunternehmens open knowledge GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als „CIO New Technologies“ mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends. Ein besonderer Schwerpunkt seiner Arbeit liegt derzeit in den Bereichen Enterprise und Mobile Computing, wobei neben Design- und Architekturfragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen. Lars Röwekamp, Autor mehrerer Fachartikel und -bücher, beschäftigt sich seit der Geburtsstunde von Java mit dieser Programmiersprache, wobei er einen Großteil seiner praktischen Erfahrungen im Rahmen großer internationaler Projekte sammeln konnte.
Kommentare
  1. Ups2017-06-21 22:37:45

    DevOps vs. NoOps? --> Als nächstes NoDevs vs. NoIT?

  2. TestP2017-06-22 14:29:27

    NoIT dürfte tatsächlich das langfristige Ziel sein. Mal ehrlich, für die ganzen BWLler ist IT ja auch nur ein Kostenfaktor, den man lieber heute denn morgen entsorgt. Und wenn IT dann wie Strom aus der Steckdose. Damit man das schön als Betriebskosten verrechnen kann.

    MfG

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.