Microservices – spielen mit Bauklötzen?

Der Begriff Microservices ist für Entscheider ausserhalb der IT-Abteilungen oftmals nicht mehr als ein Buzzword oder bestenfalls ein modernes Schlagwort in der Softwarearchitektur. Dabei sind es häufig die bestehenden Systeme, die die IT-Kosten durch Wartung und Fehlerbehebungen hochtreiben und den Ertrag senken. Hiess es früher noch "never change a running system", lohnt es sich heute, genauer hinzuschauen, ob neue Entwicklungs- und IT-Architektur-Paradigmen die Effizienz der Softwarearchitektur in puncto Betrieb und Weiterentwicklung steigern können.

Klare Zuständigkeiten für grosse Systeme

Mit der digitalen Transformation sind die Erwartungen der Fachbereiche an die IT gestiegen. Die digitale Ökonomie verlangt nach immer schneller und flexibler implementierbaren Anwendungen. Bestehende Systeme werden in sich immer weiter angepasst. Nicht immer gelingt dies reibungslos. Zusätzlich zur Entwicklung sind hohe Aufwände für Bugfixing und in der Folge erneute technische und funktionale Tests nötig. Am Ende testet man sogar die gesamte Applikation – da man nicht weiss, ob es durch den Hotfix zu weiteren, nicht vorhersehbaren Nebeneffekten kommt. Oftmals sind die Verantwortlichen in der IT kürzer dabei als das System in Betrieb. Gerade die Historie und die währenddessen hart verbauten Sonderlösungen sind die gefürchteten technischen Schulden, die auch finanzielle Auswirkungen haben. Die Historie kostet vielfach mehr Geld als die Weiterentwicklung. Und an selbige ist aufgrund der Probleme manchmal gar nicht mehr zu denken.

Diese Situation ist keineswegs überspitzt dargestellt. Viele IT-Abteilungen setzen noch immer auf eine monolithische Softwarearchitektur. Monolithisch deswegen, weil das komplette System einzig für seinen Verwendungszweck in einem grossen, unbeweglichen, komplexen und sperrigen Felsblock entwickelt wurde. Und da stehen sie nun: Das Onlineshop-System, das Filialbestellungssystem, das Lagerverwaltungssystem. Jedes für sich ein Ayers Rock im hauseigenen Rechenzentrum.

"Das System" gibt es nicht mehr

Betrachtet man die einzelnen Use-Cases der Systeme genauer, fallen Redundanzen auf. Der Lagerbestand wird in verschiedenen Prozessen angepasst, eine Filialreservation durch das Onlineshop-System aber auch durch das Tele-Sales-Bestellsystem. Erstrebenswert ist es, diese einzelnen Use-Cases in Module aufzuteilen. Microservices repräsentieren diese Module. Jedes mit einer bestimmten Funktion. Und nur dafür.

Es gibt nicht mehr "das" Shop-System oder "die" Lagerverwaltung. Es gibt einen Baukasten mit einzelnen Softwaremodulen, die nach dem alten EVA-Prinzip (Eingabe – Verarbeitung – Ausgabe) funktionieren. Zustandslos verarbeitet jedes Modul mit seiner Logik die Informationen, die es erhält, und gibt jene aus, die aus seiner implementierten Logik resultieren. Gemerkt wird sich nichts, und wenn, dann in der Datenbank, auf die der Microservice jeweils zugreift. Man wartet auf Input und man gibt Output – dafür aber zuverlässig und ohne Wenn und Aber.

All diese Module werden in skalierbaren Umgebungen, Containern, in der Cloud, gelagert. Jedes Modul kann somit für sich, unabhängig von den anderen Modulen, in Betrieb gesetzt werden. Fehler werden nur im betroffenen Modul entsprechend seiner funktionalen Spezifikation behoben, Modernisierungen nur an den betroffenen Modulen vorgenommen. Funktionen können schnell und flexibel in neuen Anwendungen abgebildet und in das bestehende System über Schnittstellen integriert werden.

