Neil Fords Übersetzung von Microservices als evolutionäre Architektur

Wir haben eine Übersetzung eines Artikels von Neil Ford, einem Systemarchitekten und ideologischen Vordenker bei ThoughtWorks, einem Softwareentwicklungsunternehmen, das Softwaretests und Bereitstellungsprozesse automatisiert, vorbereitet.

Neil ist ein anerkannter Softwareentwicklungsexperte, der an der Schnittstelle zwischen agilem Design und Systemarchitektur arbeitet. Er ist Autor zahlreicher Artikel, Bücher, Dutzende von Videopräsentationen und spricht auf führenden Entwicklerkonferenzen. Sie können seine Arbeit auf nealford.com sehen .

Microservices als evolutionäre Architektur

Die Microservice-Architektur erobert schnell die Welt. Im März organisierte der O'Reilly-Verlag seine erste O'Reilly-Software-Architekturkonferenz. Fast 60% der Berichte widmeten sich bestimmten Aspekten der Nutzung von Mikrodiensten. Warum wurde dieser besondere Baustil plötzlich so beliebt?

Die Microservice-Architektur ist ein neuer architektonischer Entwurfsstil, der nach DevOps entstanden ist und kontinuierliche Softwarebereitstellungspraktiken beinhaltet. Es ist auch ein Beispiel für eine evolutionäre Architektur, die dem Prinzip allmählicher, kontinuierlicher Änderungen in mehreren Dimensionen auf der strukturellen Ebene einer Anwendung folgt. Dieser Artikel beschreibt einige der wichtigsten Merkmale und Prinzipien dieser Familie von Architekturstilen.

Evolutionäre Architektur

Früher glaubte man, dass die Elemente der Architektur "nach ihrer Entstehung sehr schwer zu ändern sind". Allmählicher Wandel ist das Hauptprinzip der evolutionären Architektur. Es zieht allgemeine Aufmerksamkeit auf sich, gerade weil Änderungen in der Architektur immer schwer vorhersehbar und sehr kostspielig waren. Wenn die Möglichkeit von evolutionären Änderungen in die Architektur selbst integriert ist, wird ihre Implementierung viel einfacher und billiger, was zu Änderungen in der Softwareentwicklung und den Release-Praktiken beiträgt und die allgemeine Prozessflexibilität erhöht.

Die Microservice-Architektur stimmt voll und ganz mit dieser Idee überein, da sie über begrenzte Kontexte verfügt , die gemäß Eric Evans 'Domain Driven Design logisch zugeordnet und als physisch separate Komponenten implementiert sind. Diese Trennung wird durch die Implementierung von DevOps-Praktiken wie Bereitstellung, Test und automatisierte Bereitstellung virtueller Maschinen erreicht. Da jeder Dienst von allen anderen Diensten (auf struktureller Ebene) getrennt ist, ist das Ersetzen eines Mikrodienstes durch einen anderen so einfach wie das Austauschen von Legowürfeln.

Merkmale der evolutionären Architektur

Evolutionäre Architekturen weisen eine Reihe gemeinsamer Merkmale auf. All diese Merkmale werden in einem bevorstehenden Buch über evolutionäre Architektur beschrieben. In diesem Artikel geben wir nur einige davon.

Modularität und Konnektivität

Die Möglichkeit, Komponenten innerhalb genau definierter Grenzen gemeinsam zu nutzen, bietet Entwicklern bei Bedarf den Vorteil einer kontinuierlichen Änderung. Wenn die Architektur nicht entworfen wurde und das System wie ein großer Schlammballen aussieht ( Big Ball of Mud-Architektur ), sind evolutionäre Änderungen unmöglich, da es in einer solchen Struktur keine unterscheidbaren Teile gibt.


[Die Beziehung zwischen den Klassen (Punkte um den Umfang) in einem großen Schmutzbündel aus einem unbenannten Kundenprojekt.]

Eine falsche Komponentenverbindung behindert die Entwicklung des Systems aufgrund der Tatsache, dass Änderungen unvorhersehbar andere Teile des Systems beeinflussen können. Alle evolutionären Architekturen bieten ein gewisses Maß an Modularität, normalerweise auf der Ebene der technischen Architektur (z. B. Schichtarchitektur).

Organisation rund um Geschäftsmöglichkeiten

Beeinflusst von den Prinzipien des themenorientierten Designs in modernen erfolgreichen Architekturen wird zunehmend Modularität auf Domänenebene eingesetzt. Eine service-basierte Architektur unterscheidet sich von einer herkömmlichen serviceorientierten Architektur (SOA) hauptsächlich in ihrer Service-Allokationsstrategie. Serviceorientierte Architektur ist streng nach technischen Ebenen unterteilt, während serviceorientierte Architekturen hauptsächlich in Teilen des durch Microservices definierten Themenbereichs erstellt werden.

Die Experimente

Die Durchführung von Experimenten ist einer der wesentlichen Vorteile, die die evolutionäre Architektur für Unternehmen bietet. Die Möglichkeit, auf einfache Weise kleine Änderungen an Anwendungen vorzunehmen, ermöglicht die Verwendung gängiger kontinuierlicher Bereitstellungsverfahren wie A / B-Tests, Tests für eine begrenzte Gruppe von Benutzern (Canary Release) und andere. Microservice-Architekturen werden häufig auf der Grundlage von Routing-Serviceaufrufen erstellt, sodass mehrere Versionen des Service innerhalb eines gesamten Ökosystems verwendet werden können. Dies eröffnet wiederum große Möglichkeiten zum Experimentieren und zur Änderung bestehender Funktionen. Letztendlich wird bei der Entwicklung von Geschäftsanwendungen weniger Zeit für die Erörterung von Plänen und Rückständen aufgewendet, und die Entwicklung erfolgt hauptsächlich im Rahmen des schnellen Hypothesentests.

Prinzipien der evolutionären Architektur

Ein vollständigeres Bild der evolutionären Architektur kann erhalten werden, indem man sich mit ihren Grundprinzipien vertraut macht. Diese Prinzipien beziehen sich auf verschiedene Merkmale sowohl der Architektur selbst als auch ihrer Entwurfsmethoden. Ein Teil der Prinzipien bezieht sich auf die Wahl des Zeitpunkts, zu dem architektonische Entscheidungen im Prozess des Systemdesigns getroffen werden.

Fitnessfunktion

Es ist notwendig, zwischen emergenter (als Ergebnis des Designprozesses gebildeter) und evolutionärer Architektur zu unterscheiden - dies ist äußerst wichtig. Wie evolutionäre Berechnungsmethoden (wie genetische Algorithmen) setzt die architektonische Fitnessfunktion ein Ziel bei der architektonischen Gestaltung. Bei einigen Systemen ist die Hauptanforderung eine lange Betriebszeit, bei anderen eine hohe Leistung oder Sicherheit.


[Radarkarte zur Hervorhebung wichtiger Fitnessfunktionen, die für dieses Softwaresystem relevant sind.]

Wenn Sie die Fitnessfunktion für ein bestimmtes System vorab festlegen, hilft dies in Zukunft, rechtzeitig die richtigen Entscheidungen zu treffen. Für verschiedene Architekturlösungen können Sie Fitnessfunktionen berechnen. Wenn der Wert besser wird, bedeutet dies, dass sich die Architektur in die richtige Richtung entwickelt.

Aufmerksamkeit auf Schmerzpunkte

Viele der Arbeitsmethoden, die bei der kontinuierlichen Bereitstellung von Software und der Entwicklung einer sich entwickelnden Architektur verwendet werden, basieren auf dem von der eXtreme Programming-Community formulierten Prinzip der „Beachtung von Schwachstellen“. Wenn in der Entwurfsarbeit Momente auftreten, die zu Problemquellen (Schmerzpunkten) werden können, müssen diese so schnell wie möglich beachtet werden. Dies wird dazu beitragen, potenzielle Probleme im Voraus zu identifizieren und in einem funktionierenden Zustand zu beseitigen. Gängige kontinuierliche Bereitstellungsverfahren wie die Bereitstellungspipeline, die automatische Bereitstellung virtueller Maschinen und die Datenbankmigration beim Entwerfen einer evolutionären Architektur vereinfachen die Beseitigung von Schwachstellen während der Änderungsphase erheblich.

Entscheidungspunkt

Der Hauptunterschied zwischen traditioneller und evolutionärer Architektur besteht darin, dass wichtige Entscheidungen getroffen werden. Diese Entscheidungen können sich auf die Anwendungsstruktur, den Technologie-Stack, einzelne Tools oder Kommunikationsmuster beziehen. Beim Entwerfen einer traditionellen Architektur werden solche Entscheidungen in der Anfangsphase getroffen, bevor der Code geschrieben wird. Bei der Entwicklung der evolutionären Architektur werden Entscheidungen so spät wie möglich getroffen, im letzten Moment, wenn sie noch akzeptabel sind. Der Vorteil einer späteren Entscheidungsfindung besteht darin, dass an dieser Stelle möglicherweise zusätzliche Informationen verfügbar sind. Die Kosten dieser Methode umfassen die Kosten einer möglichen Verfeinerung der Architektur nach einer Entscheidung. Diese Kosten können durch geeignete Abstraktionen reduziert werden, können aber dennoch auftreten. Die Kosten für Entscheidungen in der Anfangsphase sind jedoch ebenfalls sehr real. Treffen Sie zum Beispiel die Entscheidung, ein Messaging-Tool auszuwählen. Verschiedene Tools unterstützen unterschiedliche Funktionen. Wenn wir ein leistungsfähigeres Werkzeug als nötig wählen, erhalten wir eine schlecht konzipierte Architektur, die zwangsläufig weiterentwickelt werden muss. Diese "technische Verschuldung", die sich aus der Auswahl des falschen Tools ergibt, wird eine zusätzliche Belastung für die Entwickler sein.

Natürlich besteht das Hauptproblem im letztmöglichen Moment einer Entscheidung darin, festzustellen, wann es kommt. Konzentrieren Sie sich dazu auf die Funktion der Fitness. Zunächst müssen Entscheidungen getroffen werden, die einen erheblichen Einfluss auf die Auswahl der Architektur oder der Gestaltungselemente haben können, sowie Entscheidungen, die den Gesamterfolg des Projekts erheblich beeinflussen. Die negativen Auswirkungen einer Verzögerung einer solchen Entscheidung überwiegen häufig die möglichen Vorteile einer späteren Entscheidung.

Fazit

Softwarearchitekten sollten die Entscheidungen über den Entwurf der zu entwickelnden Systeme in der Regel anhand verschiedener Arten von Diagrammen erläutern. Architekturentwickler geraten häufig in die Falle, Softwarearchitektur als die Gleichung darzustellen, die sie lösen müssen. Mit vielen kommerziellen Tools, die von Softwarearchitekten angeboten werden, können Sie die Architektur formell in Form von Quadraten, Linien und Pfeilen beschreiben. Obwohl solche Diagramme nützlich sein mögen, bieten sie nur eine zweidimensionale Darstellung, eine Momentaufnahme der idealen Welt, aber wir leben in einer vierdimensionalen Realität.

Um ein solches zweidimensionales Diagramm mit Leben zu füllen, muss es spezifiziert werden. Das ORM- Label in einem zweidimensionalen Diagramm wird zu Hibernate v4.2.17 , wodurch die betreffende Welt dreidimensional wird. Wenn Sie einen Plan für die Implementierung in der Produktion haben und sechs Monate später auf die unvermeidliche Version von Hibernate v4.3.0.1 aktualisieren , sind Sie bereit für die vierdimensionale Welt. Viele Architekten erkennen nicht, dass eine statische Ansicht der Architektur eine kurze Lebensdauer hat. Das Softwareuniversum existiert in einem Stream-Zustand, es ist dynamisch, nicht statisch. Architektur ist keine Gleichung, sondern eine Momentaufnahme eines laufenden Prozesses.

Praktiken der kontinuierlichen Softwarebereitstellung und von DevOps haben gezeigt, dass Probleme aufgrund eines Mangels an Verständnis für die Anstrengungen entstehen, die zur Implementierung und Unterstützung der Architektur erforderlich sind. Die Implementierung der Architektur ist nur der erste Schritt. Architektur bleibt eine Abstraktion, bis sie in die Tat umgesetzt wird. Mit anderen Worten, die langfristige Rentabilität einer Architektur kann nur beurteilt werden, wenn Sie sie nicht nur implementiert, sondern auch mindestens einmal geändert haben. Und vielleicht haben sie es geschafft, die Überraschungen auf dem Weg zu bewältigen.
Das Verständnis der Betriebsfähigkeiten eines Softwarearchitekten ist entscheidend für die Entwicklung einer evolutionären Architektur. Die evolutionäre Entwicklung der Architektur wirkt sich auf die Merkmale ihrer Implementierung aus und muss daher bei der Fertigstellung berücksichtigt werden. Die Anforderungen des kontinuierlichen Bereitstellungsprozesses für die Architektur zielen darauf ab, ihre Visualisierung zu verbessern und Änderungen zu vereinfachen. Auf diese Weise verbessert die kontinuierliche Bereitstellung die Fähigkeiten der evolutionären Architektur.

Am 19. November kommt Neil Ford mit einer Meisterklasse zum Erstellen einer evolutionären Softwarearchitektur nach Moskau.