Implementierung von Microservices in Produktionsumgebungen

Informatec Digital » Ressourcen » Implementierung von Microservices in Produktionsumgebungen

Die Einführung einer Microservices-Architektur in der Praxis bedeutet mehr als nur die Aufteilung eines monolithischen Systems in kleinere Komponenten. Sie erfordert ein grundlegendes Umdenken in Bezug auf Infrastruktur, Teams, Prozesse, Daten, Sicherheit und Betrieb . Beim Übergang von der Theorie in den Produktivbetrieb treten Probleme hinsichtlich Service Discovery, Verträgen zwischen Teams, CI/CD, Observability, Ausfallsicherheit und Skalierbarkeit auf. Werden diese Probleme nicht adäquat gelöst, kann die Microservices-Architektur in ein verteiltes Chaos münden.

Die gute Nachricht ist, dass wir heute auf einen reichen Erfahrungsschatz von Unternehmen wie Netflix, Amazon, Google und anderen Großkonzernen zurückgreifen können, die Hunderte von Microservices produktiv einsetzen . Aufbauend auf diesen Erkenntnissen und den Best Practices aus Unternehmensumgebungen mit Kubernetes und OpenShift können wir einen äußerst robusten Ansatz für die Entwicklung, Bereitstellung und den Betrieb von Microservices in großem Umfang entwickeln, ohne dabei die Kontrolle zu verlieren.

Warum Microservices in der Produktion einsetzen (und wann es sich nicht lohnt)

Eine gut konzipierte Microservices-Architektur ermöglicht die Arbeit mit kleinen, autonomen und funktionsübergreifenden Teams , die die Verantwortung für einen durchgängigen Service übernehmen. Jedes Team arbeitet in einem klar definierten Kontext, kann häufig deployen und trägt die volle Verantwortung für seinen Service. Dadurch werden Entwicklungszyklen verkürzt und die Bereitstellung neuer Funktionen beschleunigt.

Ein weiterer entscheidender Vorteil ist die unabhängige Skalierung jedes einzelnen Dienstes . Sie müssen nicht die gesamte Anwendung überdimensionieren, wenn nur der Katalog, der Checkout oder die öffentliche API Lastspitzen verzeichnen. Sie können jeden Microservice horizontal oder vertikal an sein Lastmuster anpassen, die Kosten jeder Funktion präzise messen und die Verfügbarkeit auch bei einem plötzlichen Nutzungsanstieg in einem bestimmten Bereich aufrechterhalten.

Die Art und Weise, wie diese Dienste verpackt und bereitgestellt werden, ermöglicht eine kontinuierliche und risikoarme Implementierung . Die unabhängige Veröffentlichung jedes Microservice vereinfacht das Testen neuer Ideen und das Zurücksetzen problematischer Versionen erheblich: Canary-Deployments, Blue/Green-Rollbacks und automatisierte Rollbacks reduzieren die Kosten von Fehlern und bieten Raum für Experimente.

Aus technologischer Sicht bieten Microservices die Freiheit, Sprachen, Frameworks und Datenbanken für jeden Dienst individuell auszuwählen . Nicht alle Anforderungen lassen sich mit demselben Technologie-Stack realisieren: Geschäftsdienste können beispielsweise in .NET oder Java, Datenverarbeitung in Scala/Spark, spezialisierte Dienste in Python oder F# oder KI-Microservices in R implementiert sein. Diese kontrollierte Vielfalt ermöglicht es, für jeden Anwendungsfall das passende Werkzeug einzusetzen, ohne die gesamte Anwendung einem globalen Technologiewechsel unterziehen zu müssen.

Darüber hinaus erleichtert die Aufteilung des Systems in kleine, klar definierte Einheiten die Wiederverwendung von Funktionalitäten als Bausteine . Ein ursprünglich als Teil einer größeren Funktionalität entwickelter Microservice kann später als Abhängigkeit anderer Systemteile wiederverwendet werden, ohne dass die Logik neu geschrieben werden muss. Da die Services isoliert sind, führt ein Ausfall eines Services in der Regel nur zu einer teilweisen Systembeeinträchtigung und nicht zu einem vollständigen Systemausfall, vorausgesetzt, die Ausfallsicherheit wurde von Anfang an berücksichtigt.

