13. September 2020

microservices vs monolith – Sekt oder Selters?

So sieht sie nun aus, die schöne, neue Softwarewelt. Die ehemals monolithische Struktur grosser, komplexer Softwareprojekte weicht einer Mikroservicearchitektur. Ehemals langatmige Deployment- (und Test-) prozesse werden ersetzt durch kurze CI / CD Pipelines.

Ein Klick und jeder neue und geänderte Service ist produktiv. Natürlich vollständig abwärtskompatibel und dank automatisierter Tests frei von Fehlern.

Für mich – primär im Mittelstand tätig – ergeben sich Fragestellungen:

  1. Ist diese Form von Softwareentwicklung für jedes Projekt sinnvoll?
  2. Wie schaut es aus mit den Betriebskosten?
  3. Erkaufe ich mir neue Probleme, die ich bisher nicht hatte?

Nicht jede Software dient am Ende der Schaffung einer Plattform mit dem Traffic wie bspw. google, amazon oder youtube.

Wieso komme ich auf dieses Thema?
Bei der Recherche im Internet bin ich über die folgende Skizze als beispielhafte Microservicearchitektur gestossen: (Diese Bilder gibt es in Hülle und Fülle in ähnlicher Form im Web. Dem geneigten Besucher empfehle ich eine Suche nach dem Bergiff „Microservices“ bei google, bing, DuckDuckGo oder sonstwo.

Quelle: https://www.weave.works/assets/images/bltc1f320aca569f087/microservices-infographic.png

Hier wird dann fachlich sehr fundiert über die Nachteile des Monolithen gegenüber der serviceorientierten Architektur debattiert. Um dann am Ende dem maximal „flexiblen“ Backend ein dickes, fettes und sehr monolithisches UI überzustülpen. In der Skizze auch noch sehr schön in rot eingefärbt. Hm. Kein Haken?

Ein paar Anmerkungen zu Microservices meinerseits:
Microservices sind ein geeignetes Pattern zur logischen Entkopplung umfangreicher Softwaresysteme, aber nicht das eine Pattern zur Lösung aller Probleme. Wie immer im Leben verlagere ich Probleme in eine andere Ebene, und für jedes behobene Problem entsteht an anderer Stelle ein neues.!

  1. Wenn ich also Anwendungen habe, die sehr stark skalieren müssen, die aber wenig UI Implikationen haben, dann bitte gerne so wie oben beschrieben.
  2. Wenn ich eine Microservice-Architektur nutzen möchte, um Abhängigkeiten zwischen Entwicklerteams zu minimieren, dann bitte nicht so, wie oben beschrieben, sondern nur mit einem dazu passenden Microfrontend-Ansatz.
  3. Wenn ich eine Microservice-Architektur nutzen möchte, dann muss mir klar sein, dass die oben skizzierte Welt nicht vollständig ist, da unter den bunten isolierten Microservices noch ein dicker fetter KAFKA Bus hängt, der leider in der Skizze fehlt und der (hoffentlich) alle Daten der Microservices synchron hält.

Es ist wie fast immer im Leben, die Welt ist nicht schwarz oder weiss, sondern grau. Und ich bin kein Gegner von Microservices, sondern ich mag unvollständige Berichte / Kommentare nicht. Und wenn ich euch durch diesen Zeilen zum Nachdenken und Abwägen gebracht habe, dann freut mich das.

VG Stephan

Scroll to Top