In der Natur ist größer nicht gleich besser. Der weiße Hai mag vielleicht der größte Raubfisch der Meere sein, doch in vielerlei Hinsicht kann ein Schwarm kleiner Fische deutlich besser im Ozean überleben und gedeihen als ein großes Einzeltier. In der Tat zieht sich der Erfolg durch Zusammenarbeit wie ein roter Faden durch die Natur: Ameisenkolonien, Bienenstöcke, Wolfsrudel und viele andere Tiergruppen profitieren davon, in lose gekoppelten Systemen zusammenzuarbeiten, um die Kontrolle zu verteilen und Ziele gemeinsam zu erreichen. Und wenn ein Mitglied der Kolonie, des Stocks oder des Rudels wegfällt, funktioniert der Rest der Gruppe weiterhin und kann den Verlust ausgleichen.
Microservices wenden diesen Ansatz auf Software-Entwicklung und Systemarchitektur an. Die Idee dahinter ist, dass die Entwicklung separater Funktionskomponenten oder Services schneller, einfacher, sicherer und effizienter ist, als dieselbe Funktion in ein eigenständiges und vollständig vernetztes System zu integrieren. Im Folgenden sehen wir uns den Microservices-Ansatz genauer an, samt seiner Eigenschaften, Vorteile und Herausforderungen.
Um herauszufinden, was Microservices sind, hilft es zu verstehen, was sie nicht sind. Es gibt zahlreiche Unterschiede zwischen Microservices und anderen Organisationsansätzen. Im Folgenden vergleichen wir Microservices mit traditionellen monolithischen Architekturen sowie mit der neueren serviceorientierten Architektur (SOA).
Der Begriff Monolith stammt aus dem Griechischen und bedeutet so viel wie „aus einem Stein“. Er beschreibt Anwendungen, bei denen jede Komponente weitgehend mit benachbarten Komponenten verbunden und von ihnen abhängig ist. Monolithische Architekturen sind der traditionelle Entwicklungsansatz – hier werden alle Funktionen über einen Ort verwaltet und bereitgestellt, und alles wird auf einer einzigen Codebasis entwickelt. Jegliche Changes, die Entwickler in monolithische Strukturen implementieren möchten, ändern also zwangsweise den gesamten Stapel. Und auch Aktivitäten wie Tests gelten für den ganzen Stapel. Daher werden Changes in großen Releases zusammengefasst und können relativ viel Zeit beanspruchen, bis sie abgeschlossen sind. Microservices unterscheiden sich von Monolithen: Sie bestehen aus mehreren kleineren, eigenständigen und lose verbundenen Komponenten. So können Changes an einzelnen Komponenten vorgenommen werden, ohne hierdurch die anderen Services der Anwendung zu beeinträchtigen.
Der Unterschied zwischen Microservices und SOA ist etwas subtiler. Zwar verlassen sich beide Ansätze auf wiederverwendbare Komponenten, die modular auf unterschiedliche Anwendungen angewendet werden können, doch eine SOA ist nicht so präzise wie Microservices. Während Microservices so weit containerisiert werden, dass jeder Service nur eine bestimmte Funktion erfüllt, kann es sich bei SOA‑Komponenten um ganze Subsysteme handeln, die für zahlreiche Geschäftsfunktionen zuständig sind. Darüber hinaus optimiert eine SOA die gemeinsame Nutzung von Komponenten sowie ihre Abhängigkeiten, während Microservices einfach nur versuchen, diese Aspekte zu minimieren.
In der Regel weisen Microservices folgende Eigenschaften auf:
Da Microservices als Sammlung individueller, unabhängiger Services aufgebaut sind, können sie einfach als eigenständige Komponenten getestet werden. Innerhalb der Komponenten können Probleme leicht eingegrenzt werden. So müssen Entwickler nicht mehr ganze Systeme und Anwendungen testen und dann viel Zeit investieren, um die Ursache bestimmter Fehler zu finden.
Um Hand in Hand zu arbeiten, müssen Microservices miteinander kommunizieren. Hierbei handelt es sich jedoch nur um eine lose Verbindung, bei der Änderungen des einen Service sich nicht direkt auf die anderen auswirken.
Anstatt sich einen gemeinsamen Datenspeicher zu teilen, verwendet jede Komponente einen eigenen. So werden versehentliche Kopplungen verschiedener Services verhindert, damit Changes nicht plötzlich andere Services beeinflussen, die eigentlich unabhängig sein sollten.
Die individuellen Services werden geändert und in der Produktionsumgebung bereitgestellt, ohne hierfür andere Services einsetzen zu müssen. Alle Bereitstellungen innerhalb des Systems werden auf diese Weise verwaltet, wodurch sich ein Microservice schnell erweitern lässt.
Microservices setzen auf funktionsübergreifende Teams, die um einen einzigen Geschäftszweck herum organisiert sind. Diese Teams umfassen häufig Entwickler, Datenbanktechniker, Tester, Infrastrukturtechniker und andere Personen – mit dem Ziel, basierend auf mehreren unabhängigen Services spezifische Produkte zu entwickeln.
Bei Microservices ist jeder unabhängige Service in der Lage, Anforderungen zu empfangen, zu verarbeiten und zu beantworten. Dieser Ansatz ist deutlich einfacher als viele traditionellere Systeme, in denen komplexe Weiterleitungen und Anwendungsschichten mit Geschäftsregeln den Prozess verlangsamen können.
Damit ein Microservices-System vollständig in die Knie geht, müssen im Grunde all seine Komponenten gleichzeitig ausfallen. Da es auf lose verbundenen Services basiert, kann das System mit nahezu optimaler Kapazität weiterarbeiten, selbst wenn einer seiner Services ausfällt. Und da die Services dezentralisiert sind, sollte der Ausfall einer Komponente wenig bis gar keine Auswirkungen auf die benachbarten Services haben.
Da Microservices modular aufgebaut sind, ist es verhältnismäßig einfach, bei Bedarf neue Services hinzuzufügen. So können Unternehmen aktuelle Systeme an neue Anwendungsfälle anpassen und sie nach oben oder unten skalieren, um den geänderten Bedarf zu berücksichtigen.
Bei der Entwicklung neuer Software können Unternehmen aus verschiedenen Technologiestapeln frei wählen. Und sie können auch neue Technologiestapel implementieren, wenn sie Änderungen an bestehenden Services vornehmen.
Der modulare containerisierte Ansatz der Microservices macht sie zum perfekten Partner für DevOps und kontinuierliche Integration/Bereitstellung (Continuous Integration/Deployment, CI/CD). Da jeder Service als eigene Einheit behandelt wird, können mehrere Teams gleichzeitig daran arbeiten, neue Funktionen zu entwickeln. So lassen sich DevOps-Prinzipien anwenden, und Projekte gelangen schnell durch die CI/CD-Pipelines.
Es ist zwar möglich, dass Microservices direkt miteinander kommunizieren, doch viele Unternehmen integrieren API-Gateways, die als Zwischenebene zur Weiterleitung von Anforderungen dienen, eine zusätzliche Authentifizierung implementieren und die Sicherheit steigern. Die API‑Kommunikation ist besonders effektiv, wenn Microservices zunächst den Status übermitteln.
Microservices stellen eine Alternative zu traditionellen Entwicklungsarchitekturen dar und bieten gegenüber klassischeren Organisationsansätzen zahlreiche Vorteile, darunter:
Mit Microservices können kleine, unabhängige Teams innerhalb eines klar definierten Kontexts agieren. So können sie in weniger Zeit mehr erreichen und agiler auf unerwartete Veränderungen reagieren.
Microservices teilen komplexe Anwendungen und Systeme in kleinere und einfachere Komponenten auf. Hierdurch können Entwickler leichter zwischen einzelnen Services unterscheiden und die nötigen Updates und Verbesserungen vornehmen.
Anstatt auf eine einzige Sprache oder einen Technologiestapel beschränkt zu sein, können Entwickler flexibel die besten Lösungen, Tools und Ressourcen für jede individuelle Funktion auswählen – ohne sich Sorgen um die Kommunikation zwischen den Services machen zu müssen.
Da auf Microservices basierende Anwendungen modular aufgebaut sind, lassen sie sich verhältnismäßig einfach entwickeln und bereitstellen. Teams können sich koordinieren, um gleichzeitig an einzelnen Komponenten zu arbeiten, und jede Komponente kann auch unabhängig bereitgestellt werden.
In der klassischen Entwicklungsarchitektur muss oft die gesamte Anwendung skaliert werden, um einen geänderten Bedarf zu decken. Mit Microservices können Entwickler Ressourcen umleiten, um nur die betroffenen Services und Komponenten zu skalieren. So wird die Skalierung beschleunigt, und die damit verbundenen Kosten sinken.
Wenn einmal ein Microservice ausfällt, bleiben die benachbarten Services hiervon unberührt. Das heißt, dass auf Microservices basierende Anwendungen in der Regel nicht abstürzen. Denn wenn eine oder mehrere Komponenten ausfallen, kann die Anwendung weiterhin bei reduzierter Funktionalität ausgeführt werden, bis der betroffene Service repariert wurde.
Da jeder Service eigenständig ist und seine spezifische Funktion unabhängig von anderen Komponenten erfüllt, können Entwickler Services für zahlreiche verschiedene Anwendungen wiederverwenden oder recyceln. Die Komponenten können wie Bausteine verwendet werden und machen es überflüssig, bei jedem neuen Projekt den Code von Grund auf neu zu schreiben.
Gesteigerte Agilität, verbesserte Wiederverwendbarkeit und vereinfachte Bereitstellung sorgen allesamt für kürzere Entwicklungszyklen und Markteinführungszeiten. So können sie die Umsätze verbessern und insgesamt zu einer besseren Benutzer-Experience führen.
Doch neben den vielen Vorteilen bringen Microservices auch einige Nachteile mit sich. Im Folgenden werfen wir einen genaueren Blick auf die Herausforderungen, die Unternehmen bei der Implementierung einer Microservice-Architektur erwarten können:
Für den Wechsel zu Microservices müssen sämtliche Abhängigkeiten zwischen Services identifiziert und katalogisiert werden – absolut alle. Durch Abhängigkeiten kann es durch die Fertigstellung eines einzigen Builds notwendig werden, eine Reihe anderer Builds zu implementieren, was frustrierend und zeitaufwendig sein kann.
Ein wichtiger Faktor von Microservices besteht darin, dass jede Komponente über eine eigene, isolierte Datenbank verfügt. Doch mit jeder neuen Datenbank wird die Verwaltung etwas komplexer. Je mehr Services – und Datenbanken – implementiert werden, desto aufwendiger wird es, die Daten zu managen.
Wenn Anwendungen mithilfe von Microservices auf neue Versionen aktualisiert werden, besteht die Chance, dass die Abwärtskompatibilität beeinträchtigt wird. Die Lösungen – also die Integration einer bedingten Logik oder die Einrichtung mehrerer Liveversionen für unterschiedliche Kunden – können am Ende äußerst komplex in Wartung und Verwaltung sein.
Microservices sollen die Bereitstellung vereinfachen. Doch die Komplexität, die die Arbeit an einer Vielzahl unabhängiger Komponenten mit sich bringt, kann schnell erdrückend wirken. Automatisierung kann dieses Problem lösen.
Die Protokollierung kann sich schwierig gestalten, wenn jeder Service seine eigene Datenbank verwendet. Hierfür ist möglicherweise die Einrichtung zentralisierter Protokollierungslösungen erforderlich. Und auch die Überwachung und Verwaltung der einzelnen Services ist möglicherweise ohne eine zentrale Ansicht und eine zentrale Datenquelle nicht umsetzbar.
Mit potenziell Hunderten von Microservices, die in eine einzige Anwendung integriert sind, ist das klassische Debugging keine Option.
Teams erhalten mit der Microservice-Architektur ein hohes Maß an Unabhängigkeit. Doch das hat auch eine Kehrseite: Um Probleme zu lösen, die sich über mehr als einen Service innerhalb der Anwendung erstrecken, ist möglicherweise teamübergreifende Kommunikation und Koordination erforderlich.
Da Microservice-Anwendungen verteilte Systeme sind, passiert es schnell, dass Teams Arbeiten doppelt ausführen. Das kann zu verschwendeten Ressourcen und ineffizienten Anwendungen führen.
Zusätzlich zu den oben aufgeführten Herausforderungen gibt es auch gewisse Stolpersteine, auf die Unternehmen achten sollten, wenn sie eine Microservice-Architektur implementieren wollen:
Microservices sind zwar eine äußerst beliebte Entwicklungsarchitektur, doch sie eignen sich in der Regel am besten für die Reparatur und Überarbeitung bestehender Anwendungen, die übermäßig komplex geworden sind und sich nur noch schwierig pflegen lassen. Sie sind nicht annähernd so effektiv, wenn sie als Ausgangspunkt verwendet werden. Wenn der traditionelle Ansatz die Grenze der „Unverwaltbarkeit“ noch nicht erreicht hat, dann muss der entsprechende Monolith auch nicht umstrukturiert werden.
Wie so ziemlich alles andere auch lässt sich ein Service immer weiter in kleinere und kleinere Teile zerlegen. Microservices sollten zwar punktuell sein und mehrere begrenzte Funktionen bereitstellen, um das große Ganze zu unterstützen, doch man kann es auch übertreiben. Viele Unternehmen müssen feststellen, dass es besser ist, mit größeren Services zu beginnen und sie nur dann in Microservices aufzuteilen, wenn ihre Bereitstellung zu langsam oder ihre Verwaltung zu komplex wird. So können sie gewährleisten, dass die vermeintliche Lösung nicht die potenziellen Vorteile beeinträchtigt.
Ein großes und verteiltes System gerät schnell außer Kontrolle. Um die Effektivität der Microservices zu gewährleisten, können Unternehmen fortschrittliche Automatisierung in den Bereichen Bereitstellung und Überwachung einsetzen – ebenso wie verwaltete Cloud-Services. Hierdurch wird der Umstieg auf Microservices deutlich leichter.
ServiceNow kann Sie nicht nur bei den Verwaltungsaspekten Microservice-basierter Komponenten, sondern auch bei der Verbindung mit Methodiken und Tools unterstützen, die in Entwicklungsphasen verwendet werden, wie z. B. CI/CD und andere DevOps-Lösungen.
Um die potenziell riesige Anzahl von Microservices mitsamt ihrer flüchtigen Natur optimal zu handhaben, bietet ServiceNow Optionen für das automatische Ausfüllen der CMDB. Und mit Service Graph können Sie Beziehungen nachverfolgen und die Definition von Services pflegen. All das ist Teil unserer Lösung IT Operations Management, die auch erweiterte Cloud-Management-Fähigkeiten umfasst.
Wie bei jedem Code, der mit DevOps-Praktiken entwickelt wird, ist Geschwindigkeit ein häufiges Ziel bei der Pflege von Microservices. Das heißt, dass der kürzestmögliche Pfad zwischen Entwickler und Produktionssystem bereitgestellt werden muss. Doch größere oder streng regulierte Unternehmen müssen gleichzeitig starke Kontrollen gewährleisten. Hierfür umfasst IT Service Management Professional unsere Funktion „DevOps Change Velocity“, die eine Verbindung zur CI/CD-Pipeline herstellt, während der Entwicklung Informationen erfasst und mithilfe dieser Informationen sowie zuvor definierter Richtlinien den Change-Management-Prozess automatisiert.
Darüber hinaus bietet ServiceNow auch zahlreiche Fähigkeiten, die von internen und externen Anwendungen auf Microservice-ähnliche Weise genutzt werden können – zusätzlich zur Integration externer Microservices in ServiceNow-Workflows.
Die ServiceNow AI Platform bietet Kernfähigkeiten, mit denen Sie Workflows schnell und effizient digitalisieren und leicht skalieren können.