Datacenter
Der kalkulierte Kontrollverlust
Viele Entscheider stellen sich die Frage, wie unterscheiden sich DevOps und Microservices von klassischen IT-Vorgehensmodellen, und welche Implikationen haben deren Einführung auf bestehende Unternehmensstrukturen?
Eine allgemein gültige Definition des Begriffes “Microservices” hat sich bislang noch nicht durchgesetzt. Folgende Kriterien können aber für eine Eingrenzung verwendet werden: Microservices dienen der Modularisierung von Software, also dem Aufteilen von monolithischen Systemen in kleine, voneinander unabhängige Bestandteile, die untereinander kommunizieren. Für die zugrundeliegende Technologie, die für die Implementierung von Microservices genutzt wird, existiert keine Einschränkung.
Fachlichkeit als Kriterium
Microservices sind fachlich abgeschlossene Bestandteile einer komplexeren Anwendung. Jeder Service besitzt die Hoheit über die Daten der implementierten fachlichen Domäne, ein Zugriff auf eine Datenquelle von mehr als einem Service ist unter allen Umständen zu vermeiden. Ziel der Definition von Fachdomänen ist die Steigerung der Produktivität von Softwareprojekten mit komplexer Fachlichkeit. In der Praxis kann diese Trennung über unterschiedliche Datenbanken oder Schemata innerhalb einer Datenbank implementiert werden. Die einzelnen Services werden unabhängig voneinander in den produktiven Betrieb überführt, die Änderung eines Service sollte keine Auswirkungen auf die Funktion anderer haben. Diese Eigenschaften implizieren, dass Microservices über das Netzwerk Daten austauschen, also eine lose Kopplung unterstützen müssen. In den meisten Fällen wird die Kommunikation der Services untereinander über HTTP mit Hilfe von „REST“ (Representational State Transfer) oder Nachrichten-Warteschlangen abgebildet.
Natürlich gab es auch schon vor Microservices Versuche, Anwendungen in einzelne Bestandteile zu unterteilen. Klassische Enterprise-Anwendungen besitzen meist eine interne Modularisierung, werden aber dennoch als monolithischer Block ausgerollt. Jede Änderung in einem der Teilmodule hatte zur Folge, dass die komplette Anwendung neu ausgerollt werden musste. Die Vorbereitungen für solche Deployments waren meist sehr zeitintensiv: Die einzelnen Entwicklungsteams mussten sich untereinander abstimmen, es gab sogenannte „Code-Freeze”-Zeiten, in denen keine Änderung des Codes mehr möglich war. Aufgrund der Vielzahl der Änderungen mussten umfangreiche Regressionstests durchgeführt werden, um sicherzustellen, dass Modifikationen in bereits getesteten Teilen keine neuen Fehler verursachen.
Durch die Modularisierung von Monolithen in Microservices können Teams deutlich autonomer arbeiten, was den Entwicklungsprozess agiler gestaltet. Wichtig für die Kommunikation der Services untereinander sind explizite Schnittstellen, was ungewünschte Abhängigkeiten größtenteils vermeidet. Das hat zusätzlich den Vorteil, dass einzelne Microservices deutlich einfacher durch andere ersetzt werden können. Falls beispielsweise ein Team entdeckt, dass sich eine neue Technologie deutlich besser für die Implementierung einer Funktionalität eignet, kann der bestehende Service abgelöst werden, indem der neue Service die bestehende Schnittstelle implementiert.
- Der kalkulierte Kontrollverlust
- Vorteile von Microservices
- Auswirkungen auf die Organisationsstruktur
- Kommentar AWS: Mut zur Veränderung
Lesen Sie mehr zum Thema
