Microservices fördern die Modernisierung Best Practices beim Schwenk auf Microservices

Als zentraler Faktor für den Geschäftserfolg muss die IT eine hohe Flexibilität bieten. Der Einsatz von Microservices und Container-Technologie spielt bei der zügigen Umsetzung neuer Ideen eine entscheidende Rolle.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Confluent Germany GmbH

Windhoff Group

ConSol Consulting & Solutions Software GmbH

Wie bei anderen IT-Trends folgt die Entwicklung bei den Microservices einer typischen Hype-Kurve: von der Euphorie über die Ernüchterung hin zum Pragmatismus. Allzu begeisterte und manchmal auch unbedarfte Herangehensweisen haben in der Praxis teils skurrile Blüten getrieben.

Nicht selten wurde beispielsweise der Anspruch „Micro“ sehr strikt interpretiert. Es entstand ein regelrechter Wettbewerb um die kleinste funktionale Einheit, die in einem Service isoliert werden kann. In anderen Fällen verantworteten siebenköpfige Scrum-Teams plötzlich 50 Microservice-Projekte. Sie waren somit personell gar nicht in der Lage, einen Kernvorteil dieser Architektur auszunutzen – nämlich, dass jedes Projekt unabhängig von allen anderen weiterentwickelt werden kann.

Pragmatismus statt buchstabengetreuer Umsetzung

Die Lektion aus diesen Entwicklungen: Statt den Code der reinen Lehre zufolge und ohne Berücksichtigung des Kontextes zu zergliedern, sollte „Right-Sizing“ das Motto sein. Wenn die Segregation von Funktionalitäten in mehrere Services einen Softwarearchitekten vermeintlich dazu zwingt, etablierte Lösungen wie eine Datenbankplattform in Frage zu stellen, dann ist das sehr wahrscheinlich keine gute Idee.

Im Mittelpunkt sollte also nicht zwingend der Anspruch stehen, dass das Endergebnis dem Domain Driven Design folgend „korrekt“ aussieht. Wichtiger als die Reinheit der Domäne eines Dienstes sind am Ende eher praktische Eigenschaften wie schneller Start/Shutdown, Statuslosigkeit und der problemlose Betrieb auf Container-Plattformen, also klassische Tugenden der „12-Faktor-App“.

In verteilten Systemen neue Konzepte zur Datenkonsistenz und -aggregation – etwa Event Sourcing und CQRS (Command Query Responsibility Segregation) – zusammen mit Microservices zu verwenden, klingt vielversprechend, ist aber auch sehr ambitioniert. Dennoch wurden sie in einigen Fällen zu leichtfertig eingesetzt.

Am Ende entstand ein hochkomplexes System, das erhebliche administrative Aufmerksamkeit und Know-how erfordert, für das sich dann aber niemand wirklich verantwortlich fühlte. Entsprechende Pläne und die Auswirkungen, die sich aus dem Einsatz dieser Systeme ergeben, sollten früh kommuniziert und gegebenenfalls auf den Einsatz verzichtet werden.

Unter Architekturaspekten empfiehlt es sich, eine evolutionäre statt einer revolutionären Transition existierender Applikationslandschaften zu betreiben: Ein funktionierender Anwendungs-Monolith wird nicht in einem Schritt dekonstruiert. Vielmehr werden nacheinander einzelne, leicht isolierbare, funktionale Domänen ausgegliedert und in separate Microservice-Projekte ausgelagert.

Das gibt allen Beteiligten zum einen die Möglichkeit, sich sowohl technisch als auch kulturell an das neue Modell zu gewöhnen. Zum anderen hilft es dabei, ein klareres Bild von den Herausforderungen zu entwickeln, bevor die „großen Aufgaben“ angepackt werden.

Microservices und Programmiersprachen

Aktuell verbreitet sich Googles neue Programmiersprache „Go“ sehr rasch im Microservices-Umfeld. Entwickler schätzen an Go die Gradlinigkeit bei der Umsetzung gängiger, nicht allzu komplexer Use-Cases – beispielsweise Web Services mit Datenbank-Backend – und die hohe Performance. Im Zusammenspiel mit dem hochoptimierten Kommunikations-Framework gRPC ist Go eine prädestinierte Lösung für sehr stark frequentierte Web Services, bei denen massive Skalierbarkeit erforderlich ist.