Architektur- und Serviceplanung

Damit Microservices im Produktivbetrieb reibungslos funktionieren, ist eine sorgfältige Gestaltung der Servicegrenzen und Verantwortlichkeiten unerlässlich . In der Praxis beginnt dies üblicherweise mit der Identifizierung grobkörniger Services innerhalb des bestehenden Monolithen: große Funktionsbereiche oder Geschäftsdomänen (z. B. Bestellungen, Katalog, Benutzer, Abrechnung), die bereits eine gewisse logische Trennung aufweisen.

Ausgehend von diesen großen Bausteinen besteht der Prozess darin, das Design zu verfeinern, um fein abgestufte Microservices zu erhalten, die mit einem zusammenhängenden Datensatz arbeiten , ihr eigenes Datenmodell besitzen und genau wissen, welche Daten sie von anderen Diensten lesen oder in diese schreiben müssen. Dieser Prozess basiert typischerweise auf Konzepten des domänengesteuerten Designs (DDD) und abgegrenzten Kontexten, wodurch verhindert wird, dass ein Microservice zu einem „Mini-Monolithen“ wird.

Die APIs, die diese Dienste bereitstellen, müssen über klar definierte und stabile Verträge verfügen . Dies impliziert eine sorgfältige Dokumentation (REST mit OpenAPI, gRPC mit .proto-Dateien usw.), eine explizite Versionierung, die Wahrung der Abwärtskompatibilität, wo immer möglich, und die automatisierte Vertragsvalidierung, um inkompatible Änderungen zu erkennen, bevor sie in der Produktion zum Einsatz kommen.

In Umgebungen mit Dutzenden oder Hunderten von Diensten ist es entscheidend, bereits in der Entwurfsphase Resilienzmechanismen zu integrieren, um das System auf Teilausfälle vorzubereiten . Mechanismen wie Schutzschalter, Wiederholungsversuche mit Backoff, klar definierte Timeouts, Schottwände und Gegendruck verhindern, dass der Ausfall eines Dienstes den Ausfall der übrigen Dienste zur Folge hat. Werkzeuge für Chaos Engineering wie ChaosMonkey oder Gremlin eignen sich, um das Verhalten der Plattform unter simulierten Ausfällen praktisch zu testen.

Viele komplexe Systeme kombinieren relativ einfache CRUD-Dienste mit anspruchsvolleren Diensten, die sich ändernde Geschäftsregeln verarbeiten. Nicht alle Microservices benötigen eine komplexe interne Architektur : Manche können einfache HTTP-Controller mit grundlegendem Datenzugriff sein, während andere, wie beispielsweise Bestell- oder Abrechnungsdienste, fortgeschrittenere Muster (DDD, CQRS, Domänenereignisse usw.) nutzen können.

Produktionsinfrastruktur: Cloud, Container und Kubernetes/OpenShift

Die Praxis zeigt, dass Microservices in Cloud-Infrastrukturen mit Containern und Orchestrierung deutlich besser funktionieren als auf isolierten virtuellen Maschinen. Plattformen wie Kubernetes und OpenShift bieten die notwendigen Basisfunktionen, um Dienste als Container zu verpacken, zu skalieren, zu aktualisieren, Lasten auszugleichen und Hochverfügbarkeit zu gewährleisten.

Typischerweise wird jeder Microservice in einem Container-Image verpackt, das auf einem unternehmensweiten Basis-Image basiert (z. B. OpenJDK 21 für Java-Services) und vom Infrastrukturteam verwaltet wird. Dieses Basis-Image wird durch Sicherheitspatches auf dem neuesten Stand gehalten. Bei der Veröffentlichung einer neuen Version sind die Entwicklungsteams für die Neukompilierung und Bereitstellung ihrer Services in den entsprechenden Umgebungen verantwortlich.

