Microservices vs. SOA: Wo liegt der Unterschied?
Jedes datengetriebene Unternehmen muss sich heute Gedanken darüber machen, wie es Anwendungen am besten entwickeln und bereitstellen kann. Optionen wie eine serviceorientierte Architektur (SOA) und Microservices bieten beim Aufbau und Betrieb von Anwendungen wertvolle Flexibilität, die traditionelle monolithische Ansätze nicht bieten. Es kann jedoch schwierig sein, die Unterschiede zwischen den beiden Ansätzen zu verstehen. Nur wenn Sie diese kennen, können Sie jedoch herausfinden, welche der Optionen die beste Wahl für Ihr Unternehmen ist.
Microservices strukturieren eine Anwendung als eine Reihe von unterschiedlichen Diensten. Jeder dieser Dienste erfüllt einen anderen Zweck. Eine SOA hingegen ist eine Gruppe modularer Dienste, die miteinander „kommunizieren“, um Anwendungen und die Bereitstellung von Anwendungen zu unterstützen. Die beiden Ansätze unterscheiden sich stark, was die Architektur, die gemeinsame Nutzung von Komponenten, die Data-Governance, die Kommunikation und andere Elemente angeht. Diese Punkte müssen berücksichtigt werden, um die richtige Wahl zu treffen. Außerdem beeinflussen diese Unterschiede, wie sich der jeweilige Ansatz auf das gesamte Unternehmen auswirkt.
Was ist eine serviceorientierte Architektur?
Die serviceorientierte Architektur stellt einen Gegenentwurf zu den traditionellen, monolithischen Ansätzen dar. SOA unterteilt die für Anwendungen erforderlichen Komponenten in einzelne Service-Module, die miteinander kommunizieren, um bestimmte Geschäftsziele zu erreichen. Jedes dieser Module ist deutlich kleiner als eine monolithische Anwendung und kann im Unternehmen für verschiedene Zwecke genutzt werden. SOA wird außerdem über die Cloud bereitgestellt und kann Dienste für Infrastruktur, Plattformen und Anwendungen umfassen.
SOA hat zwei Hauptrollen: die eines Dienstanbieters und die eines Dienstkonsumenten. Die Dienstanbieter-Schicht umfasst die verschiedenen an der SOA beteiligten Dienste, während die Konsumentenschicht als Benutzeroberfläche fungiert.
SOA stellt vier verschiedene Arten von Diensten bereit:
- Funktionale Dienste werden für Geschäftsprozesse genutzt
- Enterprise-Dienste implementieren die Funktionalität
- Anwendungsdienste dienen speziell der Entwicklung und Bereitstellung von Apps
- Infrastrukturdienste werden für nicht-funktionale Prozesse wie Sicherheit und Authentifizierung genutzt
Traditionell umfasst eine SOA einen Enterprise Service Bus (ESB), über den diese Dienste koordiniert und gesteuert werden.
Was ist ein Microservice?
Die Microservice-Architektur wird gemeinhin als Weiterentwicklung der SOA betrachtet, da ihre Dienste differenzierter sind und unabhängig voneinander laufen. Falls also einer der Dienste innerhalb einer Anwendung ausfällt, funktioniert die App weiterhin, da jeder Dienst einen bestimmten Zweck erfüllt. Die Dienste in Microservices kommunizieren über Anwendungsprogrammierschnittstellen (APIs) und sind um einen bestimmten Geschäftsbereich herum organisiert. Zusammen bilden die Dienste komplexe Anwendungen.
Da jeder Dienst eigenständig ist, kann eine Microservice-Architektur besser skaliert werden als andere Ansätze für die Erstellung und Bereitstellung von Anwendungen. Dank dieser Eigenschaft zeichnen sich Microservice-Anwendungen außerdem durch eine höhere Fehlertoleranz aus als andere Methoden der Anwendungsentwicklung. Microservices werden häufig in der Cloud erstellt und bereitgestellt. In vielen Fällen werden sie in Containern betrieben.
Microservices vs. SOA: die Unterschiede kennen
Die Hauptmerkmale von SOA und Microservices ähneln sich größtenteils. Beide nutzen eine Cloud- oder Hybrid-Cloud-Umgebung, um Anwendungen bereitzustellen und auszuführen. Beide sind darauf ausgelegt, mehrere Dienste zu kombinieren, die benötigt werden, um Anwendungen zu erstellen und zu verwenden. Und beide zerlegen große, komplizierte Anwendungen in kleinere Teile, die sich flexibler anordnen und bereitstellen lassen. Da sowohl Microservices als auch SOA in Cloud-Umgebungen laufen, können beide skaliert werden, um den modernen Größen- und Geschwindigkeitsanforderungen von Big Data gerecht zu werden.
Es gibt dennoch viele Unterschiede zwischen SOA und Microservices, aufgrund derer sich die beiden Ansätze für unterschiedliche Anwendungsfälle eignen:
| Microservices | SOA | |
|---|---|---|
| Architektur | Darauf ausgelegt, Dienste zu hosten, die unabhängig voneinander laufen können | Darauf ausgelegt, Ressourcen bereitzustellen, die von allen Diensten gemeinsam genutzt werden |
| Gemeinsame Nutzung von Komponenten | Komponenten werden i. d. R. nicht gemeinsam genutzt | Komponenten werden häufig gemeinsam genutzt |
| Granularität | Differenzierte Dienste | Größere, stärker modular aufgebaute Dienste |
| Datenspeicherung | Jeder Dienst kann über einen eigenen Datenspeicher verfügen | Datenspeicher wird von mehreren Diensten gemeinsam genutzt |
| Governance | Zusammenarbeit zwischen Teams erforderlich | Teamübergreifende, gemeinsame Governance-Protokolle |
| Größe und Umfang | Besser für kleinere, webbasierte Anwendungen | Besser für groß angelegte Integrationen |
| Kommunikation | Kommuniziert über eine API-Schicht | Kommuniziert über einen ESB |
| Kopplung und Kohäsion | Begrenzter Kontext für die Kopplung | Ressourcen werden gemeinsam genutzt |
| Remote-Dienste | Nutzt REST und JMS | Nutzt Protokolle wie SOAP und AMQP |
| Bereitstellung | Schnelle und einfache Bereitstellung | Weniger Flexibilität bei der Bereitstellung |
Architektur
Die Microservices-Architektur basiert auf kleineren, differenzierten Diensten, die auf einen einzigen Zweck ausgerichtet sind und unabhängig voneinander laufen können – aber interagieren, um dieselbe Anwendung zu unterstützen. Die Mircoservice-Architektur ist darauf ausgelegt, dass so wenige Dienstressourcen wie möglich gemeinsam genutzt werden. Die SOA umfasst größere, stärker modulare Dienste, die nicht eigenständig sind. Sie ist deshalb so konzipiert, dass die Dienste möglichst viele Ressourcen gemeinsam nutzen.
Gemeinsame Nutzung von Komponenten
Da Microservices eigenständig sind, besteht kaum Bedarf daran, Komponenten gemeinsam zu nutzen. Das macht die Dienste ausfallsicherer. Außerdem ist es für Entwickler einfacher, neuere Versionen bereitzustellen, und einzelne Dienste schneller zu skalieren als im Fall einer SOA.
In einer SOA hingegen ist die gemeinsame Nutzung von Komponenten üblicher. Die Dienste nutzen insbesondere einen gemeinsamen ESB. Wenn also ein Dienst Probleme im Zusammenhang mit dem ESB hat, kann das die Leistungsfähigkeit der anderen Dienste beeinträchtigen, die ebenfalls mit diesem ESB verbunden sind.
Granularität
Die Dienste einer SOA sind groß: Einige der modularen Dienste ähneln monolithischen Anwendungen. Da jeder Dienst skalierbar ist, haben SOA normalerweise einen breiten Fokus.
Die Microservices sind granularer. Das bedeutet, dass einzelne Dienste sich dadurch auszeichnen, dass sie eine spezifische Aufgabe ausführen. Durch Kombination dieser Aufgaben entsteht eine Anwendung.
Datenspeicherung
Im Fall von Microservices verfügen die individuellen Dienste in der Regel über einen eigenen Datenspeicher. Bei einer SOA teilen sich fast alle Dienste gemeinsame Datenspeichereinheiten.
Da der Datenspeicher in diesem Fall gemeinsam genutzt wird, können SOA-Dienste freigegebene Daten wiederverwenden. So kann der Nutzen der Daten maximiert werden, indem verschiedenen Geschäftsbereichen ein und dieselben Daten oder Anwendungen bereitgestellt werden. Das führt jedoch auch dazu, dass die Dienste stärker gekoppelt und voneinander abhängig sind.
Governance
Bei einem SOA-Konzept werden Ressourcen gemeinsam genutzt. Auch die Data-Governance-Mechanismen und -Standards gelten für alle Dienste.
Da die Dienste im Fall von Microservices unabhängig sind, sind einheitliche Data-Governance-Mechanismen nicht möglich. Die Governance ist bei diesem Ansatz wesentlich entspannter, da die Personen, die die Microservices bereitstellen, frei entscheiden können, welche Governance-Regeln für die einzelnen Dienste gelten. Damit ist eine bessere Zusammenarbeit zwischen Teams möglich.
Größe und Umfang
Die größten Unterschiede zwischen Microservices und SOA sind die Größe und der Umfang. Mircoservices können nur für Projekte bis zu einer bestimmten Größe und einem bestimmten Umfang eingesetzt werden, da sie differenziert ausgelegt sind. Aufgrund ihres relativ geringen Leistungsumfangs sind Microservices für Entwickler gut geeignet. Im Gegensatz dazu eignet sich eine SOA besser für komplexe Integrationen unterschiedlicher Dienste, da sie größer und umfangreicher ist. Eine SOA kann Dienste verbinden, um die unternehmensübergreifende Zusammenarbeit und andere große Integrationen zu ermöglichen.
Kommunikation
Die Kommunikation erfolgt im Fall einer SOA in der Regel über einen ESB. D. h., der ESB ist das Medium, über das sich die Dienste miteinander „unterhalten“. Ein ESB kann die Kommunikation der Dienste einer SOA jedoch auch ausbremsen. Microservices nutzen einfachere Messaging-Systeme, wie z. B. APIs, die sprachunabhängig sind und eine schnellere Kommunikation ermöglichen.
Kopplung und Kohäsion
Während eine SOA darauf basiert, dass Komponenten gemeinsam genutzt werden, basieren Microservices auf dem Konzept des „Bounded Context“. Bounded Context ist eine Form der Kopplung einer Komponente und ihrer Daten, die ohne viele weitere Abhängigkeiten auskommt. Damit verringert sich der Bedarf, Ressourcen gemeinsam zu nutzen. Gekoppelt werden können im Fall von Microservices auch das Betriebssystem und das Messaging, die sich in der Regel in einem Container befinden.
Diese Art der Kopplung führt zu einer hohen Kohäsion. Etwaige Schwachstellen in einem bestimmten Dienst können schnell isoliert und behoben werden, bevor sie die Leistung der Anwendung beeinträchtigen. Da der Fokus einer SOA auf der gemeinsamen Nutzung liegt, sind die Systeme anfälliger für Fehler und langsamer.
Remote-Dienste
Eine SOA und Microservices nutzen unterschiedliche Protokolle, um auf Remote-Dienste zuzugreifen. Zu den wichtigsten Remote-Zugriffsprotokollen für SOA gehören Simple Object Access Protocol (SOAP) und Messaging-Protokolle wie Advanced Messaging Queuing Protocol (AMQP) und Microsoft Messaging Queuing (MSMQ).
Die gängigsten Protokolle für Microservices sind Representational State Transfers (REST) und einfache Messaging-Protokolle wie Java Messaging Service (JMS). REST-Protokolle werden häufig in Kombination mit APIs verwendet. Die Protokolle für Microservices sind homogener als die für SOA, die in der Regel bei einer heterogenen Interoperabilität eingesetzt werden.
Bereitstellung
Die Bereitstellung ist ein weiterer großer Unterschied zwischen Microservices und SOA. Da die Dienste in Microservices kleiner und weitgehend unabhängig voneinander sind, lassen sie sich viel schneller und einfacher bereitstellen als die Dienste in einer SOA. Aus den genannten Gründen ist es auch einfacher, Dienste in Microservices zu erstellen.
SOA-Bereitstellungen gestalten sich komplexer, weil beim Hinzufügen eines Diensts die gesamte Anwendung neu erstellt und bereitgestellt werden muss, da die Dienste miteinander gekoppelt sind.
Microservices vs. SOA: Was ist die richtige Wahl für Ihr Unternehmen?
Microservices oder SOA? Muss man entscheiden, welcher Ansatz für ein bestimmtes Unternehmen besser geeignet ist, gilt es, mehrere Punkte zu beachten. SOA ist ein modulares Konzept, bei dem monolithische Anwendungen in kleine Komponenten heruntergebrochen werden. Microservices hingegen stellen einen kleineren, differenzierteren Ansatz dar, mit dem das gleiche Ziel verfolgt wird. Beide Architekturen werden routinemäßig in der Cloud ausgeführt, was für mehr Flexibilität bei der Erstellung und Bereitstellung von Anwendungen sorgt. Welcher Ansatz sich am besten eignet, hängt von den individuellen Bedürfnissen des jeweiligen Unternehmens und dem jeweiligen Anwendungsfall ab.
Die Realität ist jedoch, dass sowohl eine SOA als auch Microservices für verschiedene Anwendungsfälle im selben Unternehmen eingesetzt werden können. Talend Data Fabric ermöglicht Unternehmen durch Cloud- oder Hybrid-Cloud-Bereitstellungen den schnellen Zugriff auf Microservices und eine SOA. Als umfassende Anwendungssuite gibt Ihnen Talend Data Fabric die Mittel an die Hand, die sie benötigen, um Datenressourcen in der Cloud zu verwalten und eine sichere Datenintegration zu ermöglichen. Testen Sie Talend Data Fabric noch heute, um den Bau und die Bereitstellung von Anwendungen einfacher zu gestalten.
