SOA vs. Microservices: Was ist der Unterschied?

Wenn Sie in der IT oder im Cloud Computing arbeiten, kennen Sie wahrscheinlich die Debatte zwischen serviceorientierter Architektur (SOA) und Microservice. Schließlich spricht heutzutage jeder über Microservices und flexibel Anwendungen.

Auf den ersten Blick klingen die beiden Ansätze ähnlich, und in gewisser Weise sind sie es auch. Beide beinhalten Cloud- oder Hybrid Cloud -Umgebungen für flexible Anwendung und -Bereitstellung, und beide können skaliert werden, um der Geschwindigkeit und den Betriebsanforderungen von Big Data gerecht zu werden. Beide Methoden zerlegen große, komplexe Anwendungen in kleine, flexible Komponenten, mit denen sich leichter arbeiten lässt. Und beide unterscheiden sich von einer traditionellen, monolithischen Architektur darin, dass jeder Dienst seine eigene Verantwortung trägt.

Doch selbst bei diesen wichtigen Gemeinsamkeiten offenbart eine genauere Betrachtung der beiden Ansätze wichtige Unterschiede.

Die serviceorientierte Architektur (SOA) ist ein unternehmensweiter Ansatz für die Softwareentwicklung von Anwendungskomponenten, der wiederverwendbare Softwarekomponenten oder Dienste nutzt. In der SOA-Softwarearchitektur besteht jeder Dienst aus dem Code und den Integrationen, die zur Ausführung einer bestimmten Geschäftsfunktion erforderlich sind – zum Beispiel zur Überprüfung der Kreditwürdigkeit eines Kunden, zur Anmeldung auf einer Website oder zur Bearbeitung einer Anwendung.

Die Serviceschnittstellen bieten eine lose Kopplung, was bedeutet, dass sie mit wenig oder gar keinem Wissen darüber aufgerufen werden können, wie die Integration darunter implementiert ist. Aufgrund dieser losen Kopplung und der Art und Weise, wie die Dienste veröffentlicht werden, können Entwicklungsteams durch die Wiederverwendung von Komponenten in anderen Anwendungen im gesamten Unternehmen Zeit sparen. Dies ist sowohl ein Nutzen als auch ein Risiko. Aufgrund des gemeinsamen Zugriffs auf den Enterprise Service Bus (ESB) kann sich das, falls Probleme auftreten, auch auf die anderen verbundenen Dienste auswirken.

XML-Daten sind ein wichtiger Bestandteil von Lösungen, die auf einer SOA-Architektur basieren. XML-basierte SOA-Anwendungen können z.B. zur Erstellung von Webservices verwendet werden.

SOA entstand Ende der 1990er Jahre und stellt eine wichtige Phase in der Entwicklung von Anwendungen und Integration dar. Bevor SOA eine Option war, erforderte die Verbindung einer monolithischen Anwendung mit Daten oder Funktionen in einem anderen System eine komplexe Point-to-Point-Integration, die Entwickler für jedes neue Entwicklungsprojekt neu erstellen mussten. Durch die Bereitstellung dieser Funktionen über SOA entfällt die Notwendigkeit, die tiefe Integration jedes Mal neu zu erstellen.

SOA bietet vier verschiedene Servicetypen an:

1. Funktionale Services (d. h. Business Services), die für Geschäftsanwendungen von entscheidender Bedeutung sind.
2. Enterprise-Dienste, die der Implementierung von Funktionen dienen.
3. Anwendungsdienste, die für die Entwicklung und Bereitstellung von Apps verwendet werden.
4. Infrastrukturservices, die für Backend-Prozesse wie Sicherheit und Authentifizierung unverzichtbar sind.

Jeder Service besteht aus drei Komponenten:

1. Die Schnittstelle, die definiert, wie ein Dienstanbieter Anfragen von einem Servicenutzer ausführt.
2. Der Vertrag, der festlegt, wie der Dienstanbieter und der Servicenutzer interagieren sollen.
3. Die Implementierung, die der Servicecode ist.

SOA-Dienste können kombiniert werden, um übergeordnete Dienste und Anwendungen zu erstellen.

Wie SOA bestehen Microservice-Architekturen aus lose gekoppelten, wiederverwendbaren und spezialisierten Komponenten, die oft unabhängig voneinander arbeiten. Microservices nutzen zudem ein hohes Maß an Kohäsion, auch bekannt als Bounded Context. Eingeschränkter Kontext bezieht sich auf die Beziehung zwischen einer Komponente und ihren Daten als eigenständige Entität oder Einheit mit wenigen Abhängigkeiten. Anstatt unternehmensweit eingeführt zu werden, kommunizieren Microservices in der Regel über Programmierschnittstellen (APIs), um individuelle Anwendungen zu erstellen, die eine bestimmte Geschäftsfunktionalität ausführen. Dieser Ansatz macht sie flexibler, skalierbar und resilient, insbesondere für bestimmte Geschäftsbereiche. In der Regel ist Java die Programmiersprache der Wahl für die Entwicklung von Microservices. Es können auch andere Programmiersprachen verwendet werden, wie Golang und Python.