In Kubernetes/OpenShift ist die grundlegende Bereitstellungseinheit der Pod, der einen oder mehrere Container kapselt . Typischerweise entspricht ein Microservice einem Pod-Typ und wird mithilfe von Ressourcen wie Deployments (für zustandslose Dienste) oder StatefulSets (wenn ein Zustand vorhanden ist) bereitgestellt. Von Anfang an wird eine Mindestanzahl an Replikaten pro Umgebung definiert, um sicherzustellen, dass Test-, Vorproduktions- und Produktionsumgebungen über eine ihrer Kritikalität entsprechende Verfügbarkeit verfügen.

Die automatische Skalierung erfolgt mittels HorizontalPodAutoscaler (HPA) , der die Anzahl der Replikate anhand von Metriken wie CPU-Auslastung, Speicherauslastung oder anderen benutzerdefinierten Metriken anpasst. Die Plattform muss zudem Pod-Anti-Affinitätsregeln konfigurieren, um Replikate desselben Dienstes auf verschiedene Knoten zu verteilen und so zu verhindern, dass der Ausfall eines einzelnen Knotens alle Instanzen beeinträchtigt.

Bezüglich der vertikalen Dimensionierung werden ` resources.requests` und `resources.limits` verwendet , um den CPU- und Speicherverbrauch eines Pods festzulegen. Beispielsweise werden für einen Java-Dienst mindestens 100 MB CPU und 256 MB Speicher reserviert und maximal 500 MB bzw. 2 GB Speicher zugelassen. Die JVM (Xms, Xmx, XSS) wird entsprechend angepasst, um die Containerressourcen optimal zu nutzen.

Zustandsverwaltung: zustandslose und zustandsbehaftete Microservices

Die meisten Microservices in Unternehmen sind als zustandslose Dienste konzipiert . Das bedeutet, dass der Pod keine Informationen speichert, die einen Neustart überstehen müssen; der Zustand wird in externen Datenbanken, Message Queues oder anderen Speichern persistent gespeichert. Dieser Ansatz ermöglicht dynamische horizontale Skalierung und reibungslose Bereitstellungen, da jede Replik jede Anfrage bearbeiten kann.

Es gibt jedoch Szenarien, in denen zustandsbehaftete Microservices mit persistenten Volumes unerlässlich sind . Dies trifft beispielsweise auf einige Datenbanken, verteilte Dateisysteme oder Komponenten zu, die lokale Daten verwalten müssen. Diese Pods werden typischerweise mit StatefulSets bereitgestellt, die über PersistentVolumeClaims mit PersistentVolumes verknüpft sind, und skalieren vertikal statt horizontal.

Benötigt ein Microservice persistenten Speicher, wird ein PersistentVolumeClaim (PVC) mit Angabe von Größe, Zugriffsmodus und Verwendungszweck angefordert und vom Betriebsteam gemäß den Plattformrichtlinien bereitgestellt. Dieser PVC wird im Deployment-Manifest referenziert und im Pod eingebunden, sodass der Service Daten persistent lesen und schreiben kann.

Obwohl zustandsbehaftete Modelle in bestimmten Fällen notwendig sein können, wird generell empfohlen, so viele Dienste wie möglich zustandslos zu halten . Dies vereinfacht Bereitstellung, Skalierung, Ausfallsicherheit und Notfallwiederherstellung und reduziert die betriebliche Komplexität in Umgebungen mit vielen Microservices.

Datendezentralisierung und Dienstsouveränität

In traditionellen Infrastrukturen ist es üblich, Datenbanken und Speicher zu zentralisieren, um die Effizienz zu maximieren. Bei Microservices steht dieser Ansatz im Widerspruch zur Teamautonomie und Entkopplung . Wenn viele Dienste dasselbe relationale Schema verwenden, kann jede strukturelle Änderung mehrere Teams blockieren und unbeabsichtigt die Kompatibilität beeinträchtigen.

Daher empfiehlt es sich, dass jeder Microservice sein eigenes Datenmodell und seine eigene Datenbank besitzt . In einer Entwicklungsumgebung läuft diese Datenbank als Container innerhalb des Clusters, um die Bereitstellung zu vereinfachen. Im Produktivbetrieb werden typischerweise Cloud-basierte Instanzen oder andere hochverfügbare Datenbankserver eingesetzt, wobei stets eine klare Zuständigkeitsgrenze gewahrt bleibt.

