Hi,

Microservice Architektur

Dieses Buzzword, ist für mich inzwischen ein Trigger geworden. Darüber habe ich schon oft geschrieben.

Anfang des Jahres trendete mein Artikel Microservices are a Big Ball of Mud auf Hacker News

In den 343 Kommentaren zu meinem Artikel kann man gut sehen, wie sehr das Thema die Gemüter erhitzt 😉 Natürlich ist der rationale Blick darauf ein anderer, als ich in dem Artikel dargestellt habe. Es kommt IMMER auf den Kontext an. AppContinuum ist ein hervorragendes Paper zu einem reflektierten Blick auf die Thematik.

Aber in diesem Newsletter soll es wieder darum gehen, wie schnell man sich massive Probleme einhandelt, wenn man eine MicroService Architektur baut

Vor einer Woche berichtete ich wie ein Release bei einem Kunden schief ging . Inzwischen haben wir die Ursache verstanden und gefixt. Wir mussten 1800 Zeilen Code anpassen. Wow.

Wir konnten nicht mehr als 2 Request pro Sekunde verarbeiten. Dann lief unser Connection Pool über. Und wir haben die Ursache rasch erkannt. Während wir die Datenbankverbindung offen hielten wurden mehrere Remote Procedure Calls (RPC) ausgeführt. Diese dauerten einfach zu lange. Die Connection musste die gesamte Zeit offen gehalten werden und der Pool war schneller leer als du bis Drei zählen konntest.

Jetzt sagst du vielleicht: “Na klar. Das ist ja offensichtlich. Mach die calls halt außerhalb der Connection”

Ja. Das stimmt. Die Lösung klingt so simpel. Aber wie immer steckt der Teufel im Detail.

Unsere Connection Strategie ist simpel

Wir öffnen eine Connection, wenn ein neuer Request reinkommt. Machen einen Rollback, wenn eine Exception geschmissen wird. Oder committen, wenn wir mit der Verarbeitung fertig sind. Das Ganze ist schön gekapselt in einem Filter. In Spring nennt sich diese Strategie “Open Session in View” - dazu habe ich erst neulich einen Artikel geschrieben .

Die Strategie ist simpel und sicher. Jede Änderung an unserer Datenbank ist atomar. Wir können keine Inkonsistenzen erzeugen. Das ist gut. Aber in einer Microservice Architektur, die eigentlich ein verteilter Monolith ist, tötet sie jedoch. Denn du musst ja RPC calls zu deinen services in deiner Domänenlogik machen, um an die notwendigen Informationen der anderen Services zu kommen.

Jetzt kann man natürlich sagen: “Aber hey, wenn du das machen musst, dann hast du deine Services wahrscheinlich falsch geschnitten. Das sollte die Ausnahme sein.”

Ja. Stimmt. In der Praxis sehe ich allerdings haufenweise Systeme, in denen unter dem Deckmantel einer Microservice Architektur ein verteilter Monolith gebaut wurde. Es ist einfach zu schwer die Services richtig zu schneiden. Leider erlebe ich zu oft, dass ein Team entscheidet mehrere Services zu entwickeln. Das ist meistens der Anfang vom Ende.

Stell dir folgende Frage

Kann (und sollte) mein Service von einem unabhängigen Team vollständig betreut werden? Nein? Dann baust du wahrscheinlich einen verteilten Monolithen.

Es hat mich also wieder getroffen. Was Anfangs gut gemeint ist, endet in einer großen Komplexität und in schmerzhaften Problemen. Es ist nur eines von vielen Beispielen, der letzten Jahre. Und es wird nicht das Letzte sein.

Rule the Backend,

~ Marcus