Monolith? Das war gestern. Microservices rocken heute!

Umbau auf Microservices-Architektur

Ausgangslage und Zusammenfassung

Die Webseite eines unseres Kunden basiert auf dem Content-Management-System TYPO3 und war  im Rahmen eines Shared Hostings betrieben. Im Laufe der Jahre hat sich das System durch zahlreiche Erweiterungen sowie die Integration der Solr-Suchtechnologie stark weiterentwickelt und dabei eine hohe technische Komplexität erreicht. Zusätzlich war die Implementierung eines neuen Funktionsbereichs geplant, der die bestehende Architektur weiter belasten und die Wartbarkeit sowie Skalierbarkeit des Systems erheblich erschweren würde.

Vor diesem Hintergrund ist die aktuelle monolithische Systemarchitektur zunehmend an ihre Grenzen gestoßen und stellte ein Risiko für künftige Weiterentwicklungen dar. Daher war ein grundlegender technischer Umbau durch die Ablösung der bestehenden Architektur zugunsten eines modernen, flexiblen und skalierbaren Architekturansatzes, wie z. B. einer Microservice-Architektur erforderlich.  Trotz der Herausforderungen erwies sich der Umbau als Erfolg und führte zu spürbar positiven Ergebnissen in der Zusammenarbeit innerhalb der Teams.

In Absprache mit dem Team und mit dem Kunden wurde für die Durchführung des Projektes ein hybrides Projektmanagement-Modell ausgewählt.  Die agile Umsetzung in Kombination mit klassischer Steuerung ermöglichte die notwendige Flexibilität, aber auch gleichzeitig die nötige Struktur. Aufgrund der Komplexität und der Unsicherheiten in der Anfangsphase wurde das Projekt in zwei Phasen aufgeteilt: Vorprojekt und Hauptprojekt.

Die genaue Vorgehensweise siehst du bei Klick auf "Mehr erfahren". Weiter unten befinden sich die wichtigsten Eckpunkte des Projekts. 

Problemdefinition

  • Die Monolith-Architektur führte zunehmend zu Problemen: Änderungen in einem Bereich hatten unerwünschte Auswirkungen auf andere Teile, wodurch Wartung und Weiterentwicklung aufwendig und fehleranfällig wurden.
  • Die Skalierung war nur mit hohem Kostenaufwand möglich und automatisierte Tests waren kaum umsetzbar. Entwickler gerieten regelmäßig in Konflikte aufgrund enger Code-Abhängigkeiten, und Erweiterungen verursachten erheblichen Aufwand.
  • Zudem war nur ein vollständiges Deployment möglich, und moderne Technologien ließen sich kaum integrieren.

Projektziele

  • Verbesserte Wartbarkeit: Änderungen und Erweiterungen sollen gezielt und mit geringerem Risiko möglich sein. 
  • Erhöhung der Skalierbarkeit: Services sollen unabhängig voneinander skaliert werden können.
  • Modernisierung der Systemarchitektur: Ermöglichung des Einsatzes neuer Technologien, Frameworks und Tools.
  • Flexibles Deployment: Einzelne Services sollen unabhängig deploybar sein (Continuous Deployment). 
  • Schnellere Time-to-Market: Neue Funktionen oder Produkte können schneller ausgeliefert werden.
  • Die Laufzeit für das Projekt: 15.4.23-15.8.23

Meine Rolle als PO

  • Initiierung beim Kunden und Durchführung von Workshops
  • Erarbeitung einer klaren Produktvision und Formulierung messbarer Ziele
  • Aufbau eines Product Backlogs mit fachlichen und technischen Anforderungen als User Storys und Tasks.
  • Koordination des gesamten Projektablaufs, einschließlich Kick-off, Planung, aktiver Begleitung der Umsetzung sowie regelmäßiger Abstimmung mit dem Kunden. 
  • Das frühzeitige Erkennen und Abfedern von Risiken.
  • Das Lösen von Anforderungskonflikten usw. 

Organisatorische 
Herausforderungen

  • Der Wechsel erforderte eine neue Denkweise: weg von zentralen, einheitlichen Systemen hin zu dezentraler Verantwortung. 
  • Klassische Abteilungsgrenzen (z. B. Frontend-, Backend-, Datenbankteams) haben zu der neuen Microservices-Logik nicht gepasst. 
  • Mehr Abstimmung zwischen Entwicklung war in der Umstellungsphase notwendig.

Technische 
Herausforderungen

  • Datenbank-Zerschneidung und Datenkonsistenz: Datenkonsistenz über Services hinweg ist schwieriger sicherzustellen. 
  • Kommunikation zwischen Services: Microservices müssen nach der Umstellung miteinander kommunizieren.
  • Deployment Komplexität: Statt einer Anwendung gibt es plötzlich viele mit eigenem Build, Test, Deployment.
  • Verteiltes Logging und Monitoring: Logs, Fehler, Metriken und Traces sind über mehrere Services verteilt. Zentrale Sicht auf Systemzustand fehlt. 

Methoden & 
Tools

  • Methoden: Angebot, Projektauftrag, Projektstrukturplan (PSP), Zeitplan, Scrum Teams, Agile Sprints, Retrospektiven, Sprint Review, Release Plannung, Workshops und Domain Driven Design, Wireframes, Prototypen, Use Cases, Testfälle, Risikoanalayse-Matrix, Stakeholder-Analyse
  • Tools: Jira, Advanced Roadmaps in Jira, Excel, PowerPoint, Balsamiq, Confluence, White Boards

Ergebnisse und Impact

Die eingeleitete Umstellung auf Microservices bringt nicht nur technische Vorteile, sondern stärkt auch messbar die Entwicklungsgeschwindigkeit und Auslieferungsqualität des Unternehmens. Durch die Entkopplung von drei fachlichen Bereichen, die nun als eigenständige Services aufgesetzt wurden, konnte eine deutlich erhöhte Modularität und Skalierbarkeit erreicht werden. Diese Umstellung ermöglicht es, einzelne Teile der Software unabhängig voneinander zu entwickeln, zu testen und zu deployen, wodurch Fehler schneller identifiziert und behoben werden können und gleichzeitig die Entwicklungszyklen verkürzt werden.

Die erreichten Ziele legen die Grundlage für nachhaltige Weiterentwicklung, stabile Betriebsprozesse und deutlich mehr Flexibilität im Umgang mit zukünftigen Anforderungen. Insbesondere die Möglichkeit, einzelne Services gezielt an neue Bedürfnisse oder Marktveränderungen anzupassen, fördert die langfristige Innovationsfähigkeit des Unternehmens und stellt sicher, dass neue Funktionen schneller und zuverlässiger zur Verfügung stehen.

Technische 
Ergebnisse

Moderne, zukunftsfähige Architektur auf Basis klar definierter Microservices

Klare Trennung fachlicher Domänen mit eigenständiger Codebasis und Datenhaltung

Wartbare Services, die unabhängig voneinander weiterentwickelt werden können

Technologieoffenheit für neue Tools, Frameworks und Infrastrukturkomponenten

Containerisierung und CI/CD etabliert, was schnelle, automatisierte Deployments ermöglicht

Organisatorischer Impact

Parallele Entwicklung in mehreren Teams möglich, ohne gegenseitige Blockade

Kürzere Entwicklungs- und Testzyklen, da einzelne Services gezielt ausgeliefert werden können

Bessere Fehlerisolierung: Fehler in einem Service beeinträchtigen nicht das Gesamtsystem

Effizientere Ressourcennutzung durch gezielte Skalierung einzelner Komponenten

 

Business 
Impact

Time-to-Market verkürzt: Neue Features oder Anpassungen können schneller live gehen

Weniger technische Schulden durch Ablösung veralteter, monolithischer Abhängigkeiten

Besseres Risikomanagement: Updates können ohne „Big Bang“ live geschaltet werden

Höhere Zufriedenheit im Team durch mehr Autonomie und klarere Zuständigkeiten

Langfristige Investitionssicherheit, da das System erweiterbar und skalierbar bleibt

Strategischer 
Impact

Investitionssicherheit und Zukunftsfähigkeit: Die Architektur lässt sich kontinuierlich modernisieren, ohne alles neu zu bauen

Bessere Anschlussfähigkeit an Partner und Plattformen: Durch APIs und lose Kopplung ist die Integration mit Drittsystemen einfacher

Technologieunabhängigkeit: Dienste können unabhängig voneinander modernisiert oder ausgetauscht werden

 

Lessons Learned

Trotz einer zunächst sorgfältigen Planung sind bei der Umstellung auf die Microservices-Architektur mehrere Fehler aufgetreten, die wir im Team im Rahmen einer abschließenden Retrospektive nochmal besprochen und im 'Lessons Learned'-Dokument festgehalten haben.

API-Design 
vernachlässigt

Fehler: APIs wurden inkonsistent gestaltet und nicht ausreichend dokumentiert, was zu Integrationsproblemen führte.
Lesson Learned: API-Verträge nutzen und einheitliche Schnittstellenstandards sind ein Muss.

Fehlende 
Teststrategie

Fehler: Es fehlte an automatisierten Integrationstests zwischen den Services, was die Fehlersuche erschwerte.
Lesson Learned: Eine mehrstufige Teststrategie ( Integration,  E2E) ist essenziell und muss früh etabliert werden.

Unzureichendes 
Monitoring

Fehler: Ausfälle wurden zu spät erkannt oder konnten nicht zugeordnet werden.
Lesson Learned: Zentralisiertes Logging und verteiltes Monitoring sind Grundlage für einen stabilen Betrieb.

Aufwand 
unterschätzt

Fehler: CI/CD, Deployment und Betrieb haben länger gedauert, als geplant und verzögerten die Integration.
Lesson Learned: DevOps muss integraler Bestandteil der Architektur- und Projektplanung von Anfang an sein.

©2025 Evgeniya Vigil Presa. Alle Rechte vorbehalten.    

Wir benötigen Ihre Zustimmung zum Laden der Übersetzungen

Wir nutzen einen Drittanbieter-Service, um den Inhalt der Website zu übersetzen, der möglicherweise Daten über Ihre Aktivitäten sammelt. Bitte überprüfen Sie die Details in der Datenschutzerklärung und akzeptieren Sie den Dienst, um die Übersetzungen zu sehen.