Das bedeutet nicht, dass keine Datenintegration stattfindet; vielmehr wird die Konsistenz zwischen Diensten durch Ereignisse und asynchrone Nachrichtenübermittlung sichergestellt , wobei gegebenenfalls auch letztendliche Konsistenz akzeptiert wird. Häufig werden Ereignisbusse (wie RabbitMQ, Azure Service Bus oder Kafka) eingesetzt, um Zustandsänderungen zwischen Microservices zu verbreiten und so starke Abhängigkeiten von einer einzelnen Datenbank zu reduzieren.

Die Cloud-Plattform ermöglicht es Teams, den optimalen Datenbanktyp für jeden Dienst (relational, dokumentenbasiert, Key-Value, Zeitreihen usw.) einfach auszuwählen , ohne eine bestimmte Technologie vorzuschreiben. Entscheidend ist, dass das Design die Möglichkeit der Migration von Schemata und Strukturen berücksichtigt, ohne die Kompatibilität mit anderen Diensten zu beeinträchtigen, und dass Datenentscheidungen im Einklang mit den Domänengrenzen jedes Microservice getroffen werden.

Dezentrale Führung, Teams und Organisation

Die Umstellung auf Microservices ohne organisatorische Anpassung birgt Risiken. Anstelle der klassischen funktionalen Silos von Netzwerken, Systemen, Datenbanken, Entwicklung und Betrieb wird eine Struktur auf Basis von Produktteams empfohlen, die Profile aus Entwicklung, Qualitätssicherung, DevOps und gegebenenfalls Business- oder Datenanalysten zusammenführt.

Jedes Team ist für einen oder mehrere Microservices innerhalb desselben Funktionsbereichs verantwortlich und übernimmt sowohl die Entwicklung als auch den Betrieb (Entwicklung und Betrieb) . Das bedeutet, dass das Team seine CI/CD-Pipelines verwaltet, bei spezifischen Anforderungen mit der Infrastruktur zusammenarbeitet und sich an Monitoring und Incident Response beteiligt. Die Infrastruktur und die Cloud-Plattform konzentrieren sich auf die Bereitstellung gemeinsamer und standardisierter Services.

Um zu verhindern, dass diese verteilte Governance in Anarchie abgleitet, ist es entscheidend, schlanke Standards und gemeinsame Kataloge zu definieren : genehmigte Basis-Images, Bereitstellungsmuster, Namenskonventionen für Namensräume und Dienste, API-Richtlinien, Dockerfile- und Kustomize-Vorlagen usw. Diese Richtlinien dienen als „Leitplanken“, die Teams Orientierung geben, ohne ihre Entscheidungsfähigkeit einzuschränken.

In vielen Unternehmensumgebungen werden für jedes Projekt oder jede Domäne separate Namensräume verwendet , mindestens einer pro Umgebung (Entwicklung, Vorproduktion, Produktion). Ein großes Projekt kann seine Microservices auf mehrere Namensräume verteilen, sofern die interne Kommunikation korrekt konfiguriert und die Sicherheitsregeln eingehalten werden.

CI/CD, Automatisierung und das GitOps-Modell

Wenn eine Architektur Dutzende oder Hunderte von Microservices umfasst, lässt sich deren Betrieb nur durch hohe Investitionen in die End-to-End-Automatisierung gewährleisten . Dies beinhaltet konsistente CI/CD-Pipelines, deklarative Bereitstellungsdefinitionen, automatisierte Tests und automatische Rollback-Mechanismen.

Eine typische CI/CD-Pipeline (Continuous Integration/Continuous Delivery) übernimmt das Kompilieren von Code, das Ausführen von Tests, die Qualitätsanalyse mit Tools wie SonarQube , das Erstellen des Container-Images aus dem unternehmenseigenen Dockerfile und das Aktualisieren der Deployment-Manifeste. Anschließend wendet ein System wie ArgoCD oder ein ähnliches die Änderungen mithilfe eines GitOps-Ansatzes auf den Cluster an.

