Server-Strukturen der nächsten Generation Übergang zu Microservices – wo liegen Chancen und Risiken?

Autor / Redakteur: Owen Garrett * / Ulrike Ostler |

Microservices bieten zweifelsfrei Chancen, ökonomisch und relativ schnell alte Anwendungsumgebungen zu modernisieren. Doch es gilt – nicht gerade triviale – Anforderungen zu beachten. Hier ein Einblick.

Anbieter zum Thema

Bakterien, wie hier nachgebildet, sind mehr oder minder autonome Mikro-Organismen; sie können Gutes bewirken oder auch viel Schaden anrichten. Eine Analogie zu Microservices liegt nahe.
Bakterien, wie hier nachgebildet, sind mehr oder minder autonome Mikro-Organismen; sie können Gutes bewirken oder auch viel Schaden anrichten. Eine Analogie zu Microservices liegt nahe.
(Bild: gemeinfrei: Geralt/ Pixabay / CC0 )

Microservices teilen Anwendungen abhängig von den betrieblichen Möglichkeiten in eine kleine Menge untereinander verbundener Dienste auf. Jeder Dienst übernimmt dabei eine Gruppe unterschiedlicher Funktionen und dient somit als eine Minianwendung mit eigener Anwendungslogik, eigenen Adaptern und sogar einem Datenbankschema.

Diese Dienste lassen sich dann in verschiedener Weise zusammenfügen und können verschiedene neue Produkte bilden. Damit scheinen Microservices ideal zu sein für die schnelle Entwicklung neuer Anwendungen und den Ersatz althergebrachter. Allerdings ist schon die Verwaltung einer dynamischen, aus so vielen Einzelteilen bestehenden Umgebung keine einfache Aufgabe.

Die Chancen einer Microservices-Architektur

Eine Microservices-Architektur geht das Problem der Komplexität an und unterstützt Unternehmen bei der Optimierung ihrer Entwicklungs- und Anwendungsressourcen. Mit ihr lässt sich eine unhandliche, monolithische Anwendung in eine Gruppe gut handhabbarer Dienste zerlegen, von denen jeder durch Remote Procedure Calls (RPCs) oder nachrichtengesteuerte Application Programming Interfaces (APIs) sauber abgegrenzt ist.

Durch diesen Modularitätsgrad sind einzelne Dienste wesentlich schneller zu entwickeln und vor allem viel einfacher zu verstehen und zu pflegen. Die Microservices-Architektur ermöglicht es Teams, einen bestimmten Dienst zu entwickeln, auf den sie sich konzentrieren können.

Die Entwickler entgehen mit Microservices dem Problem, Technologien einsetzen zu müssen, die absehbar bald nach Projektstart veraltet sein werden. Weil die Dienste relativ klein sind, können Entwickler einen alten Dienst recht rasch neu programmieren und dabei die jeweils modernste Technologie einsetzen.

Jeder Microservice lässt sich unabhängig von anderen implementieren.
Jeder Microservice lässt sich unabhängig von anderen implementieren.
(Bild: gemeinfrei: Geralt /Pixabay / CC0 )

Kontinuierliche Implementierung und intelligente Skalierung

Jeder Microservice lässt sich unabhängig von anderen implementieren. Deshalb brauchen Entwickler die Implementierung lokaler Änderungen ihres Dienstes nicht untereinander zu koordinieren. Die Beachtung von Architekturregeln, etwa für RPCs und APIs, vorausgesetzt, sind Aktualisierungen und neue Funktionen theoretisch schnell und einfach zu implementieren. Das ermöglicht vor allem dort eine kontinuierliche Implementierung, wo dies zuvor nicht möglich war.

Häufig ist die Skalierbarkeit ein Problem monolithischer Anwendungen, sie können mit den betrieblichen Erfordernissen nicht Schritt halten. Microservices hingegen bieten eine Chance, solchen Engpässen zu begegnen; denn sie sind horizontal skalierbar. Unternehmen können genau die benötigte Anzahl von Instanzen jedes Dienstes implementieren und dazu die Hardware einsetzen, die am besten zu den Ressourcen-Anforderungen des jeweiligen Dienstes passen.

Die Architekturkonzeption ist anspruchsvoll

Doch Achtung! Weil es das Ziel einer Microservices-Architektur ist, Anwendungen in handhabbare Teile zu zerlegen, müssen diese Teile eine vernünftige Größe aufweisen. Sind die Dienste zu groß oder zu klein, gibt es bei den damit erstellten Anwendungen später Probleme. Besonders Entwickler, die mit solchen Architekturen noch unerfahren sind, tun sich damit schwer.

Auch gilt: Einer der größten Vorteile der Microservices-Architektur, ihre verteilte Struktur, stellt gleichzeitig eine der größten Herausforderungen dar, nämlich wenn es um das Testen, die Implementierung und die Skalierung von Anwendungen geht. Bei der Implementierung von Änderungen sind die gegenseitigen Abhängigkeiten der Dienste ein Problem. Die Entwickler müssen die Umsetzung von Änderungen in den einzelnen Diensten sorgfältig planen und koordinieren.

In einer monolithischen Anwendung gibt es zumeist nur eine einzige Datenbank. Das macht die Handhabung einfach. In einer auf Microservices basierten Anwendung sind per se mehrere Datenbanken zu aktualisieren, die zu unterschiedlichen Diensten gehören.
In einer monolithischen Anwendung gibt es zumeist nur eine einzige Datenbank. Das macht die Handhabung einfach. In einer auf Microservices basierten Anwendung sind per se mehrere Datenbanken zu aktualisieren, die zu unterschiedlichen Diensten gehören.
(Bild: gemeinfrei: geralt/Pixabay / CC0 )

Das Problem partitionierter Datenbanken

Geschäftliche Buchungen, die sich auf mehrere Betriebe gleichzeitig auswirken, sind sehr verbreitet. Da es ja in einer monolithischen Anwendung nur eine einzige Datenbank gibt, ist die Implementierung solcher Buchungen dort trivial. In einer auf Microservices basierten Anwendung muss man jedoch mehrere Datenbanken aktualisieren, die zu unterschiedlichen Diensten gehören.

Manche Unternehmen versuchen, ihre monolithischen Anwendungen durch selbstgestrickten Code aufzubrechen. Möglicherweise klappt das zunächst auch. Im Laufe der Zeit wächst jedoch die Anzahl der Microservices, der gegenseitigen Abhängigkeiten und die Komplexität. Zunehmend mehr Entwickler arbeiten an der Architektur, so dass alles immer schwerer in den Griff zu bekommen ist. Die Unternehmen sollten rechtzeitig die Implementierung beim Auffinden der Dienste, die Lastverteilung, das Caching und Layer-7-Routing planen.

Auch die Sicherheit wird mehr und mehr zu einem Problem, wenn immer mehr Microservices ins Spiel kommen. Eine Sicherheitslücke in einem Microservice kann die ganze Anwendung in Gefahr bringen. Gleichzeitig macht die vielfältige Struktur der Microservices Sicherheitsmaßnahmen nicht eben leicht. Es ist wichtig, eine Verschlüsselung von Ende zu Ende zu implementieren, damit das schwächste Glied in der Kette nicht möglicherweise großen Schaden anrichtet.

Neue Praktiken, neue Kultur und die Hilfsmittel

Die Abgrenzung der einzelnen Dienste untereinander und die Festlegung der Verantwortlichkeiten kann durchaus einige Zeit und eine kulturelle Anpassung erfordern, die nicht zu unterschätzen sind. Sinnvoll ist es, zunächst mit einem kleinen Team aus Leuten mit unterschiedlichem Know-how zu starten, die alles abdecken können - von den althergebrachten Sprachen des Monolithen bis hin zu Linux-Containertechnologien.

Die erfolgreiche Umsetzung einer Microservices-Anwendung erfordert besser gesteuerte Implementierungsmethoden durch die Entwickler und mehr Automatisierung. Die Unternehmen sollten im Idealfall eine Microservices-Referenzarchitektur einführen, die gebrauchsfertige Vorlagen für die schnelle und bessere Entwicklung sowie eine gemeinsame Testplattform für neue Funktionen bietet.

Microservices: Schlüssel zur Kundenorientierung

Microservices sind selbstverständlich nicht perfekt. Und sie können nicht alle Probleme eines Unternehmens mit althergebrachten Anwendungen lösen. Sie können jedoch ein Unternehmen sehr wohl dabei unterstützen, seine geschäftlichen und informationstechnischen Bedürfnisse besser aufeinander abzustimmen – und letztlich das monolithische Datenmonster zu bändigen.

Owen Garrett, Head of Products bei NGINX.
Owen Garrett, Head of Products bei NGINX.
(Bild: NGINX)

Das heutige Geschäftsumfeld wird unablässig von den Anforderungen der Kunden vorangetrieben. Deshalb müssen Unternehmen sich darauf einstellen, Anwendungen zu entwickeln, zu testen, zu integrieren und bereitzustellen – und das nicht als einmalige Aktion, sondern laufend und praktisch in Echtzeit. Genau dafür sind Microservices die beste Basis.

* Owen Garrett ist Head of Products bei Nginx.

(ID:45062489)