Für Entwickler spielen Flexibilität, Skalierbarkeit und Geschwindigkeit eine immer größere Rolle. Daher gelten herkömmliche monolithische Software-Entwicklungsmodelle größtenteils als veraltet. Um die aktuellen Anforderungen zu erfüllen, haben sich zwei Modelle etabliert, mit denen große komplexe Anwendungen effektiv und effizient entwickelt und ausgeführt werden können: Serviceorientierte Architektur (SOA) und Mikroservices.

Welches Modell eignet sich am besten für Ihr Unternehmen? Auf den ersten Blick erscheinen die beiden Ansätze sehr ähnlich. Es gibt jedoch einige deutliche Unterschiede, die Entwicklerteams bei der Wahl des für sie idealen Modells berücksichtigen sollten. In diesem Artikel erläutern wir, was SOA und Mikroservices sind und worin die wichtigsten Unterschiede liegen. Außerdem sehen wir uns jeweils einige Anwendungsszenarien an.

SOA und Mikroservices – ein Überblick

Bevor wir uns den Unterschieden zwischen SOA und Mikroservices widmen, schauen wir uns zunächst an, worin sie sich ähneln. SOA und Mikroservices besitzen folgende Gemeinsamkeiten:

• Große komplexe Anwendungen sind in kleinere, flexiblere Komponenten aufgegliedert
• Verbesserte Skalierbarkeit, um die Entwicklung und Bereitstellung von Anwendungen zu beschleunigen
• Agile Entwicklungsmodelle, die auf einer Cloud- oder Hybrid-Cloud-Umgebung basieren

Doch worin unterscheiden sie sich? Genau genommen gibt es mehrere wichtige Unterschiede zwischen SOA und Mikroservices in Bezug auf Umfang, Architektur, Governance und Kommunikation. Werfen wir nun einen genaueren Blick auf die Modelle und vergleichen sie miteinander.

Was ist SOA?

Serviceorientierte Architektur (SOA) ist ein cloudbasiertes Software-Entwicklungsmodell, das die erforderlichen Anwendungskomponenten in einzelne Service-Module aufgliedert. Diese Module sind kleiner und flexibler als monolithische Anwendungen, wodurch sie leichter zu handhaben sind.

SOA-Services

Es gibt vier Arten von Services, die durch SOA bereitgestellt werden:

• Funktionale Services oder geschäftliche Services, die sich auf Geschäftsanwendungen oder Unternehmensabläufe beziehen
• Unternehmensservices zur Implementierung von Funktionen
• Anwendungsservices, die sich vor allem auf die Entwicklung und Bereitstellung von Anwendungen beziehen
• Infrastrukturservices, die nicht-funktionale Prozesse im Backend wie Sicherheit, Zugriff und Authentifizierung betreffen

SOA-Komponenten

Alle SOA-Services bestehen aus drei Komponenten:

• Die Schnittstelle, die beschreibt, wie der Service-Anbieter die Anfragen des Nutzers handhabt
• Der Vertrag, in dem die Bedingungen für die Interaktion zwischen Anbieter und Nutzer festgelegt sind
• Die Implementierung bzw. der Service-Code

SOA-Services können zudem miteinander kombiniert werden, um komplexere Services und Anwendungen zu erstellen. In der Regel verbindet SOA diese Module durch eine robuste Kommunikations- und Kontrollschicht namens Enterprise Service Bus (ESB).

SOA-Entkopplung

Die SOA-Struktur basiert auf dem Konzept der „losen Kopplung“. Das bedeutet, dass die Komponenten im Gegensatz zur monolithischen Architektur keine komplexe Punkt-zu-Punkt-Integration benötigen. Dadurch können die verschiedenen Komponenten über den ESB miteinander kommunizieren, auch wenn sie auf anderen Plattformen oder Programmiersprachen basieren. Aus diesem Grund kann das Entwicklungsteam Module für verschiedene Aufgaben im gesamten Unternehmen wiederverwenden, sodass weniger Zeit für den Umbau der einzelnen Komponenten von Web-Anwendungen benötigt wird.

