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.
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.
"Eventual Target Architecture"
Aus Sicht des Managements solcher Architekturen gibt es keine "Top-Down"-Regeln oder Fachklassen, sondern die Fähigkeit eines Unternehmens, trotz Vielfalt eine Konvergenz zur Zielarchitektur herzustellen. Eine Zielarchitektur wird nicht durch eine "Top-Down"-Generierung vorgeschrieben. Zu Zeiten von SOA konnten sich Unternehmen noch zahlreiche Mitarbeiter leisten, die auf Powerpoint-Niveau Services entworfen haben. In der gleichen Zeit entstehen heute bei Unternehmen wie Amazon oder Zalando ganze Microservices und APIs, die in der Produktion genutzt werden. Heute sind Mitarbeiter gefragt, die sich anstatt mit theoretischen Definitionsfragen zu beschäftigen, Lösungen für die komplexen Herausforderungen von verteilten Systemen überlegen.
Mit dem Conveys Law kommt eine ganz neue Art, sich zu organisieren zum Einsatz. Ein IT-System und auch eine IT-Landschaft folgen in der Struktur der Organisationsform. Eine hierarchische Organisationsstruktur wird der föderierten Arbeitsweise von agilen Teams nicht gerecht. Hier lohnt sich ein Blick auf das von Zalando eingeführte Konzept der "Radical Agility", welches Eckpfeiler wie Autonomy sowie Mastery & Purpose für die Organisation definiert. Zusätzlich werden Führungspersonen klar in organisatorische und inhaltliche Führungstypen eingeteilt. Dies soll vermeiden, dass womöglich die besten Programmierer zu schlechten Führungspersönlichkeiten werden.
Entwicklung von Applikationen: Dank Docker entstehen ganz neue Ökosysteme
Demnach entspricht eine Microservices-Architektur in ihren Prinzipien exakt der einer SOA. Der eigentliche Innovationsgrad - um nicht zu sagen Paradigmenwechsel - liegt jedoch in der Fähigkeit, ein solches Konzept in die Praxis zu überführen. Das lässt sich unter anderem auch daran erkennen, dass Containertechnologien, wie beispielsweise Docker, das Thema Virtualisierung auf eine ganz neue Ebene heben. Rainer Janßens Frage, ob Virtual Server und Virtual Desktop nichts Anderes bedeuten, als die Rückkehr zum ordentlichen Mainframebetrieb, ist durchaus berechtigt und drängt sich gerade zu auf. Doch auch hier kommt es darauf an, wie man es betrachtet. Mit Docker entsteht ein ganz neues Ökosystem für die Entwicklung von Applikationen. Zwar beruht dies auch im Kern nur auf Virtualisierung, doch kleine, feine Charakteristika machen hier den Unterschied. Zum einen ändert sich der Ressourcenverbrauch. Ohne weiteres kann anstatt einer virtuellen Maschine eine Vielzahl von Docker Containern gestartet werden, die im Bruchteil von Sekunden verfügbar sind. Und zum anderen gibt es auch für Virtualisierung das Konzept von vorkonfigurierten Images, die dann für die eigenen Einsatz-Zwecke genutzt werden können. Erst durch den feingranularen Schnitt sowie Docker-Images und einer einfach zu nutzenden Registry können sich Entwickler in Sekundenbruchteilen ihre Infrastruktur zusammenstellen, für die sie früher stundenlange Setups benötigt hätten.
Bewahren Sie Ruhe!
Welchem Image kann ich vertrauen? Wie betreibe ich ein effektives Monitoring und Fehlermanagement in einer hochgradig dynamischen Infrastruktur? Alles Fragen, mit denen sich das Management heutzutage konfrontiert sieht. Auch hier zeigt sich, dass die Konzepte denkbar ähnlich sind, allerding kleinste Details ausschlaggebend sein können und über Erfolg oder Misserfolg entscheiden. Das Konzept von Microservices ist mittlerweile nicht mehr neu, umso erstaunlicher ist es, dass viele Unternehmen bislang nicht darauf umgestiegen sind. Denn für diese, die Microservices einsetzen, ist dieses Modell alternativlos, da die Vorteile überwiegen.
Umfragen zeigen jedoch, dass bereits im ersten Halbjahr 2017 deutlich mehr Unternehmen den Schritt hin zu MSA wagen werden. Und je mehr Unternehmen mit und an Microservices arbeiten, desto wahrscheinlicher ist es, dass auch neue Modelle entwickelt werden. Und wenn dies soweit ist, halten Sie es wie Herr Janßen: "Wenn Ihnen also demnächst ein Berater erklärt, dass sich die Paradigmen in der IT ändern, reagieren Sie entspannt." Der Vielzahl der Veränderungen mit Hektik zu begegnen, wäre sicher der falsche Schritt. Hingegen mit kühlem Kopf und Mut die eigene Organisation so aufzustellen, dass Sie das Optimum aus den neuen Möglichkeiten herausholen kann, wäre sicher ein guter Start.