© Enkel/Shutterstock.com
Terraforming Minecraft mit AWS Lambda

Nur Buzzwords oder Heiliger Gral?


Cloud-native Architecture, Terraform und Serverless – wer in der Softwareindustrie hat diese Schlagworte nicht schon mal in den letzten Jahren gehört? Nur ist oft schwieriger auszumachen, was sich hinter diesen Worten verbirgt. Ist es nur ein Hype, während der Großteil der Softwareentwickler noch immer von seinen VM-zentrischen Datenzentren neidisch auf die Cloud schaut? Und während die, die den Sprung in die Cloud gewagt haben, gerade noch mittendrin sind, die Folgen von Docker, Kubernetes und Service Mesh zu operationalisieren. Also nur die letzten Buzzwords, oder doch endlich der Heilige Gral der Softwareentwicklung?

Dieser Artikel will mit Hilfe eines praktischen Beispiels versuchen, ein Stück weit hinter die Buzzwords von Serverless und Cloud-nativen Architekturen zu schauen und ein erstes Gefühl für deren Praktikabilität zu entwickeln. Aufgrund meiner Erfahrungen mit der traditionell VM-zentrischen Anwendungsentwicklung sowie der Möglichkeit, in den letzten Jahren ein SaaS-Produkt basierend auf AWS Serverless entwickelt zu haben, glaube ich, dass ein solches praktisches Beispiel deutlich besser geeinigt ist, um gewisse Grundannahmen in der Anwendungsentwicklung in der Cloud mit Serverless zu illustrieren. Bevor wir allerdings in das Projekt einsteigen, sollten wir erst einmal Begriffe klären, die in der Praxis immer wieder zu Missverständnissen führen.

Serverless ist nicht gleich Serverless

Speziell der Begriff Serverless wird immer wieder genutzt, um verschiedene Dinge zu beschreiben. Im generellen Sinn steht Serverless für eine Applikationsumgebung, in der es für den Softwareentwickler keine Applikationsserver mehr gibt. Das heißt, natürlich gibt es sie noch, aber die Applikationsserver sind für den Entwickler nicht mehr sicht- und konfigurierbar. Die treibende Idee dahinter ist, dass das Aufsetzen, Managen und Skalieren von Applikationsservern inzwischen eine automatisierbare Routinetask geworden ist, die von Cloud-Anbietern „industrialisiert“ wurde. Die ersten Ansätze in dieser Richtung waren AWS Beanstalk und Paas-Plattformen wie Heroku. Allerdings brauchte es erst die Brückentechnologie Docker, damit sich die Automatisierung vom Applikations-Deployment (und damit auch die Skalierung) in der Breite durchsetzen konnte. Wait, what? Brückentechnologie Docker? Ja, meiner Meinung nach ist es eine Brückentechnologie, da es eine applikationsserverzentrische Anwendung durch die Containerabstraktion automatisierbar und skalierbar macht, aber die meisten Docker-Container weiterhin applikationsserverzentrisch sind.

Die Komplexitäten von Docker sind nicht die Container selbst, sondern sie liegen in der operationalen Komplexität von Frameworks wie Kubernetes (auch K8s abgekürzt). Jeder, der sich schon einmal mit Internationalisierung von Softwareprodukten beschäftigen durfte, wird die Analogie zum viel älteren i18n sofort bemerken [1]. Letztendlich erlaubt Docker der IT-Abteilung, die Anforderungen aus mehreren Applikationsservern in spezifischen Clustermanagements in einem einheitlichen und generisches Containermanagement zusammenzufassen. Die operationale Komplexität bleibt die gleiche, aber anstelle von drei oder vier verschiedenen applikationsspezifischen Clustern mit hochspezialisiertem Wissen bedarf es idealerweise nur noch eines Clusters über die gesamte Applikationslandschaft, die jeweils in Docker-Container verpackt worden ist.

Trotzdem ist das nur ein Zwischenschritt, denn aus einer Produkt- und Kundensicht sind operationale Exzellenz und Performance ein Hygienefeature und nur dann sichtbar, wenn es nicht funktioniert. Es wird vom Kunden beim Kauf vorausgesetzt, dass das Produkt verfügbar und performant ist. Dahingehend ist operationale Komplexität eine Kostenstelle, kein Profitcenter. Spätestens jetzt sollte klar sein, warum das Serverless-Konzept hohe Relevanz für die Zukunft haben wird. Wenn es einem Geschäft gelingt, die operationale Komplexität (in die Cloud) auszulagern und in einem Pay-as-you-go zu konsumieren, dann können die verfügbaren Entwicklungskapazitäten zur Entwicklung von kundenrelevanten Features eingesetzt werden.

Aber der Begriff Serverless wird auch in spezifischeren Kontexten benutzt. So kann er zum Beispiel auch das Serverless Framework [2] bezeichnen, das die Serverless-Applikationsentwicklung durch die Abstraktion von den verschiedenen Serverless Runtimes wie AWS Lambda, Azure Function, Google Cloud Functions oder Knative unterstützt. Wobei auch das (bisher) mehr Wunsch als Realität ist, da – wie wir in dem Beispiel sehen werden – ein Serverless Service oft mehr als nur Code braucht, nämlich auch Storage, Topics, Queues etc. Und diese Infrastructure muss bisher in jedem Framework Cloud-spezifisch definiert werden (wie wir an Terraform noch sehen werden). Thematisch könnten wir jetzt in die mit Leidenschaft diskutierte Frage des Cloud-Lock-in einsteigen, die aber den Rahmen dieses Artikels sprengen würde. Für eine tiefergehende Diskussion möchte ich auf den Blogpost von Martin Fowler [3] und meinen Blogpost [4] verweisen.

Last but not least wird der Begriff Serverless auch oft für eine spezifische (Cloud-)Runtime, wie beispielsweise AWS Lambda, genutzt. Auch ich selbst habe im oberen ...

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