Aber auch Java- und andere JVM-basierte Sprachen spielen eine wichtige Rolle; unter den Frameworks sind Spring Boot und Java EE die Spitzenreiter. Funktionale Plattformen wie AWS Lambda oder Google Cloud Functions sind im Kommen und stoßen auf großes Interesse. Sie müssen aber noch zeigen, ob sie für den Mainstream der Anwendungsfälle das Werkzeug der Wahl sind oder ob sie eine Nischenlösung bleiben.

Container-Plattformen für den Betrieb von Microservices

Eine Reihe von Entwicklerteams haben mit dem Aufkommen von Docker vor ein paar Jahren bereits viel Energie und Know-how in den Aufbau eigener Plattformen für den containerisierten Betrieb und das Testing investiert. Nun aber etabliert sich eine neue Generation von integrierten Lösungen für das Container-Clustering wie Google Kubernetes, Red Hat OpenShift Container Platform oder Docker Datacenter, die gerade hinsichtlich einfachen Betriebs und funktionalen Umfangs punkten.

Bei den Pionieren ist die Bereitschaft aktuell natürlich gering, die eigenen Lösungen nun wieder zu ersetzen. Nach dem betriebenen Aufwand sind die Prozesse vielleicht gerade erst wirklich etabliert und man identifiziert sich natürlich auch mit der eigenen Herangehensweise.

Diese „Early Adoption“ könnte sich nun folglich als Hemmschuh herausstellen, da sich die neuen Plattformen, zumindest nach Meinung des Autors, den Eigenbau-Lösungen in Hinsicht Flexibilität und Zukunftssicherheit als überlegen herausstellen könnten. Wer also bislang noch nicht auf den Container-Zug aufgesprungen ist, könnte nun bei der Umstellung seiner Infrastruktur so etwas wie die „Gnade der späten Geburt“ erleben und direkt auf eine der gereiften Lösungen der neuen Generation setzen.

Ein Aspekt, der Betreibern von Container-Plattformen teilweise Kopfzerbrechen bereitet, ist die Kontrolle der deployten Systeme hinsichtlich ihrer Sicherheit – insbesondere wegen der Geschwindigkeit, mit der neue, sehr heterogene Apps aus dem Boden schießen können. Man fürchtet einen allzu ausufernden Wildwuchs von Systemen mit einer unübersehbaren Anzahl aktiver Komponenten in diversen Versionen.

Tatsächlich muss sich hier aber erst noch zeigen, wie sensibel das Thema tatsächlich ist, oder ob der partielle Kontrollverlust beziehungsweise die Verlagerung der Verantwortung zum Projektteam nicht notwendige Übel sind. Red Hat bietet hier mit der auf einheitlichen Basis-Images aufbauenden „s2i“-Strategie eine potenzielle Lösung.

Darüber hinaus existiert eine gewisse Unsicherheit, ab welcher Unternehmensgröße es sich lohnt, eine Container-Plattform „on-premises“ selbst zu betreiben oder ob es nicht oft besser wäre, eines der Angebote von großen Cloud-Providern wie Amazon AWS, Microsoft Azure oder Google Cloud zu nutzen. Einigen Firmen erscheinen letztere Lösungen zunächst einmal als teuer, dafür sparen sie sich einen Großteil des administrativen Aufwandes und als Bonus können sie gefühlt „grenzenlos“ skalieren, auch wenn dies die wenigsten wohl jemals benötigen.

Oliver Weise

Gerade in Deutschland spielt aber auch der Datenschutz eine zentrale Rolle, der bei US-amerikanischen Cloud-Anbietern aufgrund herrschender Gesetzgebung und gemessen an den hiesigen Anforderungen zumindest mit einem Fragezeichen zu versehen ist. Potenzielle Alternativen: Microsofts „Azure Deutschland“, das von T-Systems als deutschem Datentreuhänder kontrolliert wird, oder dem auf Red Hat OpenShift Container Platform basierten „AppAgile“-Angebot, ebenfalls von T-Systems, das deutschem Recht unterliegt.

* Oliver Weise ist Development-Teamleiter bei Consol Software in München.

(ID:45141103)