Die Microservice-Architektur klingt nach serviceorientierter Architektur

Ich habe die serviceorientierte Architektur nicht verstanden. Ich dachte, dass dies nur eines dieser hochtheoretischen und sehr unpraktischen Softwarearchitekturmuster sei.

Mit anderen Worten, ich hielt es für den feuchten Traum eines Architekturfanatikers.

Dann las ich einen Artikel mit dem Titel Microservices von Martin Fowler, und die serviceorientierte Architektur, die plötzlich begann, ergab für mich Sinn.

Was hat meine Meinung geändert?

Martin Fowler spezifiziert die Microservice-Architektur wie folgt:

Kurz gesagt, der Microservice-Architekturstil ist ein Ansatz zur Entwicklung einer einzelnen Anwendung als Suite kleiner Dienste, die jeweils in einem eigenen Prozess ausgeführt werden und mit einfachen Mechanismen kommunizieren, häufig einer HTTP-Ressourcen-API. Diese Services basieren auf Geschäftsfunktionen und können durch vollautomatische Bereitstellungsmaschinen unabhängig bereitgestellt werden. Es gibt ein absolutes Minimum an zentralisierter Verwaltung dieser Dienste, die möglicherweise in verschiedenen Programmiersprachen geschrieben sind und verschiedene Datenspeichertechnologien verwenden.

Nachdem ich das gelesen hatte, klickte etwas in meinem Kopf. Mir ist aufgefallen, dass die Microservice-Architektur sehr nach der serviceorientierten Architektur klingt, die wie folgt spezifiziert ist:

Serviceorientierte Architektur (SOA) ist ein Softwaredesign- und Softwarearchitektur-Designmuster, das auf diskreten Softwareteilen basiert, die Anwendungsfunktionalität als Dienste für andere Anwendungen bereitstellen. Dies wird als Serviceorientierung bezeichnet. Es ist unabhängig von Anbietern, Produkten oder Technologien.

Ein Dienst ist eine eigenständige Funktionseinheit, wie z. B. das Abrufen eines Online-Kontoauszugs. Dienste können mit anderen Softwareanwendungen kombiniert werden, um die vollständige Funktionalität einer großen Softwareanwendung bereitzustellen.

Warum habe ich das nicht früher bekommen? Ich denke, dafür gibt es zwei Gründe:

1. Ich bin kein großer Fan von ausgefallenen Architekturdiagrammen und technischem Kauderwelsch, und das sind die Werkzeuge, die oft verwendet werden, um serviceorientierte Architektur zu erklären. Man könnte wohl sagen, dass ich den Wald vor lauter Bäumen nicht sehen konnte.
2. Die meisten Anwendungen, die ich während meiner Karriere erstellt habe, waren "normale" Webanwendungen. Mit anderen Worten, die dem Benutzer angezeigte Benutzeroberfläche wird im Backend gerendert. Die Verwendung einer serviceorientierten Architektur in diesen Anwendungen ergab für mich keinen Sinn, da es einfacher war, alles derselben Binärdatei hinzuzufügen.

Der Aufstieg von Single-Page-Webanwendungen hatte einen großen Einfluss auf mein Denken. Wenn das Backend dem Frontend eine REST-API bereitstellt, die entscheidet, wie die empfangenen Informationen gerendert werden sollen, beginnt die serviceorientierte Architektur Sinn zu machen, da sie die folgenden Vorteile hat:

• Wir können die Anwendung in einzelne Teile unterteilen. Jedes Stück erfüllt einen bestimmten Bedarf und hat seine eigene domänenspezifische Sprache.
• Wir können nur die Teile unserer Anwendung skalieren, die mehr Ressourcen erfordern.
• Wir können einzelne Dienste bereitstellen, anstatt die gesamte Anwendung bereitzustellen.
• Verschiedene Dienste müssen nicht dieselbe Programmiersprache verwenden. Mit anderen Worten, wir können das beste Werkzeug für den Job verwenden.
• Verschiedene Dienste können von verschiedenen Teams erstellt (und gepflegt) werden.

Die serviceorientierte Architektur ist keine Wunderwaffe, aber sie bietet Lösungen für die Probleme, die durch die monolithische Architektur verursacht werden.

Es gibt zwei Probleme, die mich am meisten stören:

• Es ist verdammt schwer, den Code in Module zu organisieren, die keine Abhängigkeiten zu den anderen Modulen der Anwendung haben. Obwohl ich denke, dass dies nicht die Schuld der monolithischen Architektur ist, ist es immer noch ein Problem, das bei den meisten monolithischen Anwendungen auftritt (wenn Sie Spring verwenden, haben Sie auch andere Probleme).
• Die Sprache des Monolithen ist oft voller Kompromisse. Ich gestehe, dass ich ein bisschen besessen von domänengetriebenem Design bin und ich würde gerne seine volle Kraft in meiner Arbeit nutzen. Dies ist jedoch schwierig, wenn der gesamte Code zum selben Monolithen gehört, der unterschiedliche Geschäftsanforderungen mit unterschiedlichem Vokabular erfüllen muss. Vielleicht ist dies ein Grund, warum Unternehmensanwendungen oft eine sehr allgemeine und verwirrende Sprache verwenden.

Vielleicht bin ich ein bisschen zu begeistert davon, aber man kann mit Sicherheit sagen, dass die serviceorientierte / Microservice-Architektur endlich ihren Weg in mein Toolkit gefunden hat.

Der Name spielt keine Rolle

Die serviceorientierte Architektur hat vielleicht einen schlechten Ruf, weil sie nach Unternehmertum klingt, und jeder weiß, dass Unternehmertum eine schlechte Sache ist (zumindest in Hipster-Kreisen). Vielleicht haben einige Leute deshalb angefangen, es Microservice-Architektur zu nennen.

Oder vielleicht verstehe ich die serviceorientierte Architektur nicht wirklich und kann deshalb keinen Unterschied zwischen ihr und der Microservice-Architektur erkennen (das ist wahrscheinlich wahr).

Da ich kein Architekturberater bin, interessiert es mich nicht wirklich, wie dieser Architekturstil heißt. Mir ist nur wichtig, dass ich einen neuen Weg gefunden habe, um einige der Probleme zu lösen, die durch die monolithische Architektur verursacht werden.