👈🏿 🏄 🍙 Microservices: Was ist das, warum ist es und wann müssen Sie sie implementieren? 🐳 🔝 🤾🏽

Ich wollte schon lange einen Artikel zum Thema Microservice-Architektur schreiben, aber zwei Punkte hörten immer wieder auf - je weiter ich mich mit dem Thema befasste, desto mehr schien mir, dass das, was ich weiß, offensichtlich war und dass ich es nicht wusste, ich musste noch studieren und studieren. Andererseits glaube ich, dass es in einem breiten Publikum bereits etwas zu spekulieren gibt. Daher sind alternative Meinungen willkommen.

Conway Law und die Beziehung zwischen Unternehmen, Organisation und Informationssystem

Ich erlaube mir noch einmal zu zitieren:

„Jede Organisation, die ein System entwirft (im weiteren Sinne), erhält ein Design, dessen Struktur die Struktur der Teams in dieser Organisation kopiert“
- Melvyn Conway, 1967

Meiner Meinung nach bezieht sich dieses Gesetz eher auf die Zweckmäßigkeit der Organisation eines Unternehmens als direkt auf das Informationssystem. Ich werde mit einem Beispiel erklären. Angenommen, wir haben eine ausreichend stabile Geschäftsmöglichkeit mit einem Lebenszyklus von einer solchen Dauer, dass es sinnvoll ist, ein Unternehmen zu organisieren (dies ist kein Tippfehler, aber ich mag den Begriff, den ich weggenommen habe, wirklich). Natürlich wird das unterstützende System dieses Geschäfts organisatorisch und prozesskonform mit diesem Geschäft sein .

Informationssysteme zur Geschäftsorientierung

Ich werde mit einem Beispiel erklären. Angenommen, es gibt eine Geschäftsmöglichkeit, ein Pizzageschäft zu organisieren. In der V1-Version (nennen wir es vorinformativ) war das Unternehmen eine Pizzeria, eine Kasse und ein Lieferservice. Diese Version war langlebig unter Bedingungen geringer Variabilität der umgebenden Welt. Dann kam Version 2, die fortgeschrittener war und das Informationssystem als Grundlage für ein Unternehmen mit einer monolithischen Architektur verwenden konnte. Und hier gibt es meiner Meinung nach einfach schreckliche Ungerechtigkeit in Bezug auf Monolithen - angeblich entspricht die monolithische Architektur nicht dem Geschäftsmodell der Domäne. Ja, wenn das so wäre, hätte das System entgegen dem gleichen Conway-Gesetz und dem gleichen gesunden Menschenverstand überhaupt nicht funktionieren können. Nein, die monolithische Architektur stimmt in dieser Phase der Geschäftsentwicklung vollständig mit dem Geschäftsmodell überein - natürlich meine ich die Phase, in der das System bereits erstellt und in Betrieb genommen wurde. Es ist eine absolut bemerkenswerte Tatsache, dass unabhängig vom architektonischen Ansatz sowohl die serviceorientierte Architektur von Version 3 als auch die Microservice-Architektur von Version N gleich gut funktionieren. Was ist der Haken?

Fließt alles, ändert sich alles oder sind Microservices ein Weg, um mit Komplexität umzugehen?

Bevor wir fortfahren, werden wir einige Missverständnisse in Bezug auf die Microservice-Architektur betrachten.

Befürworter des Microservice-Ansatzes sagen häufig, dass die Aufteilung eines Monolithen in Microservices den Entwicklungsansatz vereinfacht, indem die Codebasis einzelner Services reduziert wird. Meiner Meinung nach ist diese Aussage völliger Unsinn. Im Ernst, erscheint die offensichtliche Wechselwirkung innerhalb eines Monolithen und eines homogenen Codes kompliziert? Wenn dies wahr wäre, würden alle Projekte zunächst als Mikrodienste erstellt, während die Praxis zeigt, dass die Migration von einem Monolithen zu Mikrodiensten viel häufiger ist. Die Komplexität verschwindet nirgendwo, sondern wechselt einfach von einzelnen Modulen zu Schnittstellen (Datenbusse, RPC, APIs und andere Protokolle) und Orchestrierungssystemen. Und es ist schwer!

