Wie funktionieren eigentlich Microservices?

Microservices erlauben Unternehmen, komplexe Architekturen in der Informationstechnik auf einzelne Module herunterzubrechen und damit von vielen Vorteilen zu profitieren. Voraussetzung ist allerdings, dass einige grundlegende Aspekte berücksichtigt werden. Welche Herausforderungen können dabei auftreten und wie gelingt der Umstieg? Das und mehr erfahren Sie im folgenden Beitrag.

Was sind Microservices?

Ob Social-Media-Unternehmen, Einzelhändler oder Finanzdienstleister: Viele der Global Player haben der klassischen monolithischen Architektur den Rücken gekehrt und setzen auf Microservices. Immer mehr Unternehmen folgen, um von den Vorteilen des besonderen Architekturdesigns zu profitieren. Allein von 2019 bis 2020 ist der Anteil der Microservice-Anwendungen um 20 % gestiegen.

Microservices beziehungsweise Mikrodienste sind ein Architekturansatz für die Softwareentwicklung, genauer für den Aufbau verteilter Anwendungen. Als kleine unabhängige Segmente erfüllen Microservices isoliert von anderen Prozessen und Diensten jeweils einzelne Aufgaben. Innerhalb einer Anwendung arbeiten die verschiedenen, lose gekoppelten Services wie Module zusammen und kommunizieren mittels APIs über definierte Schnittstellen. Mehrere dieser Services werden per APIs wieder zu einem großen Dienst (Container) gekoppelt, um die erwartete und notwendige Funktionalität nach außen zur Verfügung zu stellen.

Ein typisches Microservice-Framework ist ein Onlineshop, in dem Prozesse wie Produktsuche, Produktempfehlungen und Bezahlung separat voneinander arbeiten können. Ebenfalls typisch: Microservices werden von kleinen, dedizierten Entwicklerteams gemanagt, wobei ein Team auch für das Development mehrerer Dienste verantwortlich sein kann.

Monolithische Architektur vs. Microservice-Architektur

Traditionelle Softwarearchitekturen sind monolithisch aufgebaut, d. h. der Quellcode der gesamten Anwendung liegt in einer untrennbaren Entwicklungseinheit. In einer monolithischen Architektur sind die einzelnen Anwendungsprozesse daher eng miteinander verbunden und arbeiten als ein Service zusammen. Das Hinzufügen neuer Features ist oft aufwändig und komplex, was Fortschritte verzögern und Neuerungen ausbremsen kann. Das liegt daran, dass bestehende Funktionen stark miteinander verzahnt sind und Veränderungen einzelner Funktionen häufig die Neukonfiguration und Aktualisierung aller Prozesse und der Anwendungssicherheit erfordern. Monolithische Softwarearchitekturen gefährden daher nicht nur die Softwareverfügbarkeit, da ein Prozessausfall bei vielen voneinander abhängigen und eng verknüpften Prozessen oft weitreichende Folgen hat. Darüber hinaus erschweren sie auch die Weiterentwicklung, da jedes neue Feature immer länger für die Entwicklung braucht und damit immer teurer wird.

Anwendungen in einer Microservice-Architektur sind anders strukturiert. Wie oben erklärt, besteht jede Anwendung aus eigenständigen Komponenten, die jeden Prozess der Applikation als separaten Service abbilden. Änderungen sind innerhalb kurzer Zeit möglich, ohne dass die Verfügbarkeit anderer Anwendungen darunter leidet. Die Komponenten sind voneinander losgelöst und können unabhängig – auch von unterschiedlichen Teams – entwickelt werden.

Microservices vs. SOA – die wichtigsten Unterschiede

Im Zusammenhang mit Microservices fällt häufig der Begriff Service-Oriented Architecture (SOA). Auch SOA beschreibt einen architektonischen Gegenentwurf zum monolithischen Ansatz und wird nicht selten mit Microservices verwechselt oder gleichgesetzt. Beide Ansätze kombinieren zum Beispiel mehrere Dienste und stellen Anwendungen in der Regel in der Cloud bereit, weshalb sie flexibel verändert und skaliert werden können. Auch die Kommunikationsmechanismen funktionieren ähnlich.

