… und Nebenwirkungen

Aber auch in anderen Bereichen lauern Herausforderungen. Da wäre zum Beispiel zu klären, wie die Daten zwischen den Services synchron gehalten werden können. Da jeder Service autark arbeiten können muss, verwaltet er auch seine eigenen Daten. Sind diese Daten nun aber im Netz verteilt, kämpft man als Entwickler möglicherweise mit Redundanzen und Inkonsistenzen. Auch bei der Gestaltung der Benutzerschnittstelle und dem Thema, wie die unterschiedlichen Bestandteile des UI in ein Gesamtkonzept eingebunden werden, stellen sich Fragen, die bei einem Monolithen meist schon implizit beantwortet sind. Wo ist das UI abzulegen? Wie wird es zusammengefügt? Wie kann es von unterschiedlichen Teams ohne Reibungsverluste bearbeitet werden? In Bild 3 ist dies gelöst, indem die Dienste von einem Client direkt verwendet werden. Alternativ dazu könnten aber auch die Dienste ihr eigenes UI mitliefern und als sogenanntes Micro-UI in einem entsprechenden Rahmen einbinden. Hierbei ist aber darauf zu achten, dass die Micro-UIs zueinander kompatibel sind, da der Nutzer sonst die Heterogenität der Technologien direkt vor sich sieht.

Damit sind wir auch bei einem anderen Thema, bei dem die optimistische Beschreibung der Microservices in der Realität an ihre Grenzen stösst. So klingt es natürlich für Entwickler verlockend, immer die Technologien einsetzen zu können, mit denen sie sich gut auskennen oder die aktuell besonders angesagt sind.

Die Summe der unterschiedlichen Technologien und des damit verbundenen Wissens macht das Gesamtsystem als solches aber schwerer beherrschbar, weil es zu einer Fragmentierung der Systemlandschaften innerhalb des Unternehmens führt. Das Geld, das während der Entwicklung durch eine höhere Produktivität der Entwickler eingespart wird, muss auf diese Weise in den entsprechenden Betrieb investiert werden, und diese Betriebskosten sind auf lange Sicht wesentlich höher als die anfänglichen Entwicklungskosten. Genau aus diesem Grund wird in vielen Unternehmen der Wahlfreiheit dann doch ein Riegel vorgeschoben.

Aufwände, die bei einem Monolithen somit über die reine Softwareentwicklung abgedeckt werden können, müssen in serviceorientierten Landschaften durch strategische Planung und unter Einbeziehung unterschiedlicher Stakeholder gelöst werden. Oder um es anders auszudrücken: In einem Monolithen kann Code sehr schnell und einfach geändert werden, mit allen Risiken und Nebenwirkungen. Bei verteilten Architekturen hat man als einzelner Entwickler nicht den Zugriff auf den gesamten Code und kann daher auch nicht einfach ohne Abstimmung etwas ändern. Für die Codequalität und -stabilität ist dies ein Vorteil, stellt aber an den organisatorischen Überbau des gesamten Softwareentwicklungsprozesses höhere Anforderungen, müssen doch Requirements, Softwareänderung und Releasepläne mit verschiedenen Stake­holdern abgestimmt werden, auch wenn das Vorgehen dies im Vorfeld so eventuell nicht vermuten lässt.

Damit soll nicht gesagt sein, dass all diese Herausforderungen die Nutzung von Microservices unmöglich machen oder dazu führen, dass man sie meiden sollte. Es ist nur so, dass sie nicht bei den Optimalbeschreibungen auftauchen, mit denen man sich beim Thema immer wieder konfrontiert sieht. Gerade wenn man sich dem Thema der Microservices aus einem Monolithen heraus widmet, trifft man auf diverse Dinge, bei denen man eigentlich keine Probleme vermutet und dann mitten in der Umsetzung über ein komplett anderes Mindset stolpert.

Erwähnenswert ist dies, weil das Thema der Microservices auch in den Etagen der Entscheider auf offene Ohren trifft. Ausgehend von den positiven Berichten von Uber, Netflix und anderen Grossunternehmen werden vor allem die hohe Entwicklungsgeschwindigkeit und die Möglichkeit des autarken Arbeitens der unterschiedlichen Teams als grosse Vorteile wahrgenommen. Davon verspricht man sich kürzere Releasezyklen und somit eine schnellere Anpassbarkeit an neue Marktgegebenheiten.

In der Praxis werden deshalb Entwicklungsteams damit konfrontiert, dass sie einen Monolithen in eine Microservice-Architektur wandeln müssen. Können in diesem Fall die Nachteile nicht eindeutig benannt und die damit verbundenen Risiken nicht adressiert werden, ist eine solche Migration fast sicher zum Scheitern verurteilt. Zumal sie möglicherweise gar nicht notwendig ist.