Jedes Microservice-Repository enthält typischerweise ein standardisiertes Dockerfile, eine Pipeline-Konfigurationsdatei (z. B. ci.json) , Eigenschaften für die Qualitätsanalyse und ein Deployment-Verzeichnis mit Kubernetes-Definitionen (Kustomize oder Helm), getrennt nach Umgebung. Die Webhooks des Repositorys lösen die Pipeline bei Ereignissen wie Tag-Pushes oder Merge-Requests aus.

Das GitOps-Muster etabliert das Git-Repository als zentrale Datenquelle für Infrastruktur und Deployment . Manifeste für Deployments, Services, ConfigMaps, PVCs, SealedSecrets und andere Ressourcen werden dort versioniert, und spezielle Tools synchronisieren den Clusterstatus mit den Git-Definitionen. Dies ermöglicht Nachverfolgbarkeit, Pull-Request-Reviews und einfache Rollback-Funktionen.

Einstellungen, Geheimnisse und Sicherheit

In einer ausgereiften Microservices-Plattform basiert das Konfigurationsmanagement auf ConfigMaps für nicht-sensible Parameter und Secrets für vertrauliche Informationen . Jeder Microservice verfügt typischerweise über eine eigene umgebungsspezifische ConfigMap, die Eigenschaften wie URLs abhängiger Dienste, Funktionsflags und Optimierungsparameter speichert.

Geheimnisse (Anmeldeinformationen, Schlüssel, Token, Zertifikate) werden mit strengen Sicherheitsrichtlinien behandelt . In weniger kritischen Umgebungen kann es akzeptabel sein, sie im Klartext zu speichern und vom Entwicklungsteam verwalten zu lassen. In Vorproduktions- und Produktionsumgebungen wird jedoch empfohlen, sie mithilfe von Tools wie Sealed Secrets oder speziellen Cloud-basierten externen Managern zu verschlüsseln.

Wenn ein Geheimnis zwischen mehreren Diensten geteilt werden muss (z. B. OTEL Collector-Zugangsdaten oder ein gemeinsamer Keystore ), kann es in einem Konfigurations-Repository pro Namespace zentralisiert werden. Projekte, die diesen Namespace gemeinsam nutzen, koordinieren die Aktualisierung und behalten so die Kontrolle darüber, wer diese Ressourcen lesen oder ändern darf.

Im Bereich der Kommunikationssicherheit dominiert das Zero-Trust- Konzept : Nichts wird als selbstverständlich angesehen, nur weil der Datenverkehr „intern“ ist. Alle Aufrufe zwischen Diensten, sowohl intern als auch extern, müssen authentifiziert und autorisiert werden, idealerweise mit mTLS, JWT-Token oder anderen gleichwertigen Mechanismen. Microservices delegieren die Sicherheit nicht blind an den API-Manager oder das Netzwerk, sondern führen eigene Prüfungen durch.

Kommunikation zwischen Microservices, APIs und Messaging

In einer ausgereiften Microservices-Architektur ist die Kommunikationsschicht in verschiedene Bereiche unterteilt. Für den Datenverkehr von Clients (Browsern, mobilen Apps, Drittanbietern) zum Backend werden veröffentlichte APIs verwendet, die von einem API-Manager verwaltet werden . Diese APIs sind typischerweise RESTful (oft mit OpenAPI) oder, in einigen Fällen, gRPC-APIs, die über ein Gateway bereitgestellt werden.

Aufrufe zwischen Microservices im selben Namespace oder sogar über mehrere Namespaces innerhalb desselben Projekts hinweg werden typischerweise von internen Kubernetes-Services mit internem DNS abgewickelt . Diese Aufrufe umgehen den öffentlichen API Manager, halten sich aber an die Sicherheits-, Authentifizierungs- und Autorisierungsrichtlinien. Für solche Szenarien können ein Service Mesh oder interne Gateways zur Durchsetzung gemeinsamer Richtlinien verwendet werden.

