Blog Überlegungen zu Microservices -- eine Polemik

Überlegungen zu Microservices -- eine Polemik

Bei zwei Tagen auf der JavaLand 2016 kommt man nicht umhin, sich intensiv mit dem Thema Microservices zu beschäftigen. Passenderweise eröffnet @andreasevers seinen Vortrag mit dem an Pulp Fiction angelehnten "Say Microservices one more time. I dare you" Meme. Das passt, das ist das vorherrschende Gefühl am Ende des zweiten Konferenztages.

Insgesamt bleibt für mich ein zwiespältiges Bild zurück: Interesse und Begeisterung sind nicht von der Hand zu weisen. Wenn man ein paar Jahre Erfahrung im Umfeld von Konzernen mitbringt, leuchten die Vorteile von Microservices sofort ein. Ich kann das alles gut nachvollziehen, habe ich doch selbst erlebt, wie eine ursprünglich schlank und rank konzipierte Web-Anwendung an ihrem eigenen Erfolg zugrunde geht. Zuerst springen immer mehr Abteilungen auf den erfolgsversprechenden Zug auf, die Anwendung suhlt sich im eigenen Erfolg und die Entwickler werden im Unternehmen hofiert. Doch die Architektur war nie für die Breite ausgelegt, in die das System nun getragen wird. Nach ein paar Jahren wird das Gebilde immer fetter, größer und schwerfälliger. Die notwendigen Refactorings und eine Neuausrichtung sind dem Management nicht zu vermitteln und bleiben letztendlich auf der Strecke. Irgendwann schaut man auf sein Projekt und kann nicht anders als festzustellen, dass hier die nächste Legacy-Anwendung herangewachsen ist. Trotz bester Absichten und Vorstellungen ist ein Monolith entstanden, der sowohl in Hinblick auf die Weiterentwicklung als auch auf den Betrieb die Agilität eines Flugzeugträgers hat.

Da erscheinen die Verheißungen von Microservices wie ein rettendes Ufer. Wenn schon nicht für das oben beschriebene System, dann wenigstens für das nächste System, dessen Entwicklung unmittelbar bevorsteht.

Und so entstehen während der Vorträge auf der Konferenz vor dem inneren Auge schon die Ideen, welche Module, welche "Self Contained Systems" das neue System umfassen soll. Vielleicht erahnt man auch schon, mit welchen Kolleginnen und Kollegen aus Entwicklung, den Fachbereichen und dem Betrieb die Zusammenarbeit in einem "Cross Functional Team" möglich und erstrebenswert wäre.

Doch mit ein paar Tagen Abstand schmeckt die appetitlich angerichtete Suppe recht salzig. Inwieweit ist die schöne, neue Microservices-Welt auch tatsächlich im Unternehmen umsetzbar? Es kommen Zweifel auf. Ich möchte hier ein paar der immer wieder zitierten Building Blocks einer Miroservices-Architektur aufgreifen und den Versuch wagen, die Auswirkungen einer Umsetzung im Konzernalltag durchzudeklinieren.

Die Analyse und Aufteilung eines Monolithen in kleine und unabhängig deploybare Services erscheint noch machbar. Das ist wünschenswert und die Vorteile liegen auf der Hand: Isolierte Services, die schnell ausgetauscht werden können, kommen auch den Wünschen der Fachbereiche nach, schnell und unabhängig vom Gesamstsystem z.B. auf Fehlersituationen reagieren zu können. Doch schon hier ist nicht klar, wie sich Continuous Delivery Pipelines in die Change-Prozesse von Konzernen einbinden lassen, besonders wenn die Konzerne im z.B. Finanz- oder Gesundheitsbereich regulatorischer Aufsicht unterliegen. Dort ist das Kontrollbedürfnis sehr stark ausgeprägt; Veränderungen werden eher als Risiko denn als Chance (oder als Notwendigkeit) gesehen. Eine auf kontinuierlichen Wandel ausgelegte Systemarchitektur konterkariert deutlich die Geschäftsprozesse der Unternehmen. Das lässt sich nicht gut miteinander vereinbaren.

