Microservices sind kleine voneinander unabhängige Dienste, die in einem verteilten System miteinander mit Hilfe einer API interagieren. In der Softwareentwicklung spricht man dann auch von einer Microservice-Architektur. In diesem Zusammenhang fällt häufig auch der Begriff Domain Driven Design, wenn jeder Dienst Funktionen eines separaten Fachbereichs abbildet. Das klären wir aber ein anderes Mal genauer.
Microservices zeichnen sich also durch zwei Eigenschaften aus:
Ist ja nicht gerade präzise. Deshalb sollten wir uns das genauer anschauen.
Um die richtige Größe von Microservices ranken sich viele Mythen. Um eine halbwegs brauchbare Definition zu erhalten, mit der man nicht nur in einem Software-Philosophie-Kurs punkten, sondern auch Entscheidungen treffen kann, schauen wir uns mal ein paar Aussagen an:
Haha. Was soll das denn bedeuten? Mit der dritten Aussage wird sinngemäß verlangt, ein System zu zerschlagen, wenn ein Softwareentwicklungs-Team das Gefühl hat, etwas ist zu groß. Anders ausgedrückt: Je kleiner ein Microservice ist, desto größer sind die Vor- aber auch die Nachteile. Wenn Sie aus einer eierlegenden Wollmilchsau eine Kuh, ein Schaf und ein Huhn machen, ist das definitiv sinnvoll – So eine Wollmilchsau ist nämlich nur schwer zu ersetzen und braucht sehr spezielle Pflege.
Lassen Sie aber für jede Addition einen Web-Dienst mit eigner API entwickeln, der zu allem Überfluss noch auf einer dedizierten Maschine läuft, wird’s insgesamt einfach zu komplex.
Während die richtige Größe eher als Geschmacksfrage daherkommt, scheint es mit der Autonomie schon griffiger zu sein. Ein Microservice ist weitestgehend autonom, wenn folgende Bedingungen erfüllt sind:
Ein Dienst läuft in einem separaten Prozess bzw. in einer eigenständigen Maschine. Damit ist gemeint, dass das Restsystem nicht runtergefahren werden muss und weiterläuft, während der neue Dienst ins Rennen geht.
Microservices sagen den behäbigen Monolithen in Form gigantischer Programm-Klumpen den Kampf an und haben eine Reihe von Vorteilen zu bieten:
Vereinfachte Bereitstellung: Anstatt eine gigantische Software-Lösung unter Akzeptanz entsprechender Stillstandzeiten in einem Rutsch bereitzustellen (deployen), kann jeder Dienst und jedes Feature unabhängig in die Produktion entlassen werden.