Microservices erzeugen lediglich andere technische Schulden

Gute Software wird nicht durch Technologie allein erzielt

Sowohl für die Umsetzung einzelner Microservices als auch für die nun zusätzlich notwendigen Antworten auf die Entwicklung und den Betrieb eines verteilten Systems, finden sich zahlreiche technische Möglichkeiten. Gute Software, die durch Merkmale wie Wartbarkeit, Erweiterbarkeit oder Skalierbarkeit glänzt, wird jedoch nicht durch Technologie allein erzielt. Diese Feststellung ist sicherlich keine revolutionär wichtige. Denn bei der Vielzahl an technologischen Entwicklungen und Frameworks, die rund um Microservices entstehen, besteht die Gefahr, die grundsätzlichen Fragen aus den Augen zu verlieren. Daher ist der Titel dieses Blog-Artikels als Erinnerung und Erdung gedacht: Microservices erzeugen lediglich andere Ausprägungen technischer und konzeptueller Schulden als Monolithen.

Microservices stellen ein architektonisches Muster dar, welches unabhängig von der aus meiner Sicht schwierigsten, aber auch wertschöpfendsten Aufgabe der Softwareentwicklung ist: Die Abbildung und formale Strukturierung real existierender Informationen und Prozesse durch Software. Im Softwareentwicklungsprozess erzeugen wir konzeptuelle Modelle für diese Informationen und Prozesse, die wir unter anderem in Programmiersprachen beschreiben. Die zuvor genannten Merkmale guter Software sind maßgeblich durch die Trennschärfe und Definition der Modelle beeinflusst. Eine unscharfe Zerlegung erzeugt unscharfe Modelle und als Folge eine enge Kopplung und viele Abhängigkeiten zwischen Teilen unserer Software, oder aber viele ungewollte Redundanzen über die Teile der Software hinweg. Als Folge mindert sich die Güte der Software, die Erweiterbarkeit verringert sich und die Behebung von Programmierfehlern erschwert sich.

Je nach Architektur manifestieren sich Abhängigkeiten und Redundanzen unterschiedlich: Während wir in einer monolithischen Architektur obsoleten Code, zyklische Abhängigkeiten und eine Vielzahl modulübergreifender Aufrufe feststellen, entstehen in einer Microservice-Architektur sich funktional überschneidende und unnötig viele Microservices. Oder aber Microservices, die unnötig viel Verständnis über andere Microservices enthalten und dadurch eine enge Kopplung erzeugen.

Neue architektonische Antwortmöglichkeiten

Unabhängig von diesen grundsätzlichen Herausforderungen der Softwareentwicklung und dem Umgang mit Software über ihren Lebenszyklus, erweitern Microservices den Werkzeugkasten architektonischer Antworten. Doch sie stellen – so wie jede technische Neuerung – keine Antwort für bessere Software dar. Interessanter ist aus meiner Sicht die Frage, ob sie auch auf anderen Ebenen ebenfalls eine Ergänzung liefern, z.B. für die Softwareentwicklungsmethodik. Welche Auswirkungen haben Microservices auf Softwareentwicklungsprozesse und Software-Delivery-Prozesse? Wirkt die physisch starke Entkopplung in einer Microservice-Architektur auch auf das Verhalten und die Denkweise der Teams, die Anforderungen liefern, diese entwickeln, testen und betreiben? Bestimmt, aber wie? Bewirkt am Ende die technische Isolation im negativen Sinne eine Isolation der Teams oder im positiven Sinne die Einhaltung der in der Trennung begründeten Definitionen?

Microservices und Tauziehen

Bradley et al (vgl. The team scaling fallacy: Underestimating the declining efficiency of larger teams, Organizational Behavior and Human Decision Processes,, Bradley R. Staats, Katherine L. Milkman, Craig R. Fox) haben untersucht wie sich die Größe von Personengruppen auf das Verhalten der Gruppenmitglieder auswirkt. Das Ergebnis: Personen in kleinen Teams ziehen fester am Seil als Personen in großen Teams. Natürlich ist Tauziehen nicht gänzlich vergleichbar mit der Disziplin der Softwareentwicklung und möglicherweise noch weniger vergleichbar mit der Entwicklung tragfähiger konzeptueller Modelle. Mich würde interessieren, wie das Ergebnis eines Experiments in der Softwareentwicklung aussähe, welche Unternehmenskulturen und Aufbauorganisationen durch Microservices nicht nur ein neues architektonisches Muster erhalten, sondern ihre Software-Delivery-Effizienz steigern können.

Fazit

Oft diskutieren wir in der Softwareentwicklung über Technologien und Patterns. Oft auch über methodische und organisatorische Aspekte der Entwicklungsprozesse, z.B. über agile Softwareentwicklung. Das Zusammenspiel beider Aspekte ist aus meiner Sicht eine der Fragen, die zukünftig noch viele Betätigungsfelder für Forscher und Visionäre zwischen Technologie und Methodik der Softwareentwicklung bietet, um die Entwicklung guter Software zu beflügeln. Was meint ihr?