Ich wollte schon lange einen Artikel zum Thema Microservice-Architektur schreiben, aber zwei Dinge hielten mich immer wieder davon ab – je tiefer ich in das Thema eintauchte, desto mehr schien es mir, dass das, was ich weiß, offensichtlich ist und was ich nicht weiß. Was ich nicht weiß, muss studiert und studiert werden. Andererseits denke ich, dass es bei einem breiten Publikum bereits etwas zu diskutieren gibt. Daher sind alternative Meinungen willkommen.
Conways Gesetz und die Beziehung zwischen Unternehmen, Organisation und Informationssystem
Ich erlaube mir noch einmal zu zitieren:
„Jede Organisation, die ein System (im weitesten Sinne) entwirft, erhält einen Entwurf, dessen Struktur die Struktur der Teams in dieser Organisation nachbildet.“
— Melvyn Conway, 1967
Meiner Meinung nach bezieht sich dieses Gesetz eher auf die Durchführbarkeit der Organisation eines Unternehmens als direkt auf das Informationssystem. Lassen Sie es mich anhand eines Beispiels erklären. Nehmen wir an, wir haben eine ziemlich stabile Geschäftsmöglichkeit mit einem so langen Lebenszyklus, dass es sinnvoll ist, ein Unternehmen zu gründen (das ist kein Tippfehler, aber ich mag diesen Begriff, den ich gestohlen habe, wirklich). Natürlich das unterstützende System dieses Unternehmens wird organisatorisch und prozessual diesem Geschäft entsprechen.
Geschäftsorientierung von Informationssystemen
Lassen Sie es mich anhand eines Beispiels erklären. Nehmen wir an, es besteht eine Geschäftsmöglichkeit, ein Geschäft zum Verkauf von Pizza zu gründen. In der V1-Version (nennen wir es Vorinformation) war das Unternehmen eine Pizzeria, eine Kasse und ein Lieferservice. Diese Version war unter Bedingungen geringer Umweltschwankungen langlebig. Dann wurde es durch Version 2 ersetzt – fortschrittlicher und in der Lage, im Kern ein Informationssystem für Unternehmen mit einer monolithischen Architektur zu nutzen. Und hier liegt meiner Meinung nach einfach eine schreckliche Ungerechtigkeit gegenüber den Monolithen vor - vermeintlich monolithische Architektur entspricht nicht dem Domain-Geschäftsmodell. Ja, wenn dem so wäre, wäre das System überhaupt nicht funktionsfähig – im Widerspruch zum gleichen Conway-Gesetz und zum gesunden Menschenverstand. Nein, die monolithische Architektur entspricht in dieser Phase der Geschäftsentwicklung vollständig dem Geschäftsmodell – ich meine natürlich die Phase, in der das System bereits erstellt und in Betrieb genommen wurde. Es ist eine absolut wunderbare Tatsache, dass unabhängig vom Architekturansatz sowohl die serviceorientierte Architektur Version 3 als auch die Microservices-Architektur Version N gleich gut funktionieren. Was ist der Haken?
Alles fließt, alles verändert sich, oder sind Microservices ein Mittel gegen Komplexität?
Bevor wir fortfahren, schauen wir uns einige Missverständnisse über die Microservice-Architektur an.
Befürworter eines Microservice-Ansatzes argumentieren oft, 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, die offensichtliche Interaktion innerhalb eines monolithischen und homogenen Codes scheint kompliziert zu sein? Wäre dies wirklich der Fall, würden alle Projekte zunächst als Microservices aufgebaut, wobei die Praxis zeigt, dass die Migration von einem Monolithen zu Microservices viel häufiger vorkommt. Komplexität verschwindet nicht; sie bewegt sich einfach von einzelnen Modulen zu Schnittstellen (sei es Datenbusse, RPC, APIs und andere Protokolle) und Orchestrierungssystemen. Und das ist schwierig!
Auch der Vorteil der Verwendung eines heterogenen Stacks ist fraglich. Ich werde nicht behaupten, dass dies auch möglich ist, aber in der Realität kommt es selten vor (mit Blick auf die Zukunft sollte dies passieren – aber eher als Konsequenz denn als Vorteil).
Produktlebenszyklus und Servicelebenszyklus
Schauen Sie sich das Diagramm oben noch einmal an. Es ist kein Zufall, dass ich den kürzeren Lebenszyklus einer separaten Version eines Unternehmens festgestellt habe – unter modernen Bedingungen ist die Beschleunigung des Übergangs eines Unternehmens zwischen Versionen entscheidend für seinen Erfolg. Der Erfolg eines Produkts wird durch die Geschwindigkeit bestimmt, mit der darin enthaltene Geschäftshypothesen getestet werden. Und hier liegt meiner Meinung nach der entscheidende Vorteil der Microservice-Architektur. Aber gehen wir der Reihe nach vor.
Kommen wir zur nächsten Stufe in der Entwicklung von Informationssystemen – zur serviceorientierten Architektur von SOA. Irgendwann haben wir also einen bestimmten Punkt in unserem Produkt hervorgehoben langlebige Dienste - langlebig in dem Sinne, dass beim Wechsel zwischen Versionen eines Produkts 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 – wir Was zählt, ist die Geschwindigkeit des Übergangs zur nächsten Version. Aber leider sind wir gezwungen, ständige Änderungen an den Diensten vorzunehmen – und hier funktioniert alles für uns, DevOps-Praktiken, Containerisierung usw. – alles, was uns in den Sinn kommt. Aber das sind immer noch keine Microservices!
Microservices als Mittel zur Bekämpfung der Komplexität... Konfigurationsmanagement
Und hier können wir endlich zur entscheidenden Rolle von Microservices übergehen – es handelt sich um einen Ansatz, der das Produktkonfigurationsmanagement vereinfacht. Genauer gesagt beschreibt die Funktion jedes Microservices genau die Geschäftsfunktion innerhalb des Produkts gemäß dem Domänenmodell – und dabei handelt es sich nicht um Dinge, die nicht in einer kurzlebigen Version leben, sondern in einer langlebigen Geschäftsmöglichkeit. Und der Übergang zur nächsten Version des Produkts geschieht buchstäblich unbemerkt – Sie ändern/fügen einen Microservice und vielleicht auch nur das Schema seiner Interaktion hinzu, und plötzlich befinden Sie sich in der Zukunft und lassen weinende Konkurrenten zurück, die weiterhin zwischen den Versionen wechseln ihre Monolithen. Stellen Sie sich nun vor, dass es eine ziemlich große Menge an Microservices mit vordefinierten Schnittstellen und Geschäftsfunktionen gibt. Und Sie kommen und bauen die Struktur Ihres Produkts aus vorgefertigten Microservices auf – zum Beispiel einfach durch das Zeichnen eines Diagramms. Herzlichen Glückwunsch – Sie haben eine Plattform – und können jetzt Geschäfte für sich gewinnen. Träume Träume.
Befund
- Die Architektur des Systems sollte durch den Lebenszyklus seiner Komponenten bestimmt werden. Wenn eine Komponente innerhalb einer Produktversion lebt, macht es keinen Sinn, die Komplexität des Systems durch den Einsatz eines Microservice-Ansatzes zu erhöhen.
- Die Microservice-Architektur sollte auf dem Domänenmodell basieren – denn die Geschäftsmöglichkeit ist die langlebigste Domäne
- Bereitstellungspraktiken (DevOps-Praktiken) und Orchestrierung gehören zu den wichtigsten für die Microservice-Architektur – da die zunehmende Änderungsrate von Komponenten erhöhte Anforderungen an die Geschwindigkeit und Qualität der Bereitstellung stellt
Source: habr.com