Von Monolith zu Microservices: Der pragmatische Weg mit Serverless und Containern

Die Entscheidung zwischen Serverless-Technologien und Container-Lösungen beschäftigt Entwicklungsteams weltweit. Doch diese Gegenüberstellung führt oft in die falsche Richtung. Anstatt sich auf technische Präferenzen zu konzentrieren, sollten wir uns fragen: Wie können wir die Komplexität reduzieren und die richtige Technologie für den jeweiligen Anwendungsfall wählen?

Das Problem mit der Komplexität verstehen

Wesentliche vs. zufällige Komplexität

In der Softwareentwicklung begegnen uns zwei grundlegende Arten von Komplexität. Die wesentliche Komplexität ist unvermeidlich – sie ergibt sich aus den tatsächlichen Problemen, die wir lösen müssen. Wenn Sie beispielsweise alle verfügbaren Pizzen in einer Anwendung zuverlässig anzeigen müssen, ist das eine inhärente Komplexität des Problems.

Die zufällige Komplexität hingegen entsteht durch unsere technischen Entscheidungen. Ein monolithisches System mit einer einzigen Datenbank hat weniger technische Komplexität als hunderte von verteilten Microservices. Microservices lösen primär soziale Komplexität – wenn zu viele Entwickler am gleichen Code arbeiten und sich gegenseitig behindern.

Serverless als Spektrum verstehen

Serverless ist kein Entweder-oder, sondern ein "Von-Bis". Am einen Ende stehen vollständig gemanagte Lösungen mit minimalem Betriebsaufwand, aber begrenzter Flexibilität. Am anderen Ende bieten selbstverwaltete Container maximale Kontrolle, erfordern jedoch mehr Management und Know-how.

Serverless-Funktionen: Stärken und Herausforderungen

Die Architektur von Function-as-a-Service

AWS Lambda und Azure Functions funktionieren fundamental anders als traditionelle Anwendungen. Während eine ASP.NET Web-API in einem Container läuft und mehrere Anfragen gleichzeitig bearbeitet, verarbeitet jede Lambda-Instanz standardmäßig eine Anfrage zur Zeit. Wenn keine gleichzeitige Verarbeitung konfiguriert wird, führt dies zu einer Architektur aus vielen parallelen Instanzen.

Cold Start: Problem oder Mythos?

Cold Starts werden oft überbewertet. Analysen von AWS zeigen, dass Cold Starts weniger als 1% aller Lambda-Aufrufe ausmachen. Dennoch können sie bei bestimmten Anwendungsfällen problematisch werden, besonders bei synchronen APIs mit strengen Latenzanforderungen.

Skalierung und Datenbankverbindungen

Functions skalieren automatisch, was bei traditionellen Datenbanken zu Problemen führen kann. Während eine herkömmliche Anwendung eine oder wenige Datenbankverbindungen nutzt, kann jede Function-Instanz eine eigene Verbindung benötigen, was die Datenbank schnell überlasten kann.

Container-Technologien: Die pragmatische Alternative

Managed Container Services

Amazon ECS mit Fargate und Azure Container Apps bieten serverless Container-Orchestrierung ohne Kubernetes-Komplexität. Sie ermöglichen es, einfach CPU und Arbeitsspeicher zu spezifizieren und Container auszuführen, ohne sich um die darunterliegende Infrastruktur kümmern zu müssen.

Azure Container Apps: Ein moderner Ansatz

Azure Container Apps abstrahiert die Kubernetes-Komplexität für Entwickler weg. Entwickler definieren Container App Environments und deployen Container Apps mit minimaler Konfiguration. Die Integration mit Dapr (Distributed Application Runtime) bietet zusätzliche Abstraktionen für Service Discovery und Kommunikation.

Flexibles Software-Design: Der Schlüssel zum Erfolg

Ports and Adapters Pattern

Das wichtigste Prinzip ist die Trennung von Geschäftslogik und Infrastruktur-Concerns. Mit dem Ports and Adapters Pattern (auch Clean Architecture genannt) wird die Kerngeschäftslogik von den spezifischen Technologie-Implementierungen entkoppelt.

Von Functions zu Containern migrieren

Mit sauberer Architektur wird die Migration zwischen verschiedenen Hosting-Modellen trivial. Der gleiche Geschäftslogik-Code kann sowohl in Azure Functions als auch in ASP.NET Core Controllern verwendet werden – nur der Adapter ändert sich.

Synchrone vs. asynchrone Anwendungen

Unterschiedliche Anforderungen verstehen

Synchrone Anwendungen haben Benutzer, die auf Antworten warten. Sie benötigen niedrige Latenz, hohe Verfügbarkeit und Zuverlässigkeit. Asynchrone Anwendungen verarbeiten Nachrichten aus Queues oder Event Streams ohne wartende Benutzer und haben entsprechend andere Prioritäten.

Die richtige Technologie für den Anwendungsfall

Container eignen sich hervorragend für synchrone HTTP-APIs mit strengen Performance-Anforderungen. Functions sind ideal für asynchrone Nachrichtenverarbeitung, da sie automatisch auf eingehende Events reagieren und nur bei tatsächlicher Verarbeitung Kosten verursachen.

Praktische Implementierungsstrategien

Hybrid-Ansätze in der Praxis

Ein bewährtes Muster ist die Kombination beider Technologien: Container für synchrone APIs und Functions für asynchrone Verarbeitung. Dies nutzt die Stärken beider Ansätze optimal aus.

Event-driven Architecture

Die Entkopplung über Events ermöglicht flexible Systemarchitekturen. Wenn eine Bestellung abgeschlossen wird, kann ein Event ausgelöst werden, das verschiedene Services zur Aktualisierung ihrer Daten veranlasst, ohne direkte Abhängigkeiten zu schaffen.

Vendor Lock-in: Mythos oder Realität?

Compute vs. Daten

Gut strukturierter Code mit klarer Trennung von Geschäftslogik und Infrastruktur reduziert Vendor Lock-in erheblich. Meist sind es die Daten und gewählten Datenbank-Services, die zu Lock-in führen, nicht die Compute-Plattform.

Pragmatische Entscheidungen treffen

Microsoft's Entscheidung, den TypeScript-Compiler in Go neu zu schreiben, zeigt die Wichtigkeit pragmatischer Technologie-Entscheidungen. Manchmal ist die beste Lösung nicht die neueste oder trendigste, sondern die, die am besten zum Problem passt.

Entscheidungskriterien und Best Practices

Wann Functions wählen?

• Asynchrone Verarbeitung: Message Queues, Event Processing
• Variable Workloads: Unvorhersagbare Spitzenlasten
• Kurze Laufzeiten: Aufgaben unter 15 Minuten
• Minimaler operativer Aufwand: Teams ohne Infrastruktur-Expertise

Wann Container wählen?

• Synchrone APIs: Niedrige Latenz erforderlich
• Lange Laufzeiten: Batch-Jobs über 15 Minuten
• Spezielle Anforderungen: GPU-Computing, spezielle Bibliotheken
• Bestehende Anwendungen: Migration ohne große Refactoring

Monitoring und Observability

Verteilte Systeme verstehen

Unabhängig von der gewählten Technologie ist Observability fundamental für verteilte Systeme. Tracing, Metriken und Logs helfen bei der Entscheidung zwischen verschiedenen Hosting-Optionen und bei der Optimierung der Performance.

Datengetriebene Entscheidungen

Load-Tests mit realistischen Workloads geben bessere Einblicke als theoretische Überlegungen. Functions verhalten sich oft besser unter Last, da sie automatisch skalieren, während Container manuell konfiguriert werden müssen.

Fazit: Die falsche Frage richtig stellen

Die Gegenüberstellung "Serverless oder Container" führt in die Irre. Serverless ist ein operatives Modell zur Komplexitätsreduzierung, während Container ein Packaging-Mechanismus sind. Die richtige Frage lautet: "Kurzlebige oder langlebige Compute-Ressourcen?"

Moderne Anwendungen profitieren oft von einer Kombination beider Ansätze. Container für synchrone APIs mit strengen Performance-Anforderungen und Functions für asynchrone Verarbeitung. Mit sauberer Architektur und klarer Trennung von Concerns bleibt die Flexibilität erhalten, zwischen verschiedenen Hosting-Modellen zu wechseln.

Der Schlüssel liegt darin, sich auf die wesentliche Komplexität zu konzentrieren – die Probleme, die Ihre Benutzer tatsächlich lösen möchten – und die zufällige Komplexität durch pragmatische Technologie-Entscheidungen zu minimieren.

Häufig gestellte Fragen

Kann ich den gleichen Code sowohl in Functions als auch in Containern ausführen?

Ja, mit sauberer Architektur und dem Ports and Adapters Pattern ist dies möglich. Die Geschäftslogik bleibt unverändert, nur die Adapter für das jeweilige Hosting-Modell ändern sich. Einige Unternehmen nutzen sogar den gleichen Container sowohl für Lambda als auch für ECS, je nach Workload-Anforderungen.

Sind Serverless-Funktionen immer teurer als Container?

Nicht unbedingt. Während die Compute-Kosten pro Ausführung bei Functions höher sein können, fallen keine Kosten an, wenn der Code nicht läuft. Bei unregelmäßigen Workloads oder niedrigem Traffic können Functions kosteneffizienter sein. Zusätzlich müssen die Personalkosten für Infrastruktur-Management berücksichtigt werden.

Wie gehe ich mit Cold Starts in kritischen Anwendungen um?

Cold Starts betreffen weniger als 1% aller Function-Aufrufe. Für kritische synchrone APIs können Sie "Always-on"-Features nutzen, Provisioned Concurrency einsetzen oder pragmatisch zu Container-basierten Lösungen wechseln. Oft ist die Wahrnehmung von Cold Starts schlimmer als die tatsächlichen Auswirkungen auf Produktions-Workloads.