Einen Nachteil hat SOA allerdings: Wenn eine Komponente einen Fehler hat, wirkt sich dies auf alle Instanzen aus, in denen sie implementiert ist. Daher können Probleme im Code oder in einer anderen Komponente eines Moduls weitreichende Konsequenzen für das gesamte Unternehmen haben, wenn sie im großen Maßstab bereitgestellt werden.

Was ist ein Mikroservice?

Die Mikroservices-Architektur gilt als Nebenprodukt der SOA. Sie teilt ebenfalls große Anwendungen in kleinere, flexiblere Komponenten auf. Dies erfolgt jedoch noch granularer. Zudem wird dabei jede Einheit auf eine sehr spezielle Geschäftsfunktion ausgerichtet.

Kontextgrenzen

Mikroservices funktionieren nach einem Prinzip namens Kontextgrenzen, d. h. eine Komponente und die dazugehörigen Daten werden als eigenständige Einheit oder als Einheit mit bestimmten Abhängigkeiten behandelt. Anders ausgedrückt: Services werden voneinander abgekoppelt und funktionieren unabhängig. Wenn also ein Web-Service in einer Anwendung ausfällt, funktionieren andere mit der Anwendung verbundene Services wie gewohnt weiter.

API

Beim Mikroservices-Modell nutzen die Services eine API (Application Programming Interface) zur Kommunikation mit anderen Services, Komponenten und Anwendungen. Durch die von der API hergestellte Verbindung können unabhängige Services zu einer komplexen Anwendung zusammengeschlossen werden.

Container-Orchestrierung

Da die Services bei einer Mikroservices-Architektur unabhängig sind und bei diesem Modell in der Regel Container genutzt werden, bietet der Mikroservices-Ansatz im Vergleich zu anderen Software-Entwicklungsmodellen, einschließlich SOA, meist eine höhere Skalierbarkeit, Portabilität und Fehlertoleranz.

Mikroservices und SOA im Vergleich: die Unterschiede

Der wesentliche Unterschied zwischen SOA und Mikroservices liegt im Architekturumfang. Beim SOA-Modell werden die Services oder Module im gesamten Unternehmen gemeinsam genutzt und wiederverwendet. Dagegen baut eine Mikroservices-Architektur auf einzelnen Services auf, die unabhängig voneinander funktionieren. Anders ausgedrückt hat SOA einen unternehmensweiten Umfang, während Mikroservices auf eine Anwendung beschränkt sind.

Daraus ergeben sich wiederum mehrere maßgebliche Unterschiede zwischen den beiden Modellen:

Wiederverwendbarkeit oder Datenduplizierung

Beim SOA-Modell verwenden Entwickler die Komponenten mehrfach, um die Skalierbarkeit und Effizienz zu verbessern. Der gleiche Ansatz führt beim Mikroservices-Modell jedoch meist zu einer geringeren Agilität und Fehlertoleranz, da durch die Wiederverwendung einer Komponente Abhängigkeiten bei mehreren anderen Services entstehen. Bei einer Mikroservices-Architektur verwenden Entwickler stattdessen den Code wieder oder duplizieren die Daten, um die Effizienz zu steigern und ein hohes Maß an Unabhängigkeit zu gewährleisten.

Synchrone Abrufe oder asynchrone Kommunikation

Bei SOA werden die Services über synchrone Protokolle im gesamten Unternehmen zur Verfügung gestellt, meist durch RESTful-APIs. Allerdings verursachen synchrone Abrufe in einer Mikroservices-Architektur Echtzeit-Abhängigkeiten, die wiederum die Zuverlässigkeit und Resilienz verringern. Um diese Probleme zu vermeiden und die Leistung nicht zu beeinträchtigen, nutzen Entwickler asynchrone Kommunikation mithilfe von Techniken wie Event Sourcing oder dem Publish-Subscribe-Modell.

Quelldaten oder lokale Daten

Beim SOA-Modell sollten alle Anwendungen Daten auf Quellebene zur gleichen Zeit empfangen und aktualisieren können, weshalb SOA-Services auf keine komplexen Datensynchronisationsmodelle zurückgreifen müssen. Doch dieser Ansatz schafft auch serviceübergreifende Abhängigkeiten, was bei einer Mikroservices-Architektur von Nachteil ist. Um die Unabhängigkeit der Services und Anwendungen zu gewährleisten, wird beim Mikroservices-Modell lokaler Zugriff auf die von den Services benötigten Daten gewährt. Dadurch entstehen Instanzen mit Datenduplikaten und infolgedessen Komplexität. Allerdings werden dadurch Abhängigkeiten vermieden, die die Leistung beeinträchtigen könnten.

ESB oder API

Beim SOA-Modell erfolgt die Organisation und Koordinierung der Services über den gemeinsamen Kommunikationskanal Enterprise Service Bus (ESB). Da die gesamte Kommunikation über den ESB läuft, entsteht an dieser Stelle ein einziger Ausfallpunkt (Single Point of Failure) für alle Services. Um dies zu vermeiden und einen unabhängigen Ablauf zu gewährleisten, kommunizieren Mikroservices über APIs.

Die folgende Tabelle bietet einen Überblick über diese und weitere Unterschiede:

Mikroservices und SOA im Vergleich: Was ist besser für Ihr Unternehmen?

SOA und Mikroservices haben ihre jeweiligen Vor- und Nachteile. Die Wahl der passenden Architektur für Ihr Unternehmen hängt meist von Ihrem Anwendungsszenario sowie von den verfügbaren Ressourcen, dem IT-Reifegrad und den geschäftlichen Anforderungen ab.

Wann SOA die richtige Wahl für Sie ist

Große und heterogene Umgebungen profitieren eher vom SOA-Modell, da es umfassende Integrationen über den ESB ermöglicht. Dadurch können Entwickler heterogene Anwendungen und eine Vielzahl an Nachrichtenprotokollen verbinden, während jede Anwendung weiterhin unabhängig bleibt.

Allerdings sind SOA-Bereitstellungen häufig langsamer und komplexer als Mikroservices, da mehrere Services miteinander gekoppelt werden. Deshalb muss beim Hinzufügen von neuen Services oder Funktionen in einigen Fällen die gesamte Anwendung neu bereitgestellt werden.

Dies sind Anwendungsszenarien, die für SOA gut geeignet sind:

• Herstellung der Kommunikation zwischen mehreren unabhängigen Anwendungen
• Entwicklung eines Services mit der ausdrücklichen Absicht, diesen im Unternehmen ein oder zwei Mal wiederzuverwenden
• Unterstützung einer Anwendung mit mehreren Datenquellen
• Freigabe von Daten oder Funktionen für externe Clients
• Entwicklung serverloser Funktionen

Wann Mikroservices die richtige Wahl für Sie sind

Eine Mikroservices-Architektur lässt sich im Vergleich zu SOA in der Regel einfacher und schneller entwickeln. Das liegt daran, dass die Services an sich kleiner sind und daher einfacher und schneller bereitgestellt werden können.

Unternehmen, die mit kleinen, weniger komplexen Umgebungen arbeiten und keine robuste Kommunikationsplattform benötigen, machen meist die Erfahrung, dass ein Mikroservices-Ansatz ihnen mehr Geschwindigkeit, Flexibilität sowie Resilienz bietet und zudem Kosten sowie Komplexität verringert.

Mikroservices sind für folgende Szenarien ideal:

• Relativ simple Projekte, die leicht aufgeteilt werden können
• Komplexe Anwendungen, die bereits aufgeteilt wurden oder sich leicht aufteilen lassen
• Unternehmen, die Prozesse für agile Entwicklung und kontinuierliche Bereitstellung einführen möchten
• Unternehmen, die ihre Cloud-Computing-Ressourcen optimieren möchten oder müssen, insbesondere durch Container
• Anwendungen, die mehrere Frameworks, Sprachen und Technologien in derselben Umgebung nutzen

Erfahren Sie mehr über CrowdStrike-Lösungen für Cloud-Sicherheit und vereinbaren Sie eine Demo, um festzustellen, welche Lösung sich für die Anforderungen Ihres Unternehmens am besten eignet.