Wenn Unternehmen selbst Software entwickeln wollen, stellt sich schnell die Frage nach dem Einsatz von Containern. Doch was bringt die Technologie eigentlich? Antworten von Matthias Stürmer und Oscar Meier von der Forschungsstelle Digitale Nachhaltigkeit der Universität Bern finden Sie hier.

Ganz oder gar nicht? Oder was dazwischen?

Die Entscheidung für eine Microservices-Architektur will gut überlegt sein. Die Einführung einer neuen Softwarearchitektur hat früher oder später Auswirkungen auf die gesamte IT-Infrastruktur. Möchte man von dem Vorteil der Wiederverwendbarkeit durch die Zentralisierung einzelner Funktionen profitieren, müsste auch jede funktionsnutzende Anwendung in der IT-Architektur auf das neue Paradigma umgestellt werden.

Jeder externe Softwaredienstleister müsste sich zu der neuen Art, Funktionen zu implementieren, bekennen. Neben den Kosten lauert hier noch die Gefahr der unterschiedlichen Programmiersprachen, der eingesetzten Entwicklungstechnologien, die die verschiedenen Dienstleister eventuell mitbringen.

Die interne IT ist nicht mehr systemverantwortlich, sondern sie muss den Baukasten der Module, sprich den Katalog der einzelnen Microservices, deren genaue Spezifikation und Zusammensetzung zur Realisierung der diversen Geschäftsanwendungen, kennen. Bei Standardsoftware, die häufig eine monolithische Struktur hat, ist die Entkopplung schwierig. Einzelne Komponenten werden somit erstmal Monolithen bleiben. Die Kunst ist es, Standardsoftware an den richtigen (Schnitt-)Stellen mit den Modulen interagieren zu lassen. Idealerweise bleibt die Standardsoftware in ihrem ursprünglichen "Werkszustand" erhalten und kann somit ohne grosse Aufwendungen ebenso ausgetauscht beziehungsweise aktualisiert werden.

Augen zu und durch?

"Dass die IT-Kosten mit der Digitalisierung steigen, ist unumkehrbar. Also jetzt lieber einmal tiefer in die Tasche greifen und sich von der Last der Granitgebilde befreien und in eine bunte Lego-IT-Welt eintauchen, wo wir unsere Ideen direkt im Workshop zu funktionierender Software zusammenstecken können."

Der Einsatz von Microservices hat ausser den initialen Kosten auch einen unvermeidlichen Impact auf die Betriebskosten. Microservices müssen sich auf eine Sprache für den Datenaustausch einigen. Bei Microservices können die einzelnen Informationen nicht, wie bei Methoden in objektorientierten Programmiersprachen, publik gemacht werden: Der komplette Output eines Microservices muss durch ihn selbst in ein zusammenhängendes Dokument geschrieben, per Netzwerk übertragen und so auch vom empfangengen Modul verstanden werden. Dies bedeutet zusätzliche technische Ressourcen (für z.B. Rechenzeit und Kommunikation). Externe Cloud-Infrastrukturen sind jedoch um ein Vielfaches günstiger als im eigenen Hause gehostete Hardware. Diesen Luxus erlauben sich nämlich heute noch mehr Unternehmen, als man denkt.

Ziel ist es, Microservices ressourcenschonend und trotzdem wiederverwendbar und evolutionsfähig statt mikroskopisch klein zu entwickeln. Wichtige Richtlinie: Microservices müssen von ihrem Erbauer und auch von dessen Nachfolger verstanden werden.

Ausserdem muss trotz aller Modularität darauf geachtet werden, dass die Orchestrierung der Microservices im tieferen Back-End, zum Beispiel bei Datenbankzugriffen, gelingt. Jede Datenquelle hat ihren bedienenden Microservice. Jeder andere Microservice muss über genau diesen Mitspieler die Daten beziehen. Positiv ist, dass übergreifende Integrationsdatenbanken damit zusehends obsolet werden.

Auch beim Testing sind Microservices nicht zu unterschätzen. Zwar suggeriert die Modularität einen geringeren Testaufwand, jedoch muss, je nach Kritikalität des jeweiligen Microservices, bei Fehlerbehebungen oder Weiterentwicklungen mehr oder weniger die gesamte Applikation getestet werden. Gut beraten ist, wer mit weitestgehend automatisierten Tests arbeitet. Dabei ist jedoch durch die Granularität ein höherer initialer Aufwand bei der Testfall-Definition zu erwarten.

Neue Organisation

Microservices sind nicht einfach nur ein neues IT-Gespinst. Sie sind oftmals der Beginn einer infrastrukturellen und organisatorischen Veränderung in der Zusammenarbeit von IT und Fachabteilungen. Business-Owner können sich fortan voll auf den Sinn und Zweck der Anwendungen, die Erhebung und Priorisierung der fachlichen Anforderungen, fokussieren.

Die IT hingegen kann sich auf die anforderungsgemässe Zusammenstellung der Microservices konzentrieren. Die Cloud-Infrastruktur sorgt für eine Zu- oder Wegschaltung von Ressourcen – je nach aktuellem Bedarf – vollkommen automatisiert und in Echtzeit.

Für die IT wird es aber nicht unbedingt einfacher. Bei Microservices gewinnt lebenslanges Lernen nochmals an Bedeutung. IT-Verantwortliche kümmern sich nicht mehr um einzelne Systeme, die auf einem einheitlichen Technologie-Stack basieren. Vielmehr ist bei Microservices eine nach Themen geordnete Zuteilung der IT-Verantwortungen sinnvoll. Es gibt die IT-Verantwortung für die Logistikmodule und solche für die Microservices im Order-Management. IT-Mitarbeiter werden also wieder vermehrt zu Beratern, die die Funktion und ihren Sinn und Zweck viel tiefer verstehen als einfache Systemadministratoren. Dies aber mit dem Umstand, dass unterschiedliche Programmiertechnologien von einer IT-Verantwortlichkeit betrieben werden müssen.

Gleichzeitig braucht es Konzertmeister, die das Monitoring und den Betrieb der Kommunikation zwischen den Microservices sicherstellen und auch die Sicherheit der Kommunikation im Blick haben. Microservices unterhalten sich über Netzwerkprotokolle wie etwa HTTP oder HTTPS, die erfahrungsgemäss anfällig für Angriffe sind. IT-Ressourcen werden also nicht reduziert, sondern müssen an neue Themen herangeführt werden.

Fazit

Microservices fördern durch ihre Modularität in Aufbau und Interaktion die Agilität bei der Weiterentwicklung der einzelnen Anwendungen und verkürzen die Time2run für eine neue Anwendung. Einzelne Funktionen können fortan sehr viel schneller modernisiert oder implementiert werden.

Auf der anderen Seite sind mehr technische und personelle Ressourcen notwendig. Dafür können Einsparungen beim Support und der Fehlerbehebung zusätzliche Ressourcen freisetzen. Know-how-Aufbau, Arbeitsweise und Organisation sind ebenfalls kritische Erfolgsfaktoren, welche die Einführung einer neuen IT-Infrastruktur beeinflussen.

Der Einsatz von Webservices ist zudem abwägend zu beurteilen. Wird kein Nutzen aus Vorteilen wie Wiederverwendung, Flexibilität und Komplexitätsreduktion gezogen, dann kann etwa bei kleineren Anwendungen und Projekten weiterhin eine Monolith-first-Strategie die sinnvollere Alternative sein. Dort, wo Unternehmen auf geänderte Kundenbedürfnisse und Marktveränderungen schnell reagieren müssen, kann der Einsatz von Microservices einen signifikanten Wettbewerbsvorteil bieten.