Im heutigen TechUp sprechen wir über ein übergreifendes Thema, das jeden interessieren könnte, der sich Gedanken darüber macht, wie man in einer Zeit der unendlichen Möglichkeiten, die die Cloud bietet, eine effiziente und elegante Architektur für die eigene Business-Domäne gestalten kann. Es geht nämlich um sogenannte Serverless-Patterns, also etablierte Entwurfsmuster, die man auf einem Cloud-Provider wie AWS provisionieren und effektiv nutzen kann. Aber bevor wir einsteigen, möchte ich ein paar Worte zu einem anderen, verwandten Thema verlieren, nämlich der Event-driven Architecture.
Die Welt ist asynchron
An der vergangenen AWS re:Invent 2022 in Las Vegas war das Motto während der Keynote von Werner Vogels, dem bekannten CTO von Amazon, folgendes: “The world is asynchronous”.
Figure: Werner Vogels, CTO Amazon an der AWS re:Invent 2022 in Las Vegas
Er verabreichte den Zuhörern die metaphorische rote Pille der Asynchronizität, also des zeitlichen Versetztseins von Ereignissen, und liess die blaue Pille der Synchronizität, in diesem Fall die simultane Gleichzeitigkeit von Ereignissen, hinter sich. Die rote Pille sei somit wahrhafter und näher an der Realität als der Glaube an die Matrix, in der eine Welt unrealistisch synchron beschrieben wird. Das fand Gehör und so kam auch ich zu der Erkenntnis der grundlegenden Beschaffenheit von Informationssystemen, nämlich dass diese letztendlich immer versuchen, asynchrone Abfolgen abzubilden.
Somit lässt sich dieser Leitgedanke auf die Art und Weise ummünzen, wie wir Technologie und dessen Innovationen angehen. AWS zusammen mit Werner Vogels hat es verstanden, strategisch Dienste und Services auszubauen, welche genau diese realen Bedürfnisse befriedigen können. Worauf Vogels mit der asynchronen Welt hinaus will, ist, dass Technologie stärker auf natives ereignisbasiertes Design ausgelegt sein sollte. Die Konsequenz davon ist eine Entkopplung von Teilkomponenten einer gegebenen Systemarchitektur. Ereignisbasierte Softwareentwicklung, und insbesondere die daraus resultierende Notwendigkeit der Entkopplung von systemtechnischen Abhängigkeiten bringt mich zu einer anderen bekannten Größe in der Tech-Szene…
Event-Driven Architecture
Martin Fowler, eine bekannte Koryphäe, bekannt für Clean Code, Dependency Injection und das Technology Radar unter der Flagge von Thoughtworks, sowie für weitere architektonische Fragestellungen in der IT-Welt, beschreibt Event-Driven-Architekturen (kurz EDA) als ein Muster, bei dem die Anwendung auf Ereignisse reagiert, anstatt auf Anforderungen. Er betont, dass EDA eine gute Möglichkeit ist, Anwendungen zu bauen, die schnell auf Veränderungen reagieren und leicht skalieren können.
Fowler argumentiert, dass EDA die Kommunikation zwischen Anwendungsteilen verbessert, indem es die Abhängigkeiten zwischen ihnen reduziert. Er führt auch an, dass EDA die Flexibilität und Wiederverwendbarkeit von Anwendungsteilen erhöht, da sie unabhängig voneinander auf Ereignisse reagieren können. Das Konzept von Event-Driven ist nicht gerade neu. Ein Meilenstein-Vortrag von Fowler geht bereits zurück auf das Jahr 2017, und seither ist bereits wieder vieles passiert. Ich möchte an dieser Stelle ein Review durchführen und schauen, wie wir Event-Driven auf einen gemeinsamen Nenner bringen und die Vorbereitung für serverless-pattern-basierte Architekturvorschläge vornehmen können.
EDA in Aktion
Also halten wir fest: EDAs sind eine Art von Systemarchitektur, die Ereignisse und asynchrone Kommunikation verwendet, um die Komponenten einer Anwendung lose zu koppeln. EDAs können dabei helfen, die Agilität, also das Tempo, mit dem man auf neue Anforderungen reagieren kann, zu steigern und zuverlässige, skalierbare Anwendungen zu erstellen.
Das bedeutet, dass eines der wichtigsten Merkmale von EDA die lose Kopplung ist. Anstatt eine statische, feste Kopplung von gegenseitigen Abhängigkeiten zu haben, ermöglicht EDA es, Komponenten voneinander zu entkoppeln und zu isolieren. Dies wiederum sorgt dafür, dass die Kommunikation zwischen den Komponenten mehr gewichtet wird und die Möglichkeit von Asynchronität garantiert wird.
Bekannte Design-Patterns aus dem EDA-Handbuch sind folgende:
- Point-to-point Messaging
- Pub/sub-Messaging
- Choreographie und Orchestrierung
- Event-Streaming
- Kopplung von Event-Sources
- Kombinationen aus den vorhergehenden Design-Patterns
Merkmale und Vorteile von EDA
Diese Design-Patterns sind mittlerweile relativ bekannt und werden quasi überall angewandt. Wir haben bei b-nova schon mehrere TechUps veröffentlicht, in denen wir eines oder mehrere dieser Design-Patterns als Konzepte vorgestellt haben. Schaut dort einfach mal vorbei, wenn etwas nicht ganz klar sein sollte. Im Rahmen einer EDA können die Patterns, die wir uns gleich näher anschauen werden, weitere Merkmale neben der losen Kopplung von Komponenten gewährleisten. Diese weiteren kennzeichnenden Merkmale sind folgende:
- Eventual Consistency: EDA gewährleistet eine “endgültige Konsistenz”, was bedeutet, dass alle Änderungen im System schließlich auf alle replizierten Komponenten übertragen werden.
- Variable Latency: Aufgrund der asynchronen Natur von EDA kann es eine variable Verzögerung zwischen dem Auftreten eines Ereignisses und seiner Verarbeitung geben.
- Idempotenz: Dies bezieht sich auf die Fähigkeit einer Anwendung, dieselben Ergebnisse zu erzielen, unabhängig davon, wie oft ein bestimmtes Ereignis auftritt.
- Ordering: In EDA können Ereignisse in einer bestimmten Reihenfolge verarbeitet werden, was wichtig sein kann, um die Konsistenz der Daten zu gewährleisten.
- Testbarkeit durch Test-Pyramide: Die lose Kopplung in EDA erleichtert das Testen einzelner Komponenten und Systeme insgesamt.
Zusammenfassend kann man sagen, dass EDA viele Vorteile bietet, einschließlich erhöhter Skalierbarkeit, Flexibilität und Agilität, sowie der Möglichkeit, asynchrone Kommunikation und lose gekoppelte Komponenten zu nutzen. Dies macht EDA zu einer starken Option für viele moderne Anwendungsarchitekturen.
Das Serverless-Land
Auf dieses Thema bin ich ursprünglich beim letzten AWS-Meetup in Basel gestoßen, bei dem unterschiedliche Architektur-Patterns vorgestellt wurden, die man produktiv auf AWS umgesetzt hatte. Dabei wurde auch eine interessante Website namens Serverless Land präsentiert, die aufzeigt, wie man dort Patterns einsehen und einsetzen kann. Die Patterns sowie der Verweis auf eine AWS-basierte, native Event-Driven-Architektur sind mir im Gedächtnis geblieben und ich wollte der Frage nachgehen, was es dort noch zu lernen gibt.
Serverless-Patterns sind bestimmte Architektur- und Designmuster, die für die Entwicklung von Serverless Anwendungen verwendet werden. Diese Anwendungen werden oft als “serverless” bezeichnet, da sie nicht auf dedizierten Servern ausgeführt werden und die Verwaltung der Serverinfrastruktur an einen Cloud-Anbieter wie AWS, Azure oder Google Cloud ausgelagert wird.
Im Zeitalter von Cloud-Providern wie AWS ist gerade EDA besonders wichtig, da es die Vorteile von AWS-Services wie AWS Lambda, Amazon SNS und Amazon SQS voll ausschöpft. Diese Dienste ermöglichen es Entwicklern, Anwendungen zu erstellen, die auf Ereignisse reagieren und automatisch skalieren, ohne dass sie sich um die Verwaltung von Servern kümmern müssen. Auch die Event-Driven-Funktionalitäten von AWS-Services wie Amazon S3 und Amazon DynamoDB unterstützen die Verarbeitung von Ereignissen in Echtzeit, was die Leistung und Effizienz der Anwendungen erhöht.
AWS-Grundbausteine
Wir wissen wahrscheinlich alle, wie viele Dienste Cloud-Provider wie AWS mittlerweile anbieten. Es ist wichtig zu verstehen, dass ein Grundset dieser Dienste bereits ausreicht, um vollwertige Geschäftsdomänen in einer EDA auf AWS abbilden zu können. Man muss somit nicht alle AWS-Dienste kennen, um eine bedeutende Serverless-Architektur auf die Beine zu stellen. Beginnen wir daher damit, genau dieses Grundset als Grundbausteine für weiterführende Patterns zu identifizieren.
1. AWS Lambda
AWS Lambda ist ein ereignisgesteuerter Serverless Computing-Dienst, der es ermöglicht, Code für nahezu jede Art von Anwendung oder Backend-Dienst auszuführen, ohne Server bereitstellen oder verwalten zu müssen. Du kannst Lambda von über 200 AWS-Diensten und Software-as-a-Service (SaaS)-Anwendungen auslösen und zahlst nur für das, was du nutzt.
2. AWS Step Functions
AWS Step Functions ist ein visueller Workflow-Dienst, der Entwicklern hilft, AWS-Dienste zum Aufbau verteilter Anwendungen, zur Automatisierung von Prozessen, zur Orchestrierung von Microservices und zur Erstellung von Daten- und Machine-Learning-Pipelines zu nutzen.
3. Amazon EventBridge
Entwickle ereignisgesteuerte Anwendungen im grossen Stil innerhalb von AWS, bestehenden Systemen oder SaaS-Anwendungen. Amazon EventBridge ist eine serverless Event-Bus-Lösung, die es ermöglicht, Ereignisse zu empfangen, zu filtern, zu transformieren, zu leiten und zu liefern.
4. Amazon SNS
Amazon Simple Notification Service (SNS) sendet auf zwei Arten Benachrichtigungen, A2A und A2P. A2A bietet eine high-frequency, Push-basierte, many-to-many Nachrichtenübertragung zwischen verteilten Systemen, Mikrodiensten und ereignisgesteuerten serverless Anwendungen.
5. Amazon SQS
Amazon Simple Queue Service (SQS) ermöglicht es, Nachrichten zwischen Softwarekomponenten in jedem Umfang zu senden, zu speichern und zu empfangen, ohne dass Nachrichten verloren gehen oder andere Dienste verfügbar sein müssen.
6. Amazon API Gateway
Amazon API Gateway ist ein vollständig verwalteter Service, der es Entwicklern erleichtert, APIs zu erstellen, zu veröffentlichen, zu warten, zu überwachen und auf jeder Skala abzusichern. APIs fungieren als “Eingangstür” für Anwendungen, um auf Daten, Geschäftslogik oder Funktionen Ihrer Backend-Dienste zuzugreifen.
Noch ein Wort zur Bereitstellung von Patterns
Es gibt unterschiedliche Ausprägungen hinsichtlich der Wiederverwendbarkeit von Serverless-Patterns in der Serverless-Landschaft. Diese Ausprägungen beruhen auf der Art und Weise, wie das Pattern deklarativ bereitgestellt wird. Dabei gibt es folgende Typen:
- AWS Cloud Development Kit (CDK)
- AWS Serverless Application Model (SAM)
- Serverless Framework
- Terraform mit nativen oder Drittanbieter-Modulen
Die Pattern-Landschaft
Auf der Webseite von Serverless Land wird zwischen Patterns und Workflows unterschieden. Zudem werden auch rohe Snippets angeboten, die die Patterns und Workflows ergänzen. Der Unterschied besteht hauptsächlich darin, dass ein Workflow eine Geschäftslogik, oft mit dem Einsatz von AWS Step Functions, implementiert, während Patterns allgemeinere Kombinationen von AWS-Services darstellen, um einen bestimmten Infrastrukturteil abzubilden.
Zwei Beispiele
Bevor wir in den praktischen Teil einsteigen, möchte ich anhand von zwei Fallbeispielen zeigen, wie so ein Pattern aussehen kann. Der praktische Teil folgt zwar noch, aber ich werde ihn in ein dediziertes, zweites TechUp verschieben.
I. Pattern: Step Functions to Glue
Pattern: Serverless Land
Bereitstellung: Terraform
Beschreibung: Das Terraform-Template stellt eine AWS Step Function, einen AWS Glue Job, eine Cloudwatch Event-Rule, einen Amazon S3 Bucket und die minimal erforderlichen IAM-Ressourcen bereit, um die Anwendung auszuführen. Dieses Pattern demonstriert die Verwendung von Terraform-Modulen und stellt die folgenden Ressourcen bereit:
- Amazon S3 Bucket: Lädt das Beispiel-Python-Skript als ein Objekt hoch.
- AWS Glue Job, der das Skript im S3 Bucket ausführt.
- AWS Step Function, die den AWS Glue Job synchron aufruft. Die Funktion wartet, bis der Job abgeschlossen ist.
- Cloudwatch Event-Regel, die so konfiguriert ist, dass sie die AWS Step Function alle 10 Minuten startet.
Schema:
Terraform:
|
|
II. Workflow: Web-Kontaktformular-Verarbeitung
Pattern: Serverless Land
Bereitstellung: Terraform
Beschreibung: Diese Anwendung nutzt einen synchronen Express-Workflow zur Analyse einer Kontaktformulareinreichung und stellt Kunden eine Fallreferenznummer zur Verfügung.
Dieses Beispiel verwendet Amazon API Gateway HTTP APIs, um einen Express-Workflow synchron zu starten. Der Workflow analysiert die Einreichungen von Webformularen auf negative Stimmungen. Er generiert eine Fallreferenznummer und speichert die Daten in einer Amazon DynamoDB-Tabelle. Der Workflow gibt die Fallreferenznummer und den Stimmungswert der Nachricht zurück.
Schema:
Terraform: Siehe hier.
Fazit
Wir haben viel angeschaut: Asynchrone Welt, Event-Driven-Architektur, Vogels und Fowler, Serverless Land, Patterns und Workflows, AWS-Services wie AWS-Lambda oder Step Function, SNS oder EventBridge und vieles mehr. Ich hoffe, dass nicht alle Begriffe neu für dich waren, aber lass uns kurz zusammenfassen, die Vorteile und Risiken dieser Thematik erneut erläutern und ein Urteil abgeben, was wir bei b-nova davon halten.
Eine Event-Driven Architecture ist eine Methodik, die beschreibt, wie man Software mit dem Fokus auf asynchrone, ereignisorientierte Beziehungen architektonisch aufbaut, in denen die Anwendung auf Ereignisse reagiert, anstatt reine Anforderungen statisch umzusetzen. Ein Ereignis kann eine Benutzerinteraktion, eine Datenänderung oder ein Timer-Trigger sein. EDA ermöglicht es, Anwendungen zu erstellen, die leicht skalierbar sind und sich schnell an geänderte Anforderungen anpassen lassen.
Im Zeitalter von AWS-Services ist EDA besonders wichtig, da es die Vorteile von AWS-Services wie AWS Lambda, Amazon SNS und Amazon SQS voll ausschöpft. Diese Dienste ermöglichen es Entwicklern, Anwendungen zu erstellen, die auf Ereignisse reagieren und automatisch skalieren, ohne dass sie sich um die Serververwaltung kümmern müssen. Auch die ereignisgesteuerten Funktionen von AWS-Diensten wie Amazon S3 und Amazon DynamoDB unterstützen die Echtzeitverarbeitung von Ereignissen, was die Leistung und Effizienz der Anwendungen erhöht.
Das Ganze nennt sich dann Serverless, was wiederum eine Art Architektur- und Designmuster ist. Dieses Serverless-Muster wird für die Entwicklung von Anwendungen ohne Server verwendet. Diese Anwendungen werden oft als “serverless” bezeichnet, da sie nicht auf dedizierten Servern ausgeführt werden und die Verwaltung der Serverinfrastruktur an einen Cloud-Anbieter wie AWS, aber auch Azure oder Google Cloud, ausgelagert wird. Serverless-Patterns bieten viele Vorteile, wie z.B. geringere Kosten, höhere Skalierbarkeit und schnellere Time-to-Market. Es gibt jedoch auch einige Einschränkungen, wie z.B. höhere Latenzzeiten und begrenzte Ressourcen. Es sollte sorgfältig überlegt werden, ob es für ein bestimmtes Projekt geeignet ist.
Serverless Land bietet eine Sammlung von Patterns und Workflows an, also eine Vielzahl von etablierten, serverless-basierten Design-Patterns, die sich nahtlos per Infrastructure-as-Code-Tooling wie SAM oder Terraform in die AWS-Cloud übertragen lassen.
Ausblick auf den praktischen Teil
Beim nächsten Mal werden wir den Serverless-Workshop von AWS durchführen, in dem ein fiktiver Business-Case durchgespielt wird, der sich mit dem charmanten Namen Serverlesspresso schmückt.
Dabei werden wir einen Workflow auf AWS abbilden, bei dem verschiedene Serverless-Patterns und drei unterschiedliche Frontend-Apps, einmal für das Display des Cafés, die Anzeige für den Barista und die Anzeige für den Kunden, eingebaut werden. Das wird sicherlich interessant werden und ich hoffe, dass du auch dabei sein wirst.