Enterprise Architecture Management

Microservices: SOA reloaded?

23.02.2017
Von 


Der Wirtschaftsinformatiker André Christ ist CEO und Mitgründer von LeanIX. Das Unternehmen ist auf Enterprise Architecture Management (EAM), SaaS Management und Value Stream Management spezialisiert.
Microservices sind nicht neu und galten zunächst als "SOA reloaded". Doch was hat sich wirklich in den vergangenen Jahren getan?

In der heutigen Zeit der digitalen Transformation ist Software eine essenzielle Kernkomponente aller Produkte geworden. Die Geschwindigkeit, mit der Softwaresysteme von Unternehmen ausgetauscht werden, nimmt stetig zu. Der Einfluss der IT-Entscheider und vor allem der IT-Architektur auf den Erfolg des Unternehmens war nie größer. Besonders deutlich wird dies an der Entwicklung der Service Oriented Architecture - kurz SOA - woraus die Microservices-Architecture (MSA) hervorging.

Auf den ersten Blick sind eine Microservices Architecture und eine SOA sehr ähnlich, doch im Detail sind signifikante Unterscheide zu erkennen und diese erfordern einen Wechsel der Management-Prinzipien.
Auf den ersten Blick sind eine Microservices Architecture und eine SOA sehr ähnlich, doch im Detail sind signifikante Unterscheide zu erkennen und diese erfordern einen Wechsel der Management-Prinzipien.
Foto: oatawa - shutterstock.com

Bei dieser Geschwindigkeit der Änderungen ist eines ganz besonders wichtig: Ruhe bewahren. Halten Sie es wie Rainer Janßen, ehemaliger CIO der Munich RE, der in seinem Artikel "SOA = Same Old Architecture" schon vor knapp fünf Jahren den guten Rat gab: "Reagieren Sie entspannt." Dennoch lohnt es sich, das Thema "Microservices vs. SOA" noch einmal genauer unter die Lupe zu nehmen, um zu sehen, was sich in den vergangenen Jahren verändert und weiterentwickelt hat. Denn hochdigitalisierte Unternehmen wie Amazon oder Netflix beweisen, dass sie dank Micro-Services ihre Geschäfte skalierbar und innovativ gestalten konnten.

Die kleinen, gekapselten Software-Stücke, die von sogenannten "Two-Pizza-Teams", die aus sechs bis acht Personen bestehen, entwickelt werden, erlauben es den Unternehmen, den Produktentwicklungszyklus drastisch zu verkürzen, Feedback zu sammeln und zu verbessern. Diese Fähigkeit, neue Produktschritte schnell liefern und eine agile Produktentwicklung durchführen zu können, ermöglicht die konsequente Umsetzung von Geschäftsmodellen in den heutigen dynamischen Märkten. So konnte aus Amazon, dem einstigen Online-Buchladen, der größte IT-Cloud-Anbieter der Welt werden und Netflix konnte sich vom DVD-Verleih zu einer TV-Produktion und einem Streaming-Unternehmen entwickeln.

Service Oriented Architecture: Die Theorieschlacht mit Millionen von Datenpunkten

Auf den ersten Blick sind eine MSA und eine SOA sehr ähnlich, doch im Detail sind signifikante Unterscheide zu erkennen und diese erfordern letztendlich einen Wechsel der Management-Prinzipien. Doch der Reihe nach: Was macht eine SOA eigentlich aus? Sie strukturiert fachliche Anforderungen in Fähigkeiten, definiert Services entlang von fachlichen Datenobjekten und ermöglicht lose Abhängigkeiten. Und das in einer möglichst flexiblen Kombination mit einer hohen Wiederverwendung. "Was hat sich denn an der Strukturierungsaufgabe für fachliche Anforderungen grundsätzlich Neues ergeben?", fragt Rainer Janßen in seinem Artikel. Aus meiner Sicht ist es ein kompletter Wechsel von einem "Top-Down-Theoriemodell" zu der Anwendung von "Bottom-Up-Best Practices".

