Was ist der Unterschied zwischen SOA und einer Microservice Architektur?

Das Konzept von Microservices erhält viel Aufmerksamkeit. Es stellt sich daher unweigerlich die Frage: Was ist der Unterschied zwischen einer serviceorientierten Architektur (SOA) und einer Microservice Architektur? Sucht man im Internet nach Antworten, tauchen Kommentare wie diese auf:

• „Microservices sind SOA, nur richtig umgesetzt.“
• „SOA ist ein langweiliger Unternehmensansatz, dagegen sind Microservices ein cooler Hacker-Ansatz.“
• „Microservice Architekturen sind Spezialisierungen von SOA.“
• „Das SOA-Paradigma bietet viel Spielraum für Interpretationen.“
• „Es gibt keine Unterschiede.“

In all diesen Kommentaren steckt ein Funken Wahrheit, je nachdem, welchen Standpunkt man vertritt. Das Problem ist, dass jeder einen anderen Standpunkt zu SOA hat, der darauf basiert, welche Technologie er verwendet, mit welchen Beratern er zusammenarbeitet oder welche Blogs und Foren er verfolgt.

OASIS hat daher ein SOA-Referenzmodell kreiert, um eine konsistente Definition für jeden zu bieten. Mit der Zeit ließ allerdings der Hype um SOA nach und die Aufmerksamkeit der Entwickler verschob sich auf andere Themen.

Aufgrund meiner Erfahrungen habe ich festgestellt, dass die meisten Unternehmen, die dem SOA-Hype gefolgt sind, keine wirkliche serviceorientierte Architektur, sondern eine servicebefähigende Architektur aufgebaut haben. In meinem Verständnis ist der Service das Kernkonzept von SOA. Eine servicebefähigende Architektur ist dagegen etwas anderes, da hier die Integration über Serviceschnittstellen ermöglicht wird (wie bei monolithischen Anwendungen). Daher bekamen Microservices in letzter Zeit erhöhte Aufmerksamkeit.

Verbindet man lediglich Serviceschnittstellen mit einem existierenden System, ändert aber nicht die Entwicklungs- und Geschäftsprozesse auf einer granulareren Ebene, führt dies zu ungewollten Veränderungen. In einem Blogeintrag von Martin Fowler zum Thema Microservices, weist der Softwareentwickler auf diese Entwicklung hin, wobei Fowler deutlich macht, dass Microservices den Kern dieser Veränderungen bilden.

Mit all den Fortschritten bei DevOps und Cloud-basierten Services im Vergleich zu den Anfängen von SOA, ist es für Unternehmen heute sehr viel einfacher, die Bedeutung dieses Aspekts zu realisieren als vor zehn oder 15 Jahren. Doch haben nicht einige Entwickler bereits von zehn oder 15 Jahren auf das gleiche Konzept hingewiesen? Ja, haben sie. Haben die Unternehmen auf sie gehört? Nein, haben sie nicht. Mittlerweile hat sich das geändert.

Aus technologischer Sicht sind die drei wichtigsten Unterschiede zwischen SOA und einer Microservice Architektur:

1. Bei einer Microservice Architektur ist es unwahrscheinlich, dass servicebefähigende Plattformen eingesetzt werden.
2. In einer Microservice Architektur gibt es normalerweise keine schwergewichtigen Applikations-Server.
3. Microservices haben in der Regel automatisierte Infrastrukturprozesse integriert.

Ich benutze dabei bewußt Wörter wie unwahrscheinlich oder normalerweise, da es keine absoluten Regeln zu einem bestimmten Tech-Stack gibt. Vielmehr weist Fowler in seinem Artikel darauf hin, dass die Technologie viele Freiheiten erlaubt.

Die Verwendung einer servicebefähigenden Plattform ist ein Indikator dafür, dass man eher auf das Erreichen von Integrationsvorteilen bedacht ist als auf die Vorteile des operativen Managements. Wie Sie vielleicht festgestellt haben, habe ich nicht den Begriff Enterprise Service Bus (ESB) verwendet, da ESBs wie Schweizer Taschenmesser sind. Ein ESB wird in der Regel als reiner Vermittler für operative Flexibilität (zum Beispiel für die Verwaltung des Routings bei einer sich ständig verändernden Zahl von Entwicklungen) oder Perimeter-Security eingesetzt. Allerdings kann es trotzdem eine Rolle bei Microservices spielen. Wenn Sie ESB nutzen, um Services für Legacy- oder monolithischen Anwendungen mit schwachen Integrationsmöglichkeiten einzusetzen, ist das ein anderer Aspekt.

Wie bei Applikations-Servern, sind dies Überbleibsel aus einer Zeit großer Server, bei denen keine Virtualisierung möglich war, die eine langsame Infrastruktur bereitstellten und als nur die Wahl zwischen Java EE oder .NET bestand. Aufgrund moderner, handelsüblicher Server, dem allgegenwärtigen Einsatz virtueller Maschinen (VM), vollautomatischen Bereitstellungen, skriptbasierter, serverseitiger Softwareentwicklung und fortschrittlichen Open-Source-Bibliotheken besteht kein Bedarf mehr an Applikations-Servern, die sehr viele Anwendungen bereitstellen.

Hinzu kommt, dass bestimmte Operationen im Vergleich zu anderen hochskaliert werden müssen, so dass alles auf eine granularere Management-Einheit hindeutet. Muss man nur eine Anwendung einsetzen, ist nicht viel mehr als ein Bertriebssystem und ein solider Satz von Bibliotheken nötig, um mit anderen Systemen zu kommunizieren. Kommt zusätzlich Docker zum Einsatz, erreicht man eine Entkopplung von der physischen Infrastruktur, was eine unglaubliche Flexibilität bei der Softwarebereitstellung bietet.

Letztlich sollte man sich meiner Meinung nach nicht zu sehr darauf fokussieren, ob nun SOA, eine Microservice Architektur oder ein Mix aus beiden eingesetzt wird. Entwickeln Sie nicht eine völlig neue Software, können Sie einfach auf Best Practices zurückgreifen. Schauen Sie sich dafür ihr bestehendes System und die Muster ihrer zur Verfügung gestellten Funktionen von Zeit zu Zeit genau an.

Wenn es Sinn macht, dass Sie bestimmte Funktionen abspalten, weil Teile ihrer Applikation deutlich häufiger genutzt oder verändert werden als andere, sollten Sie die Prinzipen von Microservices einsetzen. Müssen das System und alle Funktionen dagegen komplett geändert werden, führt das Abspalten einiger Funktionen unter Umständen zu einer höheren Komplexität, da sie neue Funktionen hinzufügen. In diesem Szenario ist der Einsatz einer servicebefähigenden Plattform wie ESB wohl die bessere Wahl. Für komplett neue Anwendungen bevorzuge ich allerdings den Microservice-Ansatz, da es derzeit die flexibelste Architektur bietet.

Folgen Sie SearchEnterpriseSoftware.de auch auf Twitter, Google+ und Facebook!