Wenn Microservices zu verschiedenen Funktionsbereichen oder Projekten gehören , gilt die Kommunikation auf Organisationsebene als „öffentlich“. In diesen Fällen ist es üblich, einen API-Manager oder einen Interoperabilitätsbus zu verwenden, über den Verträge, Kontingente, Sicherheit, Versionierung und Auditierung verwaltet werden, um eine direkte Kopplung zwischen unabhängigen Clustern oder Namensräumen zu verhindern.

Bei der Integration mit Legacy- oder externen Systemen, die möglicherweise nicht immer moderne APIs bereitstellen, ist es üblich, über einen Interoperabilitätsbus auf spezielle Konnektoren zurückzugreifen . Dadurch sprechen Microservices eine gemeinsame Sprache (z. B. Ereignisse oder interne REST-APIs), und der Konnektor übernimmt die Übersetzung zum und vom Legacy-System – stets mit erhöhter Sicherheit.

Neben der synchronen Kommunikation spielt die asynchrone Nachrichtenübermittlung eine Schlüsselrolle . Sie dient der Entkopplung von Prozessen, dem Abfangen von Lastspitzen, der Weiterleitung von Geschäftsereignissen zwischen Diensten und der Verbesserung der Ausfallsicherheit. Jedes Ereignis folgt typischerweise einem klar definierten und versionierten Schema mit Tracking-Mechanismen, um Störungen zwischen Produzenten und Konsumenten im Verlauf der Entwicklung zu verhindern.

Beobachtbarkeit, OTEL-Kollektor und Betrieb

In einem System mit vielen Microservices ist die Fehlerdiagnose ohne gute Beobachtbarkeit nahezu unmöglich. Deshalb werden Metriken, zentralisierte Protokollierung und verteilte Traces bereits in der Designphase integriert , um ein umfassendes Verständnis der Vorgänge sowohl auf Service- als auch auf Plattformebene zu ermöglichen.

Ein zentraler Bestandteil dieses Systems ist der OpenTelemetry Collector (OTEL Collector) , der im Namespace oder zentral bereitgestellt wird, um Metriken, Logs und Traces von allen Komponenten zu erfassen. Microservices müssen lediglich wissen, dass sie ihre Telemetriedaten an den Collector senden sollen; dieser leitet sie dann an die Observability-Systeme (Prometheus, Grafana, Jaeger, Elastic usw.) weiter, ohne dass der jeweilige Service die Details kennen muss.

Auf der Infrastrukturschicht werden Knoten-basierte Collector und Exporter eingesetzt , um CPU-, Speicher-, Festplatten-, Netzwerk- und Log-Metriken von den Pods zu erfassen und an Prometheus bzw. Elasticsearch zu senden. Tools wie Grafana und Kibana dienen der Visualisierung dieser Informationen, der Erstellung von Dashboards und der Definition von Warnmeldungen mit intelligenten Schwellenwerten und zugehörigen Runbooks.

Wenn ein Projekt eine sehr spezifische Verarbeitung seiner Metriken oder Traces benötigt, kann es seine eigene Instanz von OTEL Collector in seinem Namespace bereitstellen, vorausgesetzt, es verfügt über eine operative Genehmigung und das Produktionswartungsmodell ist klar.

Teststrategie, Verträge und lokale Entwicklungserfahrung

Das Testen einer verteilten Microservices-Architektur erfordert eine ausgefeiltere Teststrategie als das Testen eines monolithischen Systems. Unit-Tests bleiben unerlässlich, aber Vertragstests (für APIs und Ereignisse), Integrationstests zwischen Diensten und End-to-End-Tests, die vollständige Abläufe abdecken, gewinnen zunehmend an Bedeutung.

Um Kompatibilitätsprobleme zu vermeiden, werden Techniken wie verbraucherorientierte Vertragstests eingesetzt . Dabei definieren Kunden die API-Erwartungen, und Dienstanbieter erfüllen diese. Jede Vertragsänderung wird innerhalb der CI-Pipelines automatisiert getestet, um Deployments zu verhindern, die bekannte Kunden beeinträchtigen.

Sobald die Anzahl der Dienste einhundert übersteigt, wird die lokale Replikation des gesamten Systems unpraktisch. Daher basiert die Entwicklung auf Simulationen abhängiger Dienste oder der Anbindung an entfernte Umgebungen . Entwickler starten typischerweise nur eine Teilmenge der Microservices und ersetzen die übrigen durch Mocks, Fakes oder Simulatoren oder leiten bestimmte Aufrufe an eine gemeinsame Integrationsumgebung um.

End-to-End-Tests setzen zunehmend auf temporäre Umgebungen oder „Vorschauen“, die aus Feature-Branches erstellt werden . Diese schaffen eine isolierte Umgebung mit den für die jeweilige Funktionalität relevanten Diensten. Dadurch werden Reibungsverluste zwischen den Teams minimiert, der „Es funktioniert auf meinem Rechner“-Effekt reduziert und Integrationsprobleme erkannt, bevor sie teurere Umgebungen wie die Vorproduktion erreichen.

Microservices-Bereitstellungsmuster in der Produktion

Neben Kubernetes gibt es verschiedene Microservices-Bereitstellungsmuster für den Produktiveinsatz, die aufgrund ihrer unterschiedlichen Anforderungen an Isolation, Kosten und Reifegrad von Bedeutung sind . Eines der ältesten Muster ist die Ausführung mehrerer Serviceinstanzen pro Host, wobei ein einzelner physischer oder virtueller Host mehrere Instanzen verschiedener Dienste ausführt, typischerweise auf einem gemeinsam genutzten Anwendungsserver.

Beim Muster „Serviceinstanz pro VM“ wird jeder Service als VM-Image (z. B. EC2 AMI) verpackt und auf einer eigenen Instanz ausgeführt. Dies bietet eine starke Isolation, führt aber zu höherem Ressourcenverbrauch und längeren Startzeiten. Tools wie Packer oder Cloud-Anbieter-spezifische Lösungen erleichtern die Erstellung produktionsreifer VM-Images.

Das heute am weitesten verbreitete Muster ist die Serviceinstanz pro Container , wobei jeder Microservice als Container-Image erstellt und auf einem Orchestrator (Kubernetes, OpenShift usw.) bereitgestellt wird. Container sind ressourcenschonender als VMs, starten sehr schnell und ermöglichen es, alle für den Service benötigten Komponenten zu bündeln. Dies vereinfacht die Bereitstellung und ermöglicht die automatische Skalierung.

Schließlich erfreuen sich serverlose Ansätze wie AWS Lambda zunehmender Beliebtheit. Diese Pakete stellen Funktionen bereit, die auf HTTP-Anfragen oder Ereignisse anderer Dienste (S3, DynamoDB, Warteschlangen usw.) reagieren, wobei die Nutzer nur für die tatsächlich genutzten Ressourcen bezahlen. Dieses Muster eignet sich besonders gut für sehr kleine Microservices oder kurzlebige, ereignisgesteuerte Aufgaben, bringt jedoch zusätzliche Überlegungen hinsichtlich Beobachtbarkeit, Kaltstarts und Ausführungsgrenzen mit sich.

In der Praxis entsteht bei vielen Organisationen ein hybrides Ökosystem: Der Kern des Systems läuft auf Containern und Orchestratoren, während bestimmte Hilfskomponenten als serverlose Funktionen oder als spezialisierte VMs implementiert werden, stets mit klaren Schnittstellen und wohldefinierten Protokollen, um sie in das Ganze zu integrieren.

Bei der Umsetzung all dieser Konzepte in die Produktion kommt es nicht nur auf die gewählte Technologie an, sondern vor allem auf eine Architektur, die Fehler toleriert, bedarfsgerecht skaliert, automatisch bereitstellt und transparent ist . Mit produktorientierten Teams, gut verwalteten Verträgen, dezentralen Daten und einer robusten Cloud-Plattform werden Microservices von einem vielversprechenden Ansatz zu einer effektiven und nachhaltigen Methode, komplexe Anwendungen über Jahre hinweg weiterzuentwickeln.