Mikroservices: Was sind sie, warum sind sie wichtig und wann sollten sie eingeführt werden?

Ich wollte schon lange einen Artikel über mikroservicearchitektur schreiben, doch zwei Fragen hielten mich immer wieder zurück: Je tiefer ich in das Thema eintauchte, desto mehr schien mir das, was ich weiß, offensichtlich, während das, was ich nicht weiß, noch zu lernen bleibt. Anderseits bin ich der Meinung, dass es bereits genügend Diskussionsstoff für ein breites Publikum gibt. Alternativen Meinungen sind daher herzlich willkommen.

Conway's Gesetz und der Zusammenhang zwischen Geschäft, Organisation und Informationssystem

Ich nehme mir erneut die Freiheit zu zitieren:

„Jede Organisation, die ein System (im weitesten Sinne) entwirft, erhält ein Design, dessen Struktur die Struktur der Teams in dieser Organisation widerspiegelt.“
— Melvyn Conway, 1967

Meiner Meinung nach bezieht sich dieses Gesetz eher auf die Zweckmäßigkeit der Geschäftsorganisation als direkt auf das Informationssystem. Lassen Sie mich ein Beispiel geben. Angenommen, wir haben eine ausreichend stabile Geschäftsmöglichkeit mit einem Lebenszyklus, der lang genug ist, um ein Unternehmen zu gründen (das ist kein Tippfehler; ich finde diesen Begriff, den ich entlehnt habe, sehr interessant). Natürlich wird das unterstützende System dieses Geschäfts organisatorisch und prozessual auf dieses Geschäft abgestimmt sein.

Geschäftsorientierung von Informationssystemen

Lassen Sie mich ein Beispiel geben. Angenommen, es gibt die Geschäftsmöglichkeit, ein Unternehmen zum Verkauf von Pizzen zu gründen. In Version 1 (nennen wir sie vor-informativ) stellte das Unternehmen eine Pizzeria, eine Kasse und einen Lieferservice dar. Diese Version war langlebig in einer Umgebung mit geringer Veränderung. Dann kam Version 2 — fortschrittlicher und in der Lage, ein Informationssystem als Grundlage für ein Unternehmen mit monolithischer Architektur zu nutzen. Und hier denke ich, entsteht einfach eine furchtbare Ungerechtigkeit gegenüber den Monolithen — Die angeblich monolithische Architektur entspricht nicht dem Geschäftsmodell der Domain.Wäre dem so, könnte das System überhaupt nicht funktionieren – was im Widerspruch zum Conway’schen Gesetz und zu gesundem Menschenverstand steht. Nein, die monolithische Architektur entspricht vollkommen dem Geschäftsmodell in dieser Phase der Unternehmensentwicklung – ich spreche hierbei von der Phase, in der das System bereits erstellt und in Betrieb genommen wurde. Es ist eine bemerkenswerte Tatsache, dass unabhängig vom architektonischen Ansatz sowohl die serviceorientierte Architektur Version 3 als auch die Microservices-Architektur Version N gleichermaßen gut funktionieren werden. Wo liegt der Haken?

Alles fließt, alles verändert sich – oder sind Microservices ein Mittel zur Bekämpfung von Komplexität?

Bevor wir fortfahren, lassen Sie uns einige Missverständnisse bezüglich der Microservices-Architektur betrachten.

Befürworter des mikroservices-Ansatzes behaupten oft, dass die Aufspaltung eines Monolithen in Mikrodienste die Entwicklung erleichtert, indem sie die Codebasis der einzelnen Dienste verringert. Meiner Meinung nach ist diese Aussage völliger Unsinn. Im Ernst, ist die offensichtliche Interaktion innerhalb eines Monolithen und homogenen Codes wirklich so kompliziert? Wäre das der Fall, würden alle Projekte von Anfang an als Mikrodienste konzipiert werden. Die Praxis zeigt jedoch, dass die Migration von einem Monolithen zu Mikrodiensten weitaus verbreiteter ist. Die Komplexität verschwindet nicht, sie wechselt lediglich von einzelnen Modulen zu Schnittstellen (sei es Datenbusse, RPC, APIs und andere Protokolle) und orchestrierenden Systemen. Und das ist – kompliziert!

