Microservices – Nutzen und Kosten
| Nutzen | Kosten |
|---|---|
|
|
|
|
|
|
|
|
|
Modularität
Microservices fördern üblicherweise die Modularität von Anwendungen, da ungenügende Modularität schnell zu sehr viel höheren Aufwänden und Risiken führt. Kleine, überschaubare Moduleinheiten lassen sich viel einfacher ändern da die Konsequenzen überschaubarer bleiben.
Ein weiterer Vorteil von Microservices sind das dezentrale Datenmanagement, bei dem jeder Service seine eigene Datenbank verwaltet und ggf. die API anderer Services durchläuft.
Verteilte Systeme
Microservices sind verteilte Systeme, wodurch die Komplexität deutlich erhöht wird.
Zunächst wirkt sich dies auf die Performance aus, da Remote-Calls deutlich langsamer sind. Wenn jeder Service jedoch viele andere Services befragen muss wird die Latenz schnell unerträglich. Dem kann zwar dadurch begegnet werden, dass die Anfragen asynchron und feingranularer gestellt werden sowie die Antworten ggf. zwischengespeichert werden.Dies verkompliziert jedoch den Programmcode erheblich.
Fehlertoleranz
Die Komplexität wird noch weiter erhöht, da Ihr Euch nicht auf eine gültige Antwort in einer bestimmten Zeit verlassen könnt. So solltet Ihr schon beim Design Eures Services darauf achten, dass dieser fehlertolerant ist. Wie das geschehen kann, ist z.B. in Principles of chaos engineering oder in Fault Tolerance in a High Volume, Distributed System. So entwickelte z.B. Netflix Chaos Monkey, der zufällig Prozesse von Instanzen und Containern beendet, um sowohl die Ausfallsicherheit als auch die Zuverlässigkeit der Gesamtanwendung zu testen. Wenn Services aber jederzeit ausfallen können, wird es umso wichtiger, den Fehler schnell zu erkennen und den Service möglichst automatisiert wieder bereitstellen zu können. Daher wird die Echtzeitüberwachung der betriebs- und geschäftsrelevanten Metriken immer wichtiger.
Dies sind nur einige der Probleme von verteilten Systemen; weitere findet Ihr in Fallacies of Distributed Computing Explained).
Unabhängiges Deployment
Ein Schlüsselprinzip von Microservices ist, dass Services Komponenten sind und daher unabhängig voneinander bereitgestellt werden können. Dies hat den Vorteil, dass Ihr bei Änderungen an einem Service nur diesen Testen und neu bereitstellen müsst. Zudem sollte selbst ein vollständiger Ausfall dieser einen Komponente nicht zum Ausfall anderer Teile des Systems führen sondern nur zu einem geringeren Funktionsumfang führen. Dieser Vorteil kommt jedoch erst richtig mit Continuous Delivery zum Tragen.
Eventual consistency
Ihr kennt sicher alle das Problem, dass Ihr ein Update durchgeführt habt und dennoch könnt Ihr die Änderungen nicht sofort sehen. Dies kann einfach damit zusammenhängen, dass gerade der eine Knoten aktualisiert wird während Eure Anfrage von einen noch nicht aktualiserten Knoten beantwortet wird. Solche Inkonsistenzen können auch zu schwerwiegenderen Problemen führen. Und auch wenn bei Monolithen leichter Transaktionssicherheit hergestellt werden kann, so sind sie keineswegs frei davon, z.B. wenn die Cache-Invalidation nicht zuverlässig ist.
Technologische Vielfalt
Da jeder Microservice eine unabhängige Einheit ist, habt Ihr auch erhebliche Freiheit bei der Auswahl Eurer Technologie. Microservices können in verschiedenen Sprachen geschrieben werden, verschiedene Bibliotheken und Datenspeicher verwenden. Auf diese Weise können Teams ein geeignetes Tool für den Job auswählen. Ihr könnt also profitieren davon, dass sich manche Sprachen und Bibliotheken besser für bestimmte Arten von Problemen eignen.
Dies ist jedoch nicht der einzige Vorteil der technischen Vielfalt von Microservices. Auch die Verwendung unterschiedlicher Versionen einer Bibliothek kann Upgrades deutlich vereinfachen. Bei einem Monolithen könnte ein Teil des Systems eine neue Funktion einer Sprache oder Bibliothek nutzen wollen, das Upgrade kann jedohch nicht verwendet werden, wenn dadurch ein anderer Teil des Monolithen kaputt geht.
Umgekehrt besteht jedoch die Gefahr, dass die technologische Vielfalt zu viel wird, sodass das Team überfordert werden kann. Die meisten mir bekannten Organisationen lassen nur eine begrenzte Anzahl von Technologien zu. Dies erleichtert dann z.B. auch die Überwachung der vielfältigen Tools da sich die Anzahl der Environments reduziert.
Operationale Komplexität
Die Möglichkeit, kleine unabhängige Module schnell bereitzustellen, ist ein großer Vortiel für die Entwicklung, stellt jedoch gleichzeitig eine zusätzliche Belastung für den Betrieb dar, da aus einem halben Dutzend Anwendungen jetzt Hunderte kleiner Mikrodienste werden können. Viele Organisationen werden die Schwierigkeit, mit einem solchen Schwarm sich schnell ändernder Tools umzugehen, als unmöglich empfinden. Tatsächlich wird dies auch nur mit Continuous Delivery möglich sein. Die Komplexität verlagert sich also von den einfacher werdenden Microservices zum gemeinsamen Betrieb dieser zunehmenden Anzahl dieser Services.
Einfachere Skalierbarkeit
Es liegt auf der Hand, dass Microservices besser den Service skalieren können, der unter erhöhter Last steht. Dies ist jedoch noch nicht alles: bei Microservices könnt Ihr auch schneller und präziser erkennen, welcher Teil unter Last steht.
Bessere Trennungskontrolle
Mit Microservices können Sie vertrauliche Daten trennen und diesen Daten mehr Sicherheit verleihen. Durch die kontrolliertere Steuerung des gesamten Datenverkehrs zwischen Microservices dürfte dies das Risiko, bei einem Einbruch umfassend Zugriff auf alle Daten zu erhalten, deutlich erschweren. Mit der zunehmenden Bedeutung von Sicherheitsproblemen ist dies eine wichtige Überlegung bei der Verwendung von Microservices.
Resümee
In diesem Artikel werden nur allgemein die Kosten und Nutzen von Microservices dargelegt. Er kann nicht die Entscheidung für ein konkretes Projekt vorwegnehmen, sondern nur dazu beitragen, dass Ihr die verschiedenen Faktoren berücksichtigt. Jeder Kosten- und Nutzenfaktor hat für verschiedene Systeme ein unterschiedliches Gewicht. Beurteilt, welche Faktoren für Euer System am wichtigsten sind und wie sie sich auf Euren speziellen Kontext auswirken. Erschwerend kommt hinzu, dass Architekturentscheidungen normalerweise erst sinnvoll beurteilt werden können, nachdem ein System ausgereift ist.