Foto: vintek2303 - shutterstock.com
Microservices sind aus der serviceorientierten IT-Architektur (SOA) entstanden, mit dem Ziel, bessere Anwendungen zu entwickeln. Es gibt einige gute Gründe dafür, warum der Ansatz immer noch sehr beliebt ist, um neue Applikationen zu programmieren. Microservices:
funktionieren, ohne direkt von den internen Implementierungsdetails anderer Services abhängig zu sein.
ermöglichen es, Dienste eigenständig zu entwickeln, bereitzustellen und zu skalieren, was die Agilität fördert.
bieten eine erhöhte Ausfallsicherheit, weil sie unabhängig laufen.
5 Microservices-Schattenseiten
Doch auch in der Softwareentwicklung gibt es nichts zum Nulltarif: Jeder Ansatz, jedes Tool, jede Programmiersprache und jede Architektur bringt ihre jeweiligen Vor- und Nachteile mit, die es vorab zu berücksichtigen gilt. Das geht manchmal allerdings im Hype unter. Folgende Nachteile bringen Microservices-Architekturen mit sich:
Komplexität: Microservices werfen im Vergleich zu monolithischen Architekturen ein höheres Maß an Komplexität auf. Systeme werden in zahlreiche Services aufgeteilt, was die Architektur verkompliziert und es zur Herausforderung macht, die Abhängigkeiten und Interaktionen zwischen den Diensten zu verstehen. Dass die Plattformen, auf denen Microservices bereitgestellt werden, komplexe, verteilte Systeme darstellen (ein Nebenprodukt des Multi-Cloud-Trends), macht die Sache nicht besser.
Verteilung: Bei Microservices erfolgt die Kommunikation zwischen den Diensten häufig über ein Netzwerk, was zu Latenzen, Netzwerkausfällen und erhöhtem Stress führen kann. Das Gegenmittel: ein (kostenintensives) Netzwerk-Upgrade.
Datenmanagement: Microservices können über eigene Datenbanken oder Data Stores verfügen, was eine serviceübergreifende Datenkonsistenz erschwert. Die Datenintegrität aufrechtzuerhalten, ist in der Regel mit zusätzlichem Aufwand verbunden. Das zeigt sich jedoch erst, wenn es zu Problemen kommt - und erfordert dann meist wesentlich mehr Ressourcen als gedacht.
Abhängigkeiten: Weil Microservices über APIs interagieren, können sich Änderungen an einem Service auf alle andere auswirken. Das führt zu neuen Herausforderungen bei der Versionierung und potenziell zu Kompatibilitätsproblemen, insbesondere wenn es um Upgrades oder Serviceänderungen geht.
Ressourcen-Overhead: Mehrere Microservice-Instanzen zu betreiben, verbraucht im Regelfall mehr Ressourcen als eine monolithische App. Wenn sie nicht effizient gemanagt werden (was die Regel ist), kann das die Infrastrukturkosten in die Höhe treiben.
Cloud-Entwickler und -Architekten haben die Microservices-Architektur mit nahezu religiöser Inbrunst verinnerlicht. Allerdings können die auch wesentlich mehr Ressourcen brauchen als sie sollten - insbesondere wenn es um Applikationen geht, die in die Cloud verlagert wurden oder dorthin verlagert werden sollen. Microservices sollten - wie jeder andere Ansatz auch - immer im jeweiligen Kontext betrachtet werden. Dabei sollte der Zweck der Architektur im Fokus stehen, um einen sinnvollen Einsatz zu gewährleisten. (fm)
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.