Der Vorteil der Verwendung eines heterogenen Stapels ist ebenfalls zweifelhaft. Ich werde nicht argumentieren, dass dies auch möglich ist, aber in der Realität selten vorkommt (Vorausschauend - dies sollte der Ort sein - sondern eher als Konsequenz als als Vorteil).

Produktlebenszyklus und Service-Lebenszyklus

Schauen Sie sich die Tabelle oben noch einmal an. Es war kein Zufall, dass ich den verkürzten Lebenszyklus einer separaten Version eines Unternehmens bemerkte - unter modernen Bedingungen ist es die Beschleunigung des Übergangs eines Unternehmens zwischen Versionen, die für seinen Erfolg entscheidend ist. Der Produkterfolg wird durch die Geschwindigkeit des Testens von Geschäftshypothesen bestimmt . Und hier liegt meiner Meinung nach der Hauptvorteil der Microservice-Architektur begraben. Aber lass uns in Ordnung gehen.

Fahren wir mit dem nächsten Schritt in der Entwicklung von Informationssystemen fort - zu einer serviceorientierten SOA-Architektur. Zu einem bestimmten Zeitpunkt haben wir langlebige Dienstleistungen in unserem Produkt hervorgehoben- Langlebig in dem Sinne, dass beim Wechsel zwischen Produktversionen die Möglichkeit besteht, dass der Lebenszyklus des Dienstes länger ist als der Lebenszyklus der nächsten Version des Produkts. Es wäre logisch, sie überhaupt nicht zu ändern - die Geschwindigkeit des Übergangs zur nächsten Version ist uns wichtig . Leider sind wir gezwungen, ständig Änderungen an den Diensten vorzunehmen - und hier passt alles zu uns, den DevOps-Praktiken, der Containerisierung usw. - alles, was uns in den Sinn kommt. Aber das sind noch keine Microservices!

Microservices als Werkzeug zur Bekämpfung der Komplexität ... Konfigurationsmanagement

Und hier können wir endlich zur bestimmenden Rolle von Microservices übergehen - dies ist ein Ansatz, der das Produktkonfigurationsmanagement vereinfacht. Insbesondere beschreibt die Funktion jedes Mikroservices genau die Geschäftsfunktion innerhalb des Produkts gemäß dem Domänenmodell - und dies sind Dinge, die nicht in einer kurzlebigen Version, sondern in einer langlebigen Geschäftsmöglichkeit leben. Und der Übergang zur nächsten Version des Produkts ist buchstäblich nicht wahrnehmbar - Sie ändern / fügen einen Mikroservice und möglicherweise nur das Schema ihrer Interaktion hinzu und befinden sich plötzlich in der Zukunft, sodass weinende Konkurrenten zurückbleiben, die weiterhin zwischen den Versionen ihrer Monolithen wechseln. Stellen Sie sich nun vor, dass es ein ziemlich großes Volumen an Microservices mit vordefinierten Schnittstellen und Geschäftsmöglichkeiten gibt.Und Sie kommen und bauen die Struktur Ihres Produkts aus vorgefertigten Microservices auf - indem Sie beispielsweise ein Diagramm zeichnen. Herzlichen Glückwunsch - Sie haben eine Plattform - und jetzt können Sie Ihr eigenes Geschäft aufbauen. Träume Träume.

Ergebnisse

Die Architektur des Systems sollte durch den Lebenszyklus seiner Bestandteile bestimmt werden. Wenn eine Komponente in der Produktversion enthalten ist, macht es keinen Sinn, die Komplexität des Systems mithilfe eines Microservice-Ansatzes zu erhöhen.
Die Microservice-Architektur sollte auf einem Domänenmodell basieren - aus dem Grund, dass Geschäftsmöglichkeiten der langlebigste Bereich sind
Bereitstellungspraktiken (DevOps-Praktiken) und Orchestrierung haben einen der wichtigsten Werte für die Microservice-Architektur - aus dem Grund, dass eine Erhöhung der Änderungsrate von Komponenten höhere Anforderungen an die Geschwindigkeit und Qualität der Bereitstellung stellt