Ergebnis

Digitalisierungsprojekte profitieren besonders

Der Architekturstil Microservices ist auf dem Sprung in den Mainstream. Viele Anwenderunternehmen haben entdeckt, dass sich Microservices besonders für die Entwicklung von Services in Bereichen der Digitalisierung, für Endkundenservices und für neue Funktionen an der Peripherie traditioneller monolithischer Applikationen eignen. Bisher kommt kein anderer Architekturstil den Bedürfnissen von DevOps-Liefermodellen und Cloud-Applikationen so stark entgegen wie Microservices.

Mit ihm lassen sich einzelne Funktionen sehr schnell durch verteilte Teams realisieren und ändern. Voraussetzung für den effizienten Einsatz dieses Stils, der vor allem innerhalb von Applikationen zum Tragen kommt, nicht so sehr auf Enterprise-Ebene, ist allerdings eine „äußere Architektur“, die die vielen Möglichkeiten der Realisierung mit Leitplanken versieht, die den effizienten Einsatz von Microservices im Unternehmen sicherstellen.

Der Workstream „Microservices“ empfiehlt, das moderne Architecture Pattern bei Projekten mit folgenden Qualitätsanforderungen einzusetzen:

• bei hohem Skalierungsbedarf,
• wenn einzelne Bestandteile leicht veränderbar sein sollen,
• bei hohem Bedarf an Plattformunabhängigkeit,
• wenn Funktionen leicht austauschbar sein sollen.

Workstreamleiter Hischam Abul Ola warnt davor, Microservices ohne guten Grund einzusetzen. „Der Einsatz dieses Architekturstils ist deutlich aufwendiger, deshalb sollten nur Anwendungen so gestaltet werden, bei denen das nötig ist. Wenn keines der vier genannten Qualitätsattribute relevant ist, sollte man mit der Entwicklung einer monolithischen Anwendung anfangen.“

Die bisherigen Ergebnisse des Workstreams zeigen, dass vor allem digitalisierungs- und endkundenorientierte Projekte stark von Microservices profitieren können. „Microservices lassen deutlich mehr technologische Freiheiten bei der Realisierung einzelner Funktionen zu. Da sie außerdem leicht änderbar und austauschbar sind eignen sie sich hervorragend, um verschiedene Möglichkeiten auszuprobieren“, erläutert Abul Ola.

Die hohe Skalierbarkeit macht den Stil besonders für Projekte attraktiv, deren Funktionen zu verschiedenen Zeiten unterschiedlich stark genutzt werden. „Unser Car-Kofigurator zum Beispiel wird stark zwischen 17:00 Uhr und 22:00 Uhr genutzt, während des restlichen Tages ist die Nutzung dagegen normal. Eine granulare Skalierbarkeit hilft uns dabei, die Nutzung zu den Peak-Zeiten abzufedern“, berichtet Abul Ola aus dem eigenen Konzern.

Digitalisierungsprojekte profitieren stark von Microservices. Weil in der jungen Disziplin „Digitalisierung“ noch viel getestet werden muss und sich wenige Best Practices etabliert haben, sind die hohe technische Flexibilität und die unterschiedlichen Realisierungsmöglichkeiten für einen Microservice ein sehr starkes Argument. „Gerade, wenn noch nicht hundertprozentig klar ist, wohin letztlich die Reise geht, muss man unterwegs Änderungen vornehmen können, die nicht zu aufwendig sind und die Projekte nicht gefährden“, so Abul Ola.

Allerdings stellt die hohe Zahl der Realisierungsmöglichkeiten für die kleinen, unabhängig voneinander deploybaren Komponenten auf Enterprise-Ebene auch ein Problem dar. Wenn jedes DevOps-Team seine Microservices ausschließlich auf die eigenen Projekte ausrichtet, entsteht ein Neben- und Durcheinander verschiedener übergeordneter Funktionen. Zum Beispiel würde jede Projektgruppe ein eigenes Logsystem entwickeln, mit dem sie Fehler in ihren Microservices protokolliert, auswertet und schließlich behebt. 

Deshalb brauchen Microservices neben ihrer „inneren Architektur“, um die sich die jeweiligen Solution-Architekten in den Teams kümmern, eine „äußere Architektur“, die die Lücken zwischen den verschiedenen in Microservices realisierten Applikationen und Systemen adressiert. Da geht es laut Abul Ola um Themen wie Kommunikation, Transaktionen, Betriebsaspekte und natürlich Sicherheit.„Wir entwickeln im Workstream diese äußere Architektur, damit nicht jedes Team das Rad neu erfindet und im Endeffekt die Effizienz der Microservice-Architektur ad absurdum führt“, erläutert Abul Ola.

Diese „äußere Architektur“ wird ein produktunabhängiger aber hinreichend konkreter Leitfaden sein, an dem sich Unternehmen orientieren können. Über diesen Leitfaden hinaus liefert der Workstream eine klare Definition von Microservices, grenzt den Architekturstil gegen SOA ab, klärt die besten Einsatzbereiche für Microservices und entwickelt Integrationsszenarien.