Für die Einführung einer SOA wurden nicht selten über viele Monate in einem großen Kraftakt Domänenmodelle entwickelt, an denen solange gefeilt wurde, bis tausende Domänen auf ein halbes Dutzend Ebenen beschrieben werden konnten. Manch einer wird sich noch an die zahlreichen Workshops und Steering Committees erinnern, die beweisen sollten, dass die Domäne "Abrechnung" im jeweiligen Unternehmen nun zur Domäne "Vertrieb" gehört und damit abgetrennt ist von der Domäne "Buchhaltung", die wiederrum zur Domäne "Finanzen" gehört. Ein immenser theoretischer Kraftakt mit fragwürdigem Return on Invest. Das Ziel, sämtliche Applikationen eines Unternehmens mit diesem Modell darzustellen und daraus wiederum den richtigen Schnitt der Services abzuleiten, kommt einer Herkulesaufgabe gleich: Bei einem Unternehmen mit rund 500 eingesetzten Applikationen führt dieser Ansatz nicht selten zu einer Matrix mit mehr als einer Million manuell auszuführender Datenpunkte.

Von unten nach oben: Microservices Architecture ermöglichen intuitive Benutzbarkeit

Während eine SOA meist vom CIO verordnet wurde und somit die schon erwähnte "Top-Down-Entwicklung" war, so ist es bei Microservices genau umgekehrt. Das liegt vor allem an innovativen Open-Source-Softwareprojekten und Plattformen, die dank offener REST APIs einfache Wege der Integration geschaffen haben. Eine REST-Schnittstelle stellt die intuitive Benutzbarkeit durch einen Entwickler in den Vordergrund, beispielsweise durch Charakteristiken wie "Konvention vor Konfiguration". Da REST APIs eben nicht durch ein kopflastiges Design am Reißbrett entstanden sind, sind nicht alle zueinander konsistent, doch aufgrund ihrer Struktur sind sie für den geübten Programmierer dafür schnell zu verstehen. Während die in einer SOA üblichen Service-Beschreibungen via WSDL und Übertragungsprotokollen auf einer XML-Basis aufgrund ihrer Komplexität für Entwickler abschreckend waren, haben die JSON-basierten Spezifikationen gerade auch bei Webdevelopern eine schnelle Lernkurve ermöglicht.

Nicht etwa ein Zusammenschluss von großen Konzernen, wie das W3C, haben eine Spezifikation von REST APIs vom Himmel fallen lassen, sondern hierbei handelt es sich um eine erfreuliche Bottom-Up-Entwicklung, wie das Beispiel "Swagger" zeigt. Aus einem Hobby-Projekt einer Web-Firma entwickelt sich gerade ein De-Facto-Standard für die Dokumentation von APIs. Das liegt vor allem daran, weil eine automatische Generierung von SDKs genauso möglich ist, wie eine automatisch generierte Dokumentation, die es erlaubt REST-APIs direkt aufzurufen. Natürlich war das zuvor auch schon theoretisch mit WSDL möglich, doch erst jetzt kann es erfolgreich implementiert werden, weil nicht der Zwang der Standardisierung und Harmonisierung im Vordergrund stand, sondern die möglichst breite Nutzbarkeit in zahlreichen Programmiersprachen und Frameworks.

In der SOA-Welt setzt sich der "von oben nach unten"-Gedanke auch in der Idee fort, sämtliche Webservice-Interfaces und Programmcode-Vorlagen direkt aus den sogenannten Fachklassen - gemäß dem Model Driven Design - zu generieren, damit möglichst alle Interfaces "gleich" sind. Ein Ansatz, der eine Sackgasse ist. In modernen Unternehmen lässt sich durch ein Korsett und Zwang keine Innovation hervorbringen. Die erfolgreiche Umsetzung einer flexiblen und robusten Architektur darf nicht von einem möglichst hohen Standardisierungsgrad abhängen. Unternehmen bleiben nur dann für Talente attraktiv, wenn sich moderne Programmiersprachen und Frameworks in bestehende Architekturen integrieren lassen.

Ein weiterer Faktor, der den Erfolg von Microservices begünstigt, ist die Tatsache, dass heutzutage Netzwerkverbindungen mit mehr Bandbreite zur Verfügung stehen und die Latenz gesunken ist. Dies begünstigt es erstmals, auch hochperformate Systeme in ihre Einzelteile zu zerlegen, die in ihrem Backend, wie beispielsweise bei Netflix, auf hunderte einzelne Microservices zugreifen.