Unser Hauptprodukt — ein Informationssystem für mittelständische Unternehmen — ist ein klassischer Monolith. Ein WAR, ein GlassFish, eine Oracle-Datenbank. Es funktioniert, die Kunden sind zufrieden. Warum also anfassen? Weil jedes neue Feature länger dauert, das Deployment einer einzelnen Änderung die Freigabe der gesamten Anwendung erfordert und das Team gewachsen ist. Microservices sehen nach dem Ausweg aus.
Warum nicht „alles neu schreiben”¶
Unser erster Impuls war, den Monolith wegzuwerfen. Glücklicherweise verwies uns ein Kollege auf Martin Fowlers Artikel über das Strangler Pattern — Teile des Monolithen schrittweise durch neue Services ersetzen. Evolution, nicht Revolution.
Wir haben Bounded Contexts definiert (DDD-Terminologie): Rechnungsstellung, Benutzerverwaltung, Benachrichtigungen, Reporting. Wir begannen mit Benachrichtigungen — das geringste Risiko, ein klarer Umfang.
Notification Service — Unser erster Microservice¶
Der neue Notification Service: eine eigenständige Spring-Boot-Anwendung (ja, wir haben Java EE für Microservices verlassen). REST-API, Templates in der Datenbank, asynchrone Zustellung über eine Queue. Stack: Spring Boot 1.2, Embedded Tomcat, PostgreSQL, RabbitMQ. Der gesamte Service umfasst ca. 3.000 Zeilen Code und wird unabhängig deployed.
REST-API — Der Vertrag ist Gesetz¶
Wir definieren APIs in Swagger. Spezifikationen leben in Git, Änderungen durchlaufen ein Review. Client-Code wird aus Swagger generiert. Versionierung: /api/v1/notifications. REST für synchrone Operationen, RabbitMQ für asynchrone Events.
Deployment — Docker in der Produktion (fast)¶
Docker 1.5 ist stabiler. Docker Compose für die lokale Entwicklung. Orchestrierung? Noch nicht. Ich habe von Kubernetes bei Google gehört — es sieht interessant aus, aber für 3 Services ist es überdimensioniert. Ein Server = ein Service, nginx als Load Balancer. Primitiv, aber funktional.
Was wir unterschätzt haben¶
Verteiltes Logging. Mit fünf Services braucht man zentralisiertes Logging. ELK Stack + Correlation IDs — es dauerte zwei Sprints.
Netzwerkausfälle. Ein HTTP-Aufruf über das Netzwerk ist nicht zuverlässig. Circuit Breaker (Hystrix von Netflix) ist eine Notwendigkeit. Unser erster Produktionsvorfall war ein kaskadierender Timeout über das gesamte System.
Testing. Unit-Tests sind unkompliziert. Integrationstests über Services hinweg sind ein Albtraum. Contract Testing (Pact) hilft, aber End-to-End-Tests über 4 Services sind fragil.
Lohnt es sich?¶
Nach einem Jahr: 4 Microservices und ein verkleinerter Monolith. Das Deployment des Notification Service dauert 2 Minuten. Wir liefern neue Features 3× schneller. Aber der Overhead ist real — mehr Infrastruktur, Monitoring und Komplexität. Für ein Team mit weniger als 5 Entwicklern würde ich Microservices nicht empfehlen.
Evolution, nicht Revolution¶
Microservices sind kein Allheilmittel. Sie tauschen Komplexität innerhalb der Anwendung gegen Komplexität zwischen Anwendungen. Aber wenn der Monolith Sie bremst, ist schrittweise Dekomposition sinnvoll. Beginnen Sie mit einem kleinen, peripheren Service.
Brauchen Sie Hilfe bei der Implementierung?
Unsere Experten helfen Ihnen bei Design, Implementierung und Betrieb. Von der Architektur bis zur Produktion.
Kontaktieren Sie uns