Mikrodienste könnten Firmen den Weg in die Cloud erleichtern

In Unternehmen findet derzeit ein nicht enden wollendes Tauziehen statt: Auf der einen Seite besteht der Drang, Anwendungen und Dienste zu zentralisieren und damit besser zu kontrollieren, auf der anderen Seite wird momentan jedoch die Auftrennung der Applikationen in lose miteinander verknüpfte und voneinander unabhängige Dienste benötigt, die schnell aufgerufen und auf alle möglichen Geschäftsprozesse abgebildet werden können.

Vielleicht ist es da ja an der Zeit, die Idee eines Unternehmens wieder aufzugreifen, das auf hochgradig verteilten Diensten basiert, die an keine bestimmten Plattformen, Abteilungen oder Machtbereiche gekoppelt sind. Dies erscheint besonders vor dem Hintergrund notwendig, dass sich Unternehmensteams die Zähne bei dem Versuch ausbeißen, Teile ihrer monolithischen Anwendungen in die Cloud umzuziehen.

Der Leitsatz hierbei lautet: „Nutze den Ansatz der Mikrodienstarchitektur.“ James Lewis und Martin Fowler, beide Mitarbeiter des Software-Unternehmens ThoughtWorks, nahmen diesen aufstrebenden IT-Architekturstil kürzlich genauer unter die Lupe. Sie untersuchten dabei auch, wie er mit der Aussicht auf hochgradig unabhängige Dienste zur Problemlösung beitragen könnte.

Eine Mikrodienstarchitektur beruht tendenziell auf REST-basierenden Diensten, die von funktionsübergreifenden Teams aufgebaut und betrieben werden. Dabei sollen sie vollständig unabhängig von darunterliegenden Plattformen und Anwendungen operieren. „Diese Art der Software-Systemen werden für uns immer attraktiver“, schreiben Lewis und Fowler. Sie stellten ein besonderes Konzept des Software-Anwendungsdesigns dar, das sie als Pakete unabhängig voneinander einsetzbarer Dienste vorsehe. Der Schwerpunkt liegt dabei auf der Dezentralisierung.

Die beiden ThoughtWorks-Mitarbeiter untersuchten zudem, was Mikrodienste von traditionelleren zentralisierten Unternehmensanwendungen unterscheidet. Eine detailliertere Analyse findet sich auf Martin Fowlers Homepage, eine kurze Zusammenfassung der Kernpunkte folgt hier:

Dienstebasierende Komponentisierung: Tendenziell scheinen viele Anwendungen über mehrere Bibliotheken innerhalb eines einzelnen Prozesses zu verfügen. Änderungen in einzelnen Komponenten bedeuten Lewis und Fowler zufolge somit, dass die gesamte Anwendung umstrukturiert werden muss.

Eine Mikrodienstarchitektur nutzt dagegen Out-of-Process-Dienste, um Anfragen an Bibliotheken zu richten, „die mit einem bestimmten Programm verknüpft sind und per In-Memory-Funktionsaufruf gestartet werden.“ Der Aufruf eines Dienstes geschieht dabei vollkommen unabhängig von der Applikation, die aufgerufen wird.

Ausgerichtet nach den Möglichkeiten des Unternehmens: Lewis und Fowler stellten fest, dass Änderungen an Diensten oftmals aus funktionaler Sicht vorgenommen werden. So tendieren Arbeitsgruppen, die beispielsweise für Nutzerschnittstellen, Datenbanken oder Server zuständig sind, dazu, „ihre eigene Logik, jeder Anwendung aufzuzwingen, zu der sie gerade Zugang haben“.

Mikrodienstbasierende Ansätze hingegen beruhen auf Diensten, die durch funktionsübergreifende Teams aufgebaut werden. Damit sollen die geschäftlichen Produkte und Services unterstützt werden – und nicht umgekehrt.

Produkte, keine Projekte: Auf der Diskussion der unternehmerischen Möglichkeiten aufbauend, gehen Lewis und Fowler noch einen Schritt weiter: Sie sind der Meinung, dass diese funktionsübergreifenden Service-Teams bestimmte Produkte über ihren gesamten Lebenszyklus hinweg „besitzen“ sollten.

„Grundlage dieser Annahme ist Amazons ‚Du hast es aufgebaut, du betreibst es auch‘-Ansatz. Dieser sieht vor, dass ein Entwicklerteam die volle Verantwortung für die zu entwickelnde Software übernimmt.“ Das bedeutet, dass die Software- und Dienste-Entwicklung nicht einfach nach der Fertigstellung des Produktes eingestellt wird, sondern dass die Teams gemeinsam mit der geschäftlichen Seite weiterhin die Software warten, verwalten und kontinuierlich verbessern.

Intelligente Endpunkte und dumme Datenströme: Der Mikrodienstansatz ist hochgradig dezentralisiert und meidet zugleich den Middleware-Ansatz. Hierzu zählt zum Beispiel das Konzept der Enterprise-Service-Busse, die die zentralisierte Nachrichtenweiterleitung, die Choreografie, die Umwandlung sowie die Anwendung von Geschäftsregeln unterstützen, wie Lewis und Fowler erklären. Als Alternative favorisiert dieser Ansatz einen Lightweight Message Bus.

Unter dem Strich, so betonen sie, sollen „Mikrodienstbasierende Anwendungen so abgekoppelt und gleichzeitig so zusammenhängend wie möglich sein. Sie verfügen über ihre eigene Domänenlogik und agieren tendenziell als Filter, die eine Anfrage entgegennehmen, eine bestimmte, für sie als geeignet empfundene Logik anwenden und darauf basierend eine Antwort produzieren.“

[Der Beitrag erschien ursprünglich auf ZDNet.com, Übersetzung: Rainer Schneider]

Tipp: Die Cloud ist mehr als nur ein Produkt oder eine Dienstleistung. Sie stellt vielmehr ein Bereitstellungsmodell dar. Entscheiden Sie sich für die Cloud, so wird Ihnen das neue Möglichkeiten eröffnen, IT-Dienstleistungen innerhalb und außerhalb Ihres Unternehmens zu erbringen und zu nutzen. Aber nach welchen Kriterien wählt man das passende Modell aus? Besuchen Sie am 27. März 2014 um 10 Uhr unser 40-minütiges Live-Webinar und erfahren Sie mehr. Zu weiteren Informationen und zur Registrierung.

Tipp: Sind Sie ein Fachmann in Sachen Cloud Computing? Testen Sie Ihr Wissen – mit dem Quiz auf silicon.de.