Ein weiteres Versprechen der Microservice-Evangelisten ist, dass die Services so kleinteilig geschnitten sind, dass die Entscheidung über die verwendete Technologie in die Verantwortung der Entwicklerteams übergehen kann: Java oder Ruby, node.js oder Go – all das sollen die Teams, die nach dem DevOps Paradigma ja auch für den Betrieb zuständig sind, selbst entscheiden können. Doch lässt sich das mit den zentralistischen Entscheidungswegen in einem Konzern in Einklang bringen? Ist das stets in Grabenkämpfe verwickelte mittlere Management wirklich bereit, seine  abgesteckten Claims derart beschneiden zu lassen? Man muss sich die Situation vor Augen führen, in der ein Teamleiter seinem Abteilungsleiter 0,75 VAK/FTE für einen MySQL Admin abringen möchte, obwohl es doch im Rechenzentrum drei Oracle DBAs gibt, die ganz prima ein Datenbanksystem betreuen können. Zumal das Unternehmen erst im letzten Monat 2,5 Mio Euro für konzernweite Oracle-Lizenzen ausgegeben hat. Das geht sicher nicht im Sinne des Teamleiters aus.

Überhaupt der ganze Bereich Betrieb und Rechenzentrum: Wieweit sollen die Entscheidungsmöglichkeiten über Technologie gehen, wenn es einen sehr fest umrissenen Vertrag mit dem RZ-Dienstleister gibt, an den man den Betrieb ausgelagert hat? Hier überschreiten die Auswirkungen der von Microservices geforderten Organisationsänderungen sogar Unternehmensgrenzen. Wer ist letztlich für den Betrieb verantwortlich? Wer zahlt die Pönale, wenn den Kunden Vermögensschäden entstehen durch einen falsch deployten Service und einen abgestürzten Container? Da kann das Unternehmen nur hoffen, dass der Betreiber des RZ, der nicht mehr für den Betrieb des Microservices verantwortlich ist, die SLAs nicht zu kleinlich auslegt.

Auch eine andere Auswirkung einer durch Microserverices beeinflussten Archikteur lässt sich meiner Meinung nach nicht so einfach umsetzen, wie immer beschrieben: Die Cross Functional Teams, in denen das Know-How gebündelt werden soll. Wer einmal eine Umorganisation in einem Konzern mitgemacht hat, weiß, dass der Aufwand, der hier in die Umschreibung von Stellenbeschreibungen und in die Neuberechnung der Mitarbeiterzahlen zu stecken ist, jedes Vorhaben erlahmen lässt. Von den Aspekten zur Betriebsverfassung und Mitbestimmung einmal ganz abgesehen. Das agile Neuorganisieren von Teams ist hier wohl eher Wunschdenken.

Es ist schon klar, dass ich hier das möglichst pessimistischste, wenn nicht sogar fatalistischste Bild einer Konzernrealität beschreibe. Es ist auch nicht so, dass ich die propagierten Vorteile einer kleinteilig strukturierten Anwendung von der Hand wischen möchte. Doch nach zwei Tagen intensiver Beschäftigung mit Microserverices in Vorträgen hätte ich gerne auch mal einen Beitrag zu dem Thema gehört, der nicht nur die Vorteile hervorhebt, sondern sich ernsthaft auch mit den kritischen Aspekten auseinandersetzt.

Dabei geht es nicht um ein allgemeines Bashing von Microservices: Es ist vor allem um den Hype um dieses Thema und die Intensität, mit der die Consultants ein Thema als Allheilmittel propagieren, statt es als eins von vielen Werkzeugen im Repertoire eines guten Entwicklers zu begreifen.

Daher die ernst gemeinte Aufforderung: Widerlegt meine Bedenken! Ich bin gespannt auf Beispiele, in denen mir die Mitarbeiter eines Konzerns (und nicht die Consultants) zeigen, dass es klappen kann, ein Unternehmen so zu transformieren, dass es den Vorstellungen der Microserverices-Evangelisten entspricht.