Zusammenfassung
Wenn man in ein neues Projekt einsteigt, ist es nicht ungewöhnlich, eine Infrastruktur zu übernehmen, die „einfach funktioniert“ – bis sie es eben nicht mehr tut.
In einem meiner letzten Beratungsprojekte übernahm unser Team die AWS-Umgebung eines Kunden, die auf einem weit verbreiteten Microservices-Muster basierte.
Das ursprüngliche Setup wirkte zunächst sinnvoll, aber schnell wurde klar:
Eine Modernisierung war nicht nur empfehlenswert – sie war absolut notwendig.

Eine vertraute Architektur mit versteckten Einschränkungen
Im Zentrum der Plattform befand sich ein typischer AWS-Stack: Anfragen aus dem Internet trafen auf ein Amazon API Gateway, das den Datenverkehr über einen VPC Link an einen privaten Network Load Balancer (NLB) weiterleitete. Von dort leitete der NLB die Daten an ein ECS-Cluster weiter, das auf Fargate lief und auf dem mehrere Microservices bereitgestellt waren. Das System nutzte außerdem Amazon RDS für relationale Daten, Amazon S3 zur Objektspeicherung und AWS Lambda-Funktionen, die über SQS-Warteschlangen für asynchrone Aufgaben ausgelöst wurden.
Obwohl diese Architektur etablierten Mustern folgte, wies sie eine erhebliche architektonische Einschränkung auf: Alle fünf Microservices wurden gemeinsam in einer einzigen ECS-Task-Definition bereitgestellt. Jedes Mal, wenn ein Entwickler eine Änderung an nur einem Dienst vornahm – sei es ein Bugfix, ein neues Feature oder eine Konfigurationsanpassung – musste die gesamte Gruppe von Diensten neu bereitgestellt werden.
Dieses Setup untergrub viele der Versprechen der Microservices-Architektur. Es verhinderte unabhängige Deployments, verzögerte Release-Zyklen und erhöhte das Risiko von Produktionsproblemen durch unnötige Neuveröffentlichungen. Außerdem bedeutete es, dass Dienste, die eigentlich unabhängig skalieren sollten, in ihrem Lebenszyklus eng gekoppelt waren.
Entkopplung der Architektur
Mein erster Schritt bestand darin, dieses Monolith-durch-Deployment zu entwirren. Ich teilte die einzelne Task-Definition in fünf unabhängige ECS-Services auf, jeweils mit eigener Task-Definition, Zielgruppe, Skalierungskonfiguration und Deployment-Pipeline. Dies brachte sofortige Vorteile: schnellere Deployments, feinere Rollback-Möglichkeiten und echte Isolierung auf Service-Ebene.
Die verbesserte Architektur erhöhte auch die Resilienz. Dienste konnten nun je nach Bedarf unabhängig skalieren, und Infrastrukturprobleme konnten behoben werden, ohne nicht betroffene Teile des Systems in Mitleidenschaft zu ziehen.
Eine neue Herausforderung: monolithische Pipelines
Nachdem die Infrastruktur entkoppelt war, richtete sich die Aufmerksamkeit auf den Entwicklungslebenszyklus. Trotz der verbesserten Laufzeittrennung behandelte der CI/CD-Prozess den Code weiterhin als Monolith. Alle fünf Dienste befanden sich in einem einzigen Repository, und jede Änderung löste eine Pipeline aus, die alle Container-Images erstellte, taggte und in Amazon ECR übertrug – unabhängig davon, welcher Dienst tatsächlich geändert worden war.
Das war ineffizient und teuer – sowohl hinsichtlich der Rechenressourcen als auch der Entwicklerzeit.
GitOps für skalierbare Bereitstellung implementieren
Um das zu lösen, führte ich einen GitOps-ähnlichen Ansatz ein. Jeder Microservice erhielt innerhalb des Repositories eine eigene logische Abgrenzung. Die CI/CD-Pipeline wurde neu gestaltet, um Änderungen zu erkennen bei …
Möchten Sie mehr erfahren?
Wenn Sie mit einem veralteten ECS-System arbeiten, unter Deployment-Engpässen leiden oder daran interessiert sind, GitOps-Prinzipien in Ihrer Cloud-Umgebung umzusetzen – ich teile gerne mehr dazu. Die richtigen architektonischen Verbesserungen erfordern nicht immer einen kompletten Neuanfang. Manchmal braucht es nur den richtigen Plan.