Nachdem ich in 3 Teilen die Welt von Cloud-Computing und dessen Inhaltsbegriffen oberflächlich beleuchtet habe, steige ich heute hinab in den Bereich derer Begriffe die oft aus dem Zusammenhang gerissen werden wenn über Wolken diskutiert wird.
Heute:
Microservices
Die Basis für diese “kleinen” Dienste ist der Gedanke, alles möglichst einfach aber gut zu machen. Daher sind folgende Eigenschaften für Microservices prägend:
- Die Services können einfach ersetzt werden.
- Der Umfang eines Microservices sollte für jedes Teammitglied überschaubar sein.
- Ein Microservice sollte vom zuständigen Team (üblicherweise 5 bis 7 Entwickler) mit vertretbarem Zeitaufwand (z. B. innerhalb eines Monats) neu erstellt und ersetzt werden können.
- Die Dienste haben eine Geschäftsfunktion.
- Jeder Microservice kann eine andere Programmiersprache, Datenbank oder einen ganz anderen Technologie-Stack nutzen.
- Jeder Microservice kann unabhängig von anderen Microservices in Produktion gebracht werden. Das erleichtert den Einstieg in Continuous Delivery. Ein Microservice wird nur von einem Team entwickelt.
- Ein Microservice sollte einen Bounded Context im Sinne von Domain-driven Design implementieren.
Die Größe eines Microservices wird hierbei dadurch nach unten begrenzt, dass die Netzwerkkommunikation zwischen Microservices ressourcenintensiv ausfallen kann und für jeden Microservice ein eigenes Deployment vorgesehen werden muss.
Abgrenzung zu SOA
SOA (Serviceorientierte Architektur) und Microservices nutzen beide Dienste als Architektur-Elemente. SOA nutzt Dienste, um verschiedene Anwendungen zu integrieren. Die Kombination der Dienste erfolgt durch Orchestrierung, und Portale können ein gemeinsames UserInterface (UI) für alle Dienste bieten. Microservices strukturieren eine Anwendung durch Dienste. Jeder Microservice kann eine UI enthalten und Geschäftsprozesse implementieren, wie sie bei SOA in der Orchestrierung zu finden sind.
Vorteile
Der Sinn hinter den Microservices liegt darin begründet verteilt entwickeln zu können. Mehrere Teams können unabhängig voneinander arbeiten und doch bündelt sich das Gesamtwerk zu einem agilen Entwicklungsprozess. Die Kommunikation und Koordination mit oder ohne Werkzeuge (Collaboration-Plattformen) ist hierbei nicht zu unterschätzen. Innerhalb eines Teams ist der Aufwand dafür hingegen klein.
- Microservices sind klein. Dadurch bleiben sie übersichtlich und leicht weiterentwickelbar. Im Notfall können sie auch durch eine Neuimplementierung ersetzt werden.
- Continuous Delivery ist aufgrund der Größe der Microservices einfacher.
- Jeder Microservice kann mit einer anderen Technologie implementiert werden. Das vereinfacht Experimente mit neuen Technologien und verhindert das Veralten des Technologie-Stacks.
- Microservices können auch dazu genutzt werden, um Legacy-Systeme zu erweitern, ohne dabei zu viele Änderungen an der alten Code-Basis vornehmen zu müssen.
- Oft schleichen sich bei Systemen ungewollte Abhängigkeiten ein und irgendwann geht die ursprüngliche Architektur vollständig verloren. Die Architektur des Microservices-Systems bleibt stabil, weil Abhängigkeiten zwischen Microservices über eine API (Programmierschnittstelle ) eingeführt werden müssen. Das ist aufwändig und passiert nicht aus Versehen.
- Weil die Microservices wartbar bleiben und auch die Architektur des Gesamtsystems erhalten bleibt, erlauben Microservices auch langfristig eine produktive Entwicklung des Systems.
- Microservices können unabhängig voneinander skaliert werden.
- Microservice-Systeme sollten gegen den Ausfall einzelner Microservices abgesichert sein, so dass das Gesamtsystem robust ist.
Nachteile
Diese gibt es trotzt der erheblichen Vorteile durchaus:
- Die komplexen Abhängigkeiten verschwinden nicht, sondern existieren auf der Netzwerk-Ebene weiter.
- Der Aufwand für die Migration bestehender Systeme ist beträchtlich und bedeutet in der Regel auch eine Anpassung der Kommunikationskultur in den beteiligten Organisationen.
- Die verteilte Architektur erzeugt zusätzliche Komplexität, vor allem Netzwerk-Latenzen, Lastverteilung oder Fehlertoleranz.
- Die Vielzahl an Services macht die Softwareverteilung und das Testen komplexer.
Quellenhinweise: