Was ist wirklich anders zwischen SOA und Microservices

Haftungsausschluss

Ich hoffe, ich trete niemandem auf die Zehen oder beleidige die Enthusiasten beider Konzepte

Hintergrund

Ich habe nach echten Unterschieden zwischen serviceorientierter Architektur und Microservices gesucht , ohne eine klare Antwort zu finden.

Ich lese Dinge wie:

• die Nebenwirkungen von SOA
• SOA ist Anti-Pattern
• Microservices kamen, um die Fehler von SOA zu beheben
• ESBs sind nicht wirklich ESBs, sondern EAIs
• Übermäßiges Vertrauen in Message Brokers
• Anbieter missbrauchen den Begriff SOA und versuchen, ihre Produkte zu verkaufen
• SOA wächst unkontrolliert

Dennoch definiert nichts klar die architektonischen Unterschiede zwischen serviceorientierter Architektur (als Konzept) und Microservices (als Konzept).

Nach meinem Verständnis haben beide:

• Dienstleister, die nur eines tun
• Service Gateway / ESB stellt diese Dienste Verbrauchern zur Verfügung
• Service-Verbraucher, die über ESB / Service Gateway auf Services zugreifen

Frage

Gibt es etwas anderes als die Umbenennung von SOA in Microservices? Ist es eine technologische Einschränkung, die verhindert, dass Microservices zu Makros werden?

Hinweis: Ich suche keine Meinungen, nur harte Fakten, hoffentlich in Stichpunkten

Verweise

• Fragen zum Software-Engineering
• Martin Fowlers Site (Ich denke, er hasst es sehr)
• Info Welt
• Michael Fethers 'Website
• Fragen zum Stapelüberlauf

Aktualisieren

Es scheint, dass eine ähnliche Debatte in einer Stapelüberlauffrage stattgefunden hat , bei der die Meinungen geteilt wurden, ob Microservices eine serviceorientierte Architektur sind oder nicht.

Schlussfolgerung aus der SO-Frage:

• MS ist ein Sonderfall von SOA
• MS befürworten kleinere Anwendungen von Hosting-Diensten
• MS ist technologieabhängig (die Verwendung von HTTP anstelle von offenen Protokolloptionen)
• MS setzt auf Technologie, um Disziplin durchzusetzen (automatische Bereitstellung von Diensten)
• MS betrachtet ESBs (böse), verwendet jedoch API-Gateways, bei denen es sich meiner Meinung nach um eine Art ESB handelt

Daraus folgt, dass MS SOA ist, wenn Folgendes zutrifft:

• Unterstützen MS den Begriff Orchestrierung? Ein oder mehrere Masterprozesse verwalten Workflows
• Gibt es in MS eine Nachrichtenbroker-Schicht? Eine Reihe von Adaptern, die Nachrichtenformate aus dem Nachrichtenbereich der Dienstproduzenten an die Dienstkonsumenten übersetzen
• Können Microservices Daten aus monolithischen Unternehmensanwendungen lesen? Können es APIs einer monolithischen Anwendung sein? oder müssen es eigenständige Anwendungen sein, die unabhängig arbeiten können?

Wenn sich die Antwort auf die letzte Frage als Nein herausstellen würde, wäre Microservices nicht in der Lage, komplexe Workflow-Systeme, z. B. Kreditkartenverwaltungssysteme oder Abstimmungssysteme, zu handhaben

Dienstleister, die nur eines tun

Der Hauptunterschied, der weit verbreitete Konsequenzen des Projekts hat, besteht darin, dass diese Dienstanbieter mit Microservices unabhängig voneinander bereitstellbar und skalierbar sind .

Das ist großartig, weil Sie agiler sein können. Wenn ein Dienst geändert werden muss, ändern Sie einfach diesen, keinen seiner Verwandten. Wenn Sie ein neues Framework oder eine neue Sprache ausprobieren möchten, ersetzen Sie einfach diesen einen Dienst. Wenn Sie plötzlich die 100-fache Kapazität benötigen, drehen Sie einige neue Maschinen mit diesem Service hoch, um diesen Zustrom zu bewältigen. Wenn Sie etwas versionieren möchten, versionieren Sie es einfach, ohne die gesamte App zu berühren . Und es macht es einfacher, Dinge zu überwachen, zu instrumentieren, zwischen Teams aufzuteilen, veraltet ...

Aber es hat einige schwerwiegende Folgen:

• Ihr Freigabeprozess muss sich ändern, da sich die Bereitstellung einiger Dienste erheblich von der Bereitstellung einiger Dutzend Dienste unterscheidet.
• Ihr Freigabeprozess muss sich ändern, da sich die Bereitstellung eines Dienstes auf einem Computer erheblich von der Bereitstellung auf einigen Dutzend Computern unterscheidet.
• Das Design, die Verwendung und die Bereitstellung Ihrer Datenbank müssen sich ändern, da die Bereitstellung eines Dienstes bedeutungslos ist, wenn diese große gemeinsam genutzte Datenbank für die Arbeit bereitgestellt werden muss (wodurch alle anderen Dienste beschädigt werden).
• Ihr Design und Ihre Verwendung von Bibliotheken müssen sich ändern, da es irgendwie bedeutungslos ist, einen Dienst bereitzustellen, wenn diese gemeinsam genutzte Bibliothek aktualisiert werden muss (wodurch alle anderen Dienste beschädigt werden).
• Ihre Protokollierung / Autorisierung / Session - Management / etc muss mich ändern , weil es zu teilen Sachen ziemlich einfach ist , wenn man nur ein Dienst ist, aber anders , wenn Sie eine Reihe von unabhängigen kleinen Dienstleistungen, die das Produkt bilden - und sie gehen zu will Sachen teilen. Oh, und all das geteilte Zeug muss sich damit befassen, möglicherweise auf verschiedenen Versionen zu sein.
• Ihre Kommunikation muss sich ändern. Mit wenigen Diensten können Sie Probleme lösen, bei denen die Kommunikation nicht häufig und / oder langsam erfolgt. Mit Microservices werden sie viel miteinander reden, und eine hohe Latenz wird es nicht schaffen.

Hier ist das Fazit Der einzige offensichtliche Unterschied zwischen SOA und Microservices ist der Begriff von

Intelligente Endpunkte dumme Rohre

Im Gegensatz zu SOA würde dies darauf beruhen, dass Servicekonsumenten und -produzenten nichts davon mitbekommen und das Verkehrsmanagement, die Übersetzung des Nachrichtenformats und die Service-Orchestrierung an externe Systeme delegieren, z. B. ESB, Service Orchestrator, Message Broker.