Microservices sind ein echter cloudnativ architektonischer Ansatz, der oft in Containern betrieben wird, was sie für die Erstellung unabhängiger Dienste skalierbar und portabler macht. Teams können Microservices verwenden, um Code einfacher zu aktualisieren, unterschiedliche Stacks für verschiedene Komponenten zu verwenden und die Komponenten unabhängig voneinander zu skalieren. Dieser Ansatz reduziert die Verschwendung und die Kosten, die mit dem Skalieren ganzer Anwendungen verbunden sind, weil eine einzelne Funktion möglicherweise zu stark belastet wird. Aufgrund ihrer Unabhängigkeit bieten Microservices Dienste an, die fehlertoleranter sind als die Alternativen.

Weitere Informationen zur Microservices-Architektur finden Sie im folgenden Video:

Der Hauptunterschied zwischen den beiden Ansätzen liegt im Umfang. Vereinfacht gesagt, hat die serviceorientierte Architektur (SOA) einen unternehmensweiten Geltungsbereich, während die Microservice-Architektur einen Anwendungsgeltungsbereich hat.

Viele der Kernprinzipien der beiden Ansätze werden unvereinbar, wenn Sie diesen Unterschied vernachlässigen. Wenn Sie den Unterschied im Umfang akzeptieren, werden Sie vielleicht schnell erkennen, dass sich die beiden potenziell ergänzen können, anstatt miteinander zu konkurrieren.

Hier sind ein paar Anwendungsfälle, in denen diese Unterscheidung ins Spiel kommt:

In SOA ist die Wiederverwendbarkeit von Integrationen das Hauptziel, und auf Unternehmensebene ist es unerlässlich, ein gewisses Maß an Wiederverwendung anzustreben. Wiederverwendbarkeit und gemeinsame Nutzung von Komponenten in einer SOA-Architektur erhöhen die Skalierbarkeit und Effizienz.

In der Microservices-Architektur führt die Erstellung einer Microservice-Komponente, die zur Laufzeit in einer Anwendung wiederverwendet wird, zu Abhängigkeiten, die die Agilität und Belastbarkeit reduzieren. Komponenten von Microservices bevorzugen im Allgemeinen die Wiederverwendung von Code durch Kopieren und Akzeptieren von Datenduplikaten, um die Entkopplung zu verbessern.

Die wiederverwendbaren Dienste in SOA sind im gesamten Unternehmen verfügbar, indem überwiegend synchrone Protokolle wie RESTful-APIs verwendet werden.

Innerhalb einer Microservice-Anwendung führen synchrone Aufrufe jedoch zu Echtzeit-Abhängigkeiten, was zu einem Verlust an Ausfallsicherheit führt. Diese Abhängigkeiten können auch zu Latenzzeiten führen, die die Leistung beeinträchtigen. Innerhalb einer Microservice-Anwendung werden Interaktionsmuster bevorzugt, die auf asynchroner Kommunikation basieren, wie z.B. das Event Sourcing, bei dem ein Publish/Abonnieren-Modell verwendet wird, damit eine Microservice-Komponente über Änderungen an den Daten einer anderen Komponente auf dem Laufenden bleibt.

Ein klares Ziel der Bereitstellung von Diensten in einer SOA besteht darin, dass alle Anwendungen Daten direkt an ihrer primären Quelle synchron abrufen und ändern können, wodurch die Notwendigkeit der Pflege komplexer Datensynchronisationsmuster reduziert wird.

In Microservice-Anwendungen hat im Idealfall jeder Microservice lokalen Zugriff auf alle Daten, die er benötigt, um seine Unabhängigkeit von anderen Microservices – und sogar von anderen Anwendungen – zu gewährleisten, auch wenn dies eine gewisse Duplizierung von Daten in anderen Systemen bedeutet. Natürlich erhöht diese Duplizierung die Komplexität, also muss sie gegen die Gewinne an Agilität und Leistung abgewogen werden, aber das wird als Realität des Microservice-Designs akzeptiert.

• Kommunikation: In einer Microservice-Architektur wird jeder Dienst unabhängig entwickelt und verfügt über sein eigenes Kommunikationsprotokoll. Bei SOA muss jeder Dienst einen gemeinsamen Kommunikationsmechanismus teilen, der als Enterprise Service Bus (ESB) bezeichnet wird. SOA verwaltet und koordiniert die Dienste, die es über den ESB bereitstellt. Der ESB kann jedoch zu einem Single Point of Failure für das gesamte Unternehmen werden, und wenn ein einzelner Dienst ausfällt, kann das gesamte System betroffen sein.
• Interoperabilität: Um die Dinge einfach zu halten, verwenden Microservices leichtgewichtige Messaging-Protokolle wie HTTP/REST (Representational State of Transfers) und JMS (Java Messaging Service). SOAs sind offener für heterogene Messaging-Protokolle wie SOAP (Simple Object Access Protocol), AMQP (Advanced Messaging Queuing Protocol) und MSMQ (Microsoft Messaging Queuing).
• Servicegranularität: Microservice-Architekturen bestehen aus hochspezialisierten Diensten, von denen jeder darauf ausgelegt ist, eine Sache sehr gut zu machen. Die Dienste, aus denen sich SOAs zusammensetzen, können dagegen von kleinen, spezialisierten Diensten bis hin zu unternehmensweiten Diensten reichen.
• Geschwindigkeit: Durch die Nutzung der Vorteile einer gemeinsamen Architektur vereinfachen SOAs die Entwicklung und Fehlerbehebung. Dies führt jedoch auch dazu, dass SOAs langsamer arbeiten als Microservice-Architekturen, bei denen die gemeinsame Nutzung zugunsten der Duplizierung minimiert wird.
• Governance: Die Art der SOA, die gemeinsam genutzte Ressourcen umfasst, ermöglicht die Umsetzung gemeinsamer Data-Governance-Standards für alle Services. Die unabhängige Natur von Microservices ermöglicht keine konsistente Data Governance. Dies bietet eine größere Flexibilität für jeden Dienst, was zu einer besseren Zusammenarbeit im gesamten Unternehmen führen kann.
• Speicher: SOA und Microservices unterscheiden sich auch in Bezug auf die Zuweisung von Speicherressourcen. Die SOA-Architektur umfasst in der Regel eine einzelne Datenspeicherschicht, die von allen Diensten innerhalb einer bestimmten Anwendung gemeinsam genutzt wird, während Microservices einen Server oder eine Datenbank für die Datenspeicherung für jeden Dienst bereitstellen, der sie benötigt.

Für einige Unternehmen ist die SOA-Architektur ein Sprungbrett, um den Monolithen zu ersetzen und eine flexiblere und agilere Umgebung zu schaffen. SOA-Dienste können in einer großen Umgebung entwickelt und genutzt werden, aber sie entsprechen nicht den spezifischen Bedürfnissen einzelner Unternehmen, die Geschäftsprozesse in ihrem Zuständigkeitsbereich behandeln möchten. DevOps kann einem Unternehmen beim Übergang von einer SOA-Architektur zu Microservices helfen, um bestimmte Bedürfnisse zu erfüllen.

Architektonische Stile haben ihre Vorteile. Wie können Sie also herausfinden, welcher Stil für Ihre Zwecke am besten geeignet ist? Im Allgemeinen hängt es davon ab, wie groß und vielfältig Ihre Anwendung ist.

Sowohl SOA als auch Microservices können Automatisierung nutzen, um Geschäftsprozesse zu beschleunigen. Größere, vielfältigere Umgebungen tendieren eher zu serviceorientierter Architektur (SOA), die die Integration zwischen heterogenen Anwendungen und Messaging-Protokollen über einen Enterprise-Service-Bus (ESB) unterstützt. Kleinere Umgebungen, einschließlich Web- und mobiler Anwendungen, benötigen keine so robuste Kommunikationsschicht und lassen sich durch die Verwendung einer Microservice-Architektur leichter entwickeln.

Einige werden darauf hinweisen, dass die Debatte SOA vs. Microservices viel komplizierter ist, und das stimmt. Es steckt noch viel mehr dahinter. Für eine detailliertere technische Erläuterung dieser Nuancen empfehlen wir Ihnen die Artikel im Learn Hub zu SOA und Microservice, die eine Fülle von detaillierten Informationen enthalten. Aus geschäftlicher Sicht ist der Umfang jedoch der entscheidende Unterschied.

• Was sind Microservices?
• Was ist SOA (serviceorientierte Architektur)?
• Agilität versus Wasserfall

Um mehr über die Erstellung flexibler Anwendungen zu erfahren, laden Sie Ihr kostenloses Exemplar des E-Books Agile Applications Architecture herunter.