Niko Köbler Selbstständig

Wer einfach so weitermacht wie bisher und seine Anwendung einfach nur woanders hin deployen möchte, um Geld in der Cloud zu sparen, wird schnell enttäuscht werden und wahrscheinlich letztendlich sogar auf höheren Kosten sitzen bleiben.

Den Begriff Serverless hat zwischenzeitlich wohl jeder schon gehört. Einige haben schon erste Erfahrungen gemacht, andere ein paar mehr. Viele dürften aber noch am Anfang stehen, da sie zu wenig über das Serverless-Paradigma wissen. Der Begriff Serverless wird sehr kontrovers diskutiert. Die einen finden den Begriff gut und treffend, die anderen lästern über diese Namenswahl. Fakt ist jedoch, dass es nun mal ein Name ist, vorhanden und mittlerweile auch etabliert, der einen bestimmten Sachverhalt bezeichnet. Nutzen wir doch einfach diesen Namen, ohne uns darüber aufzuregen.

Amazon Web Services hat den Begriff Serverless vor ziemlich genau drei Jahren, im November 2014, auf der Hausmesse re:invent, mit dem Dienst AWS Lambda eingeführt. Mittlerweile kann ich auf rund zwei Jahre Erfahrung mit dem Serverless-Ökosystem in der AWS Cloud zurückblicken. In dieser Zeit konnte ich diese noch sehr junge Technologie sehr erfolgreich einsetzen, habe aber auch die eine oder andere negative Erfahrung gemacht, die mich hat lernen lassen.

Serverless Computing Manifesto

  • Functions are the unit of deployment and scaling.
  • No machines, VMs, or containers visible in the programming model.
  • Permanent storage lives elsewhere.
  • Scales per request. Users cannot over- or under-provision capacity.
  • Never pay for idle (no cold servers/containers or their costs).
  • Implicitly fault-tolerant because functions can run anywhere.
  • BYOC – Bring Your Own Code.
  • Metrics and logging are a universal right.

Übrigens: das Serverless-Ökosystem besteht für mich nicht nur aus AWS Lamda. Lambda ist der typische Vertreter, wenn es um Function-as-a-Service geht, was nur ein Subset der Serverless-Welt darstellt. Auch Komponenten wie das API-Gateway, Datastorage wie z. B. S3 und DynamoDB, Messaging Services wie SQS und SNS, Streams wie Amazon Kinesis und viele weitere mehr gehören für mich zum Komplettpaket dazu (Abb. 1). Natürlich gibt es außer AWS noch andere Anbieter von Serverless-Diensten, in diesem Artikel beschränke ich mich jedoch ausschließlich auf meine Erfahrungen mit AWS und hier hauptsächlich auf den Dienst AWS Lambda. Die eine oder andere Erfahrung lässt sich aber durchaus ebenso auf andere Umgebungen übertragen.

Abb. 1: Serverless-Bausteine in AWS

Abb. 1: Serverless-Bausteine in AWS

Anwendungsszenarien

Sehr oft höre ich die Frage, in welchen Szenarien oder wofür man Serverless am besten einsetzen kann. Diese Frage ist gleichermaßen einfach wie auch schwer zu beantworten. Da Serverless keine neue Technologie an sich ist, sondern nur eine weitere Abstraktions-, Virtualisierungs- oder Isolationsebene darstellt, kann damit im Grunde alles gemacht werden, was bislang auf anderen Plattformen ausgeführt wurde.

Ein komplette Webanwendung auf Serverless-Komponenten aufzubauen ist natürlich möglich. In diesem Kontext wird man statische Ressourcen vielleicht in Amazon S3 ablegen, dynamische Inhalte über AWS Lambda mit DynamoDB verwalten, über das API-Gateway den Lambdafunktionen ein API geben, CloudFront für das CDN (Content Delivery Network) verwenden und die unterschiedlichen AWS-Backend-Domains mit Route 53 einheitlich über einen eigenen Domainnamen publizieren. Das ist kein Problem, wird aber sehr schnell sehr komplex, da viele unterschiedliche Services beteiligt sind und viele einzelne, kleine Ressourcen verwaltet werden müssen. Eine gute und aktuelle(!) Dokumentation der beteiligten Komponenten ist unerlässlich. In der AWS-Welt können die AWS Simple Icons dabei helfen, aussagekräftige Architekturdiagramme zu zeichnen.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 3.18 - "20 Jahre Java Magazin"

Alle Infos zum Heft
579827743Serverless Tipps und Tricks
X
- Gib Deinen Standort ein -
- or -