Demgegenüber stehen aber wesentliche Unterschiede. Während Microservices zum Beispiel Anwendungen strukturieren, liefert SOA die Strategie zur Strukturierung der gesamten IT-Landschaft eines Unternehmens. SOA kann aus orchestrierten Mikroservices bestehen, muss es jedoch nicht. Die wichtigsten Unterschiede haben wir nachfolgend für Sie zusammengefasst:

 

	SOA	Microservices
Zweck	Strukturierung der gesamten IT-Umgebung	Strukturierung einzelner Anwendungen
Architektur	stellt Ressourcen bereit, die von allen Diensten gemeinsam verwendet werden	hostet Dienste, die unabhängig voneinander funktionieren können
Nutzung von Komponenten	Komponenten können gemeinsam genutzt werden	Komponenten werden meist nicht gemeinsam genutzt
Granularität	größere, modular strukturierte Dienste	kleinere, stärker differenzierte Dienste
Governance	teamübergreifende, gemeinsame Governance-Protokolle	verwaltet von dedizierten Teams, erfordert gute Zusammenarbeit
Kommunikation	kommuniziert via Enterprise Service Bus (ESB) als Single Point of Failure	kommuniziert via API, meist Representational State Transfer (REST), losgelöst von einem ESB
Datenspeicherung	mehrere Services teilen sich einen Datenspeicher	jeder Service nutzt einen eigenen Datenspeicher
Umfang	geeignet für größer angelegte Integrationen	geeignet für kleinere, webbasierte Anwendungen wie Onlineshops
Bereitstellung	weniger flexibel bei der Bereitstellung	schnelle und flexible Bereitstellung

 

Vorteile von Microservices

Richtig auf- und eingesetzt, bieten Microservice-Architekturen Unternehmen eine Reihe von Vorteilen – von schnellerer Softwareentwicklung bis hin zu mehr Sicherheit.

• Eigenständigkeit der Komponenten: ermöglicht schnelle Entwicklung, Bereitstellung, Ausführung, Skalierung
• Hohe Agilität: Verwaltung durch kleine dedizierte Teams beschleunigt Prozesse, vereinfacht Wartung, verkürzt Entwicklungszyklen
• Flexible Skalierung: Dienste skalieren individuell nach realen Anforderungen
• Mehr Innovationsspielraum: geringe Ausfallkosten begünstigen technologische Experimente
• Wiederverwendbarer Code: ermöglicht neue Funktionen ohne Code komplett neu zu programmieren
• Hohe Ausfallsicherheit: jeder Dienst erfüllt eine Funktion, abhängige Anwendungen bleiben bei einem Ausfall der Microservices größtenteils weiterhin verfügbar

Herausforderungen und Nachteile

Wie so oft, gibt es auch in puncto Microservices einen Haken: Ihr Einsatz wird von einigen Herausforderungen begleitet, die die IT des Unternehmens beeinträchtigen können.

• Erhöhter Entwicklungs- und Betriebsaufwand: Integrations- und End-to-End-Tests, Deployment und Versionierung sind in einer heterogenen Umgebung deutlich komplexer
• Fachwissen erforderlich: Verstehen neuer Technologien und Definieren der Abhängigkeiten zwischen Microservices erfordern sicheres Know-how
• Korrekte Einrichtung: Datenkonsistenz und unabhängige Bereitstellung sind essentiell, damit ein Microservice-Ausfall andere Komponenten nicht beeinträchtigt
• Risiko des gemeinsamen Datenmodells: globales Datenmodell für alle Microservices verursacht gefährliche Abhängigkeiten und verhindert getrenntes Deployment
• Lückenloses Monitoring: granulare Aufteilung jeder Anwendung in viele Objekte, APIs und Prozesse erschwert die Überwachung und gefährdet die IT-Security
• Organisatorische und kulturelle Herausforderungen: Microservices brauchen Teams, die eigenverantwortlich agieren, reibungslos kooperieren und gut organisiert sind

Microservices vs Microsegmentation?

Sie kennen nun die wichtigsten Vor- und Nachteile von Microservices – doch welche Rolle spielt Microsegmentation in diesem Zusammenhang? Der Ansatz wird mit Microservices häufig gleichgesetzt, dabei handelt es sich um zwei unterschiedliche Konzepte. Was Mikrodienste auf Anwendungsebene leisten, bewirkt Microsegmentation auf Netzwerkebene. Als Netzwerkarchitektur bricht die Mikrosegmentierung eine monolithische Struktur wie Sicherheitsfunktionen im Netz auf und verteilt sie auf mehrere kleine Segmente. Security-Richtlinien werden dabei in weitere fokussierte Richtlinien zerlegt und rücken physisch näher an die jeweilige Anwendung heran. Beide Ansätze können dementsprechend getrennt voneinander genutzt werden. Im Idealfall folgt Microsegmentation jedoch der Entscheidung für Microservices.

8 Tipps für den Umstieg auf Microservices

So weit, so gut. Aber wie gelingt Unternehmen der Umstieg auf die neue Anwendungsumgebung? Die kurze Antwort: Step-by-Step auf Basis einer sorgfältigen Planung, Kalkulation und Umsetzung. Zumindest die typischen Stolperfallen lassen sich einfach vermeiden, wenn Sie sich die folgenden Tipps zu Herzen nehmen.

1. Eignung prüfen: Microservices sind vor allem dann optimal, wenn in Ihrem Unternehmen Software regelmäßig verändert und skaliert oder neue Technologie schnell bereitgestellt werden muss.
2. Migrationsplan erstellen: Vor der Migration müssen Umfang und Architektur vollständig erfasst werden – am besten mit einer Lösung, die jede einzelne Komponente und Abhängigkeit aufdeckt.
3. Know-how, Kapazitäten & Budget schaffen: Der Aufbau einer komplexen neuen Architektur erfordert spezielles Fachwissen, Kapazitäten und finanzielle Ressourcen. Kalkulieren Sie daher vorab die Kosten, sorgen Sie für das Training des Teams und planen Sie ausreichend Zeit ein.
4. Performance sicherstellen: Ein Vergleich der Performance-Metriken vor und nach der Migration stellt sicher, dass die Prozesse auch in der neuen Architektur wie gewünscht ablaufen und die User Experience nicht leidet.
5. Monitoring klären: Wegen der höheren Komplexität werden häufig mehrere Tools zur Überwachung benötigt. Sie brauchen granularen Einblick in alle Dienste, APIs, Arbeitslasten und Abläufe auf Prozessebene – am besten mit Hilfe grafischer Visualisierung.
6. Containerisierung: Gehen Sie auf Nummer Sicher und führen Sie die Services in einer standardisierten Laufzeitumgebung als Container aus. Auf diese Weise können die Container bei einem Release in der neuen Version bereitgestellt und übergangsweise parallel zur alten Version laufen.
7. Automatisierung: Hardware wie Rechner und Server, aber auch Prozesse wie Entwicklung, Testing und Deployment sollten so weit wie möglich automatisiert sein. Der Einsatz von Continuous Integration (CI) & Deployment (CD) zahlt sich aus.
8. Schrittweise umstellen: Nach der Einarbeitung in die neue Technologie und Architektur folgt die schrittweise Umstellung. Wenn möglich, sollten weniger kritische Services den Anfang machen und die alten neben den neuen Services vorübergehend parallel betrieben werden.

Fazit

Auch wenn eine Microservice-Architektur viele Vorteile hat, lohnt es sich, vorab den tatsächlichen Bedarf, die Herausforderungen und mögliche Nachteile zu bewerten. Verfügen Unternehmen über die nötigen Kompetenzen, Kapazitäten und finanziellen Ressourcen, kann die neue Architektur aber zentrale Probleme beheben und die Bereitstellung von Anwendungen massiv verbessern.