Fischschwarm versus Ozeandampfer: Mehr Flexibilität durch Restrukturierung von Monolithen in Microservices

Amazon, Ebay und Netflix sind gute Beispiele für erfolgreiche Großunternehmen, die längst Anwendungen mit Microservices-Architekturen einsetzen. Sie sind die nicht mehr ganz so geheimen Waffen der Entwickler, die den Unternehmen helfen, schnell, zuverlässig und effizient zu bleiben. Denn Microservices sind im Vergleich zu monolithischen Architekturen agiler und damit effizienter und verhalten sich ähnlich wie ein Fischschwarm im Verhältnis zu einem Ozeandampfer.

Dabei sind monolithische Anwendungen im heutigen Geschäftsbetrieb nach wie vor überaus gebräuchlich. Sie werden in herkömmlichen Entwicklungsumgebungen erstellt, lassen sich einfach entwickeln, testen und – zumindest am Anfang – auch einfach implementieren und skalieren. Die Sache hat nur einen Haken: Ein solcher Monolith wird immer größer und komplexer, bis er schließlich zu einem komplizierten Code-Monster wird. Das ist für Organisationen, die flexibel auf sich ständig wandelnde geschäftliche Anforderungen und Kundenwünsche reagieren müssen, eine Herausforderung.

Es gibt Situationen, da sind Monolithen durchaus von Vorteil.

Vor allem in der Anfangszeit der Anwendungsentwicklung wird dieses Konzept favorisiert, weil es ja bekannt und damit etabliert ist. Bei Monolithen befindet sich die Geschäftslogik im Kern ihrer Anwendung, sie werden durch Module für die einzelnen Dienste, Objekte und Ereignisse implementiert. Dieser Kern wird dann von Datenbanken und Komponenten für Meldungen sowie die durch ein API oder eine Benutzerschnittstelle realisierte Web-Anbindung umgeben und mit der Außenwelt verbunden.

Auch wenn solche Anwendungen modular konzipiert wurden, so sind sie doch als Monolith implementiert. Gute Beispiele dafür sind Java-Anwendungen, die auf Anwendungs-Servern implementiert und als WAR-Dateien beziehungsweise als eigenständige und ausführbare JAR-Dateien verpackt sind oder auch Rails- und Node.js-Anwendungen, die als Verzeichnishierarchie verpackt sind.

Zu Beginn eines Projekts hat dieses Modell viele Vorteile. Werden die Anwendungen jedoch größer und kommen neue Funktionen hinzu, so wird im Laufe der Zeit alles komplexer und schwerfälliger. Je erfolgreicher eine Anwendung ist, desto schwieriger wird meist ihre Handhabung, weil sie neben der ursprünglichen Information aus vielen, nach und nach ergänzten Quelltext-Zeilen besteht.

Wenn, mit der Zeit, die Probleme kommen

Spätestens dann ist eine kontinuierliche Bereitstellung nicht mehr möglich: Der Monolith muss in kleinere Teile zerlegt werden. Regressionstests können bei einem großen Monolith eine ungeheure Zeit in Anspruch nehmen, vor allem wenn besondere Anforderungen zu manuellen Tests der Benutzerschnittstelle erwartet werden. Für Entwickler wird die Arbeit dann (besonders für diejenigen, die die Anwendung nicht kennen) sehr schwierig, wenn nicht sogar fast unmöglich. Die für die Fehlerbehebung und Beseitigung von Schwachstellen benötigte Zeit wächst dann exponentiell – ganz zu schweigen vom Zeitaufwand für den Einbau neuer Funktionen.

Das allein ist schon schwierig genug – doch Unternehmen müssen heute zusätzlich effizient auf neue Kundenwünsche und sich wandelnde Marktbedingungen reagieren. Wenn schon kleine Änderungen an einer geschäftskritischen Anwendung dem Wenden eines Ozeandampfers gleichkommt, dann ist folglich die Wettbewerbsfähigkeit eines Unternehmens deutlich eingeschränkt.

Monolithische Anwendungen sind ein erhebliches Hindernis für Innovation und Erfolg.

Denn Schwierigkeiten bei der Skalierbarkeit können die Flexibilität eines Unternehmens, auf steigende Nachfrage zu reagieren, stark einschränken. So ist etwa die Integration neuer Sprachen und Technologien mitunter eine große Herausforderung. Da DevOps, Microservices und Container heute sehr gängige Anwendungen sind, erschweren Monolithen auch die Rekrutierung neuer Entwickler, die ja meist mit den modernsten Technologien arbeiten wollen.

Microservices als Lösung

Was also tun? Die Großen machen es vor. Sie verwenden Microservices-Modelle, in denen die Anwendungen abhängig von den betrieblichen Möglichkeiten in eine kleine Menge untereinander verbundener Dienste aufgeteilt werden. Jeder Dienst realisiert dabei eine Gruppe unterschiedlicher Funktionen und dient somit als Minianwendung mit eigener Anwendungslogik, eigenen Adaptern und sogar einem Datenbankschema. Solche Dienste können dann auf verschiedene Weise zusammengefügt werden und insgesamt als neues Produkt dienen.

Für Martin Fowler, US-amerikanischer Autor, Software-Entwickler und früher Verfechter von Microservices, ist das Microservices-Modell »ein Ansatz zur Entwicklung einer Gesamtanwendung als eine Gruppe kleiner Dienste, die jeweils als eigener Prozess laufen und über einfache Mechanismen, häufig HTTP-basierte APIs, miteinander kommunizieren.« Diese Dienste sollten an die betrieblichen Möglichkeiten angepasst und von einem vollautomatischen Implementierungsvorgang unabhängig voneinander implementiert werden, so seine Meinung. Schließlich existiere nur ein Mindestmaß an zentralisiertem Management für diese Dienste, die in unterschiedlichen Programmiersprachen geschrieben seien und verschiedene Datenspeicherungsmechanismen nutzen können.

Wann, wenn nicht jetzt?

Die Idee der Microservices ist bei weitem nicht neu, das Konzept im heutigen, sich dynamisch wandelnden Geschäftsumfeld aber wichtiger denn je. Jeder Dienst hat klar definierte Grenzen und kommuniziert mit anderen Diensten über irgendwelche APIs. Das Modell erzwingt einen Modularitätsgrad, mit dem die einzelnen Dienste schneller zu entwickeln, zu testen und zu implementieren sind. Der zusätzliche Vorteil für Entwickler: Diese Dienste sind wesentlich einfacher zu verstehen und zu pflegen.

Das Microservices-Modell macht es für Entwickler-Teams außerdem einfacher, sich jeweils auf einen Dienst statt auf eine ganze, monolithische Anwendung zu konzentrieren. Entwickler werden also nicht durch die für den ursprünglichen Monolithen verwendeten Technologien eingeschränkt. Vielmehr können sie für die zu erledigende Aufgabe die geeignetste Technologie auswählen und Schritt für Schritt vorgehen. Auch jeder Dienst hat so sein eigenes Datenbankschema. Selbst wenn dies dem Prinzip eines unternehmensweiten Datenmodells widerspricht, so erlaubt es den Entwicklern dennoch, das am besten zum jeweiligen Dienst passende Datenbanksystem zu verwenden. Dies wird auch als »polyglot persistence architecture« bezeichnet, also als eine Architektur der polyglotten Beständigkeit.

Das Datenmonster bändigen

Mit dem Microservices-Modell lässt sich das Datenmonster eines Unternehmens bändigen, vorausgesetzt drei wichtige Schritte werden umgesetzt:

  • Jetzt handeln! Steht die Implementierung einer neuen Funktion an, sollte der neue Code gleich als eigenständiger Microservice realisiert werden, statt ihn erneut für den Monolithen zu erstellen.
  • Trennung muss sein! Bei den meisten monolithischen Anwendungen gibt es eine klare Trennung zwischen der äußeren Präsentation (Benutzerschnittstelle/ Front End) einerseits und den internen, firmenseitigen Datenzugriffen andererseits (Back End). Beide sind meist über eine API-Schnittstelle verbunden. Durch die Aufteilung der Anwendung entlang dieser Schnittstelle erhält man zwei kleinere Anwendungen.
  • Schritt für Schritt: Module werden zu eigenständigen Microservices. Bei jeder Herauslösung und Umwandlung eines Moduls in einen Dienst wird der Monolith kleiner. Sobald ausreichend Module in Microservices umgewandelt wurden, stellt der Monolith kein Problem mehr dar.

Microservices sind natürlich nicht perfekt und sie sind auch kein Allheilmittel gegen alle Sorgen eines Unternehmens bezüglich seiner Anwendungen. Sie können Unternehmen jedoch sehr wohl dabei unterstützen, geschäftliche und informationstechnische Bedürfnisse besser aufeinander abzustimmen.

Chris Stetson, Chief Architect of Microservices Engineering bei NGINX

 


 

Hier folgt eine Auswahl an Fachbeiträgen, Studien, Stories und Statistiken die zu diesem Thema passen. Geben Sie in der »Artikelsuche…« rechts oben Ihre Suchbegriffe ein und lassen sich überraschen, welche weiteren Treffer Sie auf unserer Webseite finden.

 

Mittelstand agiert bei Microservices und Containern zu unentschlossen

Wissen und Informationen optimal nutzen – Die 5 Faktoren erfolgreicher Technologieentwicklung

CIOs brauchen eine ereigniszentrierte Strategie für das Digital Business

Fünf Merkmale zukunftssicherer Cloud-Architekturen

Zukunft, Digitalisierung und Erfolg: 69 Prozent der befragten KMU blicken positiv in die Zukunft

Bimodale IT: Fünf Schritte auf dem Weg zu einer zukunftsfähigen IT

Prognose für die Anwendungsintegration im Jahr 2017

Weitere Artikel zu