Der Vorteil der Nutzung eines heterogenen Stacks ist ebenfalls fraglich. Ich will nicht sagen, dass dies nicht möglich ist, aber in der Realität kommt es selten vor (Um es vorwegzunehmen – es sollte vorkommen, jedoch eher als Folge denn als Vorteil).

Produktlebenszyklus und Servicelebenszyklus

Schauen Sie sich das Diagramm oben noch einmal an. Ich habe nicht zufällig den verkürzten Lebenszyklus einer einzelnen Geschäftsversion hervorgehoben – in der heutigen Zeit ist die Beschleunigung des Übergangs zwischen den Versionen für den Erfolg entscheidend. Der Erfolg eines Produkts hängt von der Geschwindigkeit ab, mit der die Geschäfts-Hypothesen darin überprüft werden.. Hier liegt meiner Meinung nach der Schlüsselvorteil der mikroservicebasierten Architektur. Doch lassen Sie uns der Reihe nach vorgehen.

Lassen Sie uns zur nächsten Evolutionsstufe der Informationssysteme übergehen – zur serviceorientierten Architektur (SOA). In einem bestimmten Moment haben wir in unserem Produkt langfristige Dienste definiert – langfristig insofern, als dass beim Übergang zwischen den Produktversionen die Chance besteht, dass der Lebenszyklus des Dienstes länger ist als der Lebenszyklus der nächsten Produktversion. Es wäre logisch, sie überhaupt nicht zu ändern – denn wir benötigen insbesondere die Geschwindigkeit des Übergangs zur nächsten Version. Doch bedauerlicherweise sind wir gezwungen, ständige Änderungen an den Diensten vorzunehmen – und hier kommen uns alle Möglichkeiten zugute, sei es DevOps-Praxis, Containerisierung und alles, was uns in den Sinn kommt. Aber das sind noch keine Mikroservices!

Mikrodienste als Mittel zur Bewältigung von Komplexität… Konfigurationsmanagement

Hier können wir endlich zur entscheidenden Rolle der Mikrodienste übergehen – es handelt sich um einen Ansatz, der das Management der Produktkonfiguration vereinfacht. Genauer gesagt beschreibt die Funktion jedes Mikrodienstes genau die Geschäfts- funktion innerhalb des Produkts gemäß dem Domänenmodell – und das sind bereits Dinge, die nicht in einer kurzlebigen Version leben, sondern in einer langlebigen Geschäftsmöglichkeit. Der Übergang zur nächsten Produktversion geschieht quasi unmerklich – Sie ändern oder fügen einen Mikrodienst hinzu, oder möglicherweise nur das Schema seiner Interaktionen, und schon befinden Sie sich in der Zukunft, während Ihre weinenden Konkurrenten weiterhin zwischen den Versionen ihrer Monolithen springen. Stellen Sie sich nun vor, dass es eine ausreichend große Anzahl an Mikrodiensten mit bereits definierten Schnittstellen und Geschäftsmöglichkeiten gibt. Sie kommen und bauen die Struktur Ihres Produkts aus diesen bestehenden Mikrodiensten – einfach indem Sie beispielsweise ein Diagramm zeichnen. Herzlichen Glückwunsch – Sie haben eine Plattform geschaffen – und jetzt können Sie sich Ihr Geschäft zusammenklicken. Träume, Träume.

Fazit

• Die Systemarchitektur sollte durch den Lebenszyklus der enthaltenen Komponenten bestimmt werden. Wenn eine Komponente innerhalb einer Produktversion lebt, macht es keinen Sinn, die Komplexität des Systems durch die Anwendung eines mikroservicebasierten Ansatzes zu erhöhen.
• Eine mikroservicebasierte Architektur sollte auf einem Domänenmodell basieren, da die Geschäftschancen die langlebigsten Bereiche sind.
• Lieferpraktiken (DevOps-Praktiken) und Orchestrierung spielen eine entscheidende Rolle in der mikroservicebasierten Architektur, da die erhöhte Geschwindigkeit bei Veränderungen an Komponenten höhere Anforderungen an die Geschwindigkeit und Qualität der Bereitstellung stellt.

Quelle: habr.com