© Excellent backgrounds/Shutterstock.com
Erfahrungsbericht: Deployment und Monitoring von Microservices

Einfach mal loslegen


Beim Deployment von Microservices verschwimmen die Grenzen zwischen Mikro- und Makroarchitektur [1]. Während das Team die Mikroarchitektur für jeden Service individuell entscheiden kann, muss man sich bei Makroarchitekturthemen mit anderen Teams zusammensetzen. Es ist deswegen wichtig zu wissen, welche Entscheidungen ein Team für sich treffen kann und welche nicht. Ein Erfahrungsbericht zeigt, wie der Weg mit Learning by Doing funktionieren kann.

Bei einem Kundenprojekt bot es sich an, die Anforderungen mit drei Microservices umzusetzen, die jeweils über ein kleines REST-API verfügten. Nachdem wir verschiedene Microservices-Frameworks ausprobiert hatten, entschieden wir uns letztlich für Spring Boot. Durch seine Opinionated Presets bietet dieses Framework eine konstant hohe Entwicklungsgeschwindigkeit. Schließlich bekamen wir von unseren Kollegen im Operations-Team die Nachricht, dass sie für unsere Services eine Continuous-Delivery-Pipeline einrichten wollen. Dazu müssten wir uns aber entscheiden, wie denn die Services deployt werden sollen.

Da wir bereits zwei unserer drei so genannten Innovation Tokens [2] für den Microservices-Ansatz und Spring Boot verbraucht hatten, haben wir die Vor- und Nachteile eines Docker-basierten Deployments nicht evaluiert. Bei der Idee hinter Innovation Tokens geht es darum, dass man nicht zu viele Innovationen auf einmal einführt. Einerseits ist bei neuen Technologien nicht sicher, wie stabil sie bereits sind bzw. unter welchen Szenarien sie sich nicht wie spezifizierte verhalten und man zusätzliche Zeit in ihre Stabilisierung investieren muss. Andererseits bringen sie immer Unbekannte mit sich, weil das Team noch keine Erfahrung mit ihnen gesammelt hat und hierfür Zeit aufbringen muss. Die Theorie besagt, wenn man zu viele Innovationen auf einmal einführt, überfordert dies die Menschen im Projekt, weil man die Anzahl der beweglichen und unbekannten Teile so weit erhöht, dass sie den Überblick verlieren. Durch diese Überforderung kommt Unzufriedenheit und zusätzliche Instabilität ins Projekt, was die Produktivität senkt. Stattdessen limitiert man die Anzahl der mit einem Projekt einführbaren Innovationen auf ein Maß, das das Team tragen kann.

Deshalb entschieden wir uns, als Deployment-Artefakt durch das Maven-Plug-in von Spring Boot ein self executable JAR erstellen zu lassen. Für dessen Aufruf schrieben wir dann ein Shellskript, das wir auf den Linux-VMs, die als Zielsysteme geplant waren, zum Starten und Stoppen unse...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang