Architekturen von Softwareapplikationen wechseln mit der Zeit. Je komplexer die Anwendungssysteme werden, desto mehr braucht es eine Strategie, diese Komplexität auf technischer Ebene zu beherrschen. Ein bereits langanhaltender Trend ist die Nutzung von Microservices. Unter Microservices versteht man ein Architekturprinzip, bei dem ein komplexes Anwendungssystem sich aus unabhängigen Teilen bzw. Diensten zusammensetzt, welche untereinander mit Hilfe von sprachunabhängigen Programmierschnittstellen kommunizieren. Die Dienste erledigen jeweils eine eindeutig abgegrenzte Aufgabe mit einem überschaubaren Umfang. Einzelne Microservices können beliebig verändert werden, ohne dass dieses einen Einfluss auf das Gesamtsystem hat. Dieser Systemaufbau ermöglicht eine schnelle Anpassung an sich ändernde Anforderungen. Microservices sind von anderen Diensten und Prozessen isoliert, sodass man verschiedene Technologien für deren Umsetzung, zum Beispiel Programmiersprachen oder Datenbanken, einsetzen kann.

Microservices versus SOA

Microservices ist das Ergebnis einer stetigen Weiterentwicklung der Architektur von umfassenden Softwaresystemen.
 

Monolithische Softwaresysteme sind dadurch gekennzeichnet, dass sämtliche Funktionen der Businesslogik als globale Einheit vorliegen. Um die Nachteile einer zu hohen Komplexität in Verbindung mit einer schlechten Wartbarkeit auszugleichen, wurden Konzepte zur Dezentralisation entwickelt. Sowohl bei SOA (Service-Oriented Architecture), als auch bei Microservices werden die Anwendungen aus kleineren, überschaubaren Teilen, welche flexibel angeordnet werden können, kombiniert. Dennoch gibt es wichtige Unterschiede.
 

Die Architektur von SOA ist so ausgelegt, dass die bereitgestellten Ressourcen von allen Diensten gemeinsam genutzt werden. Das betrifft ebenso die Komponenten und Datenspeicher. Es handelt sich eher um „größere“ Einheiten, welche über ein gemeinsames Bussystem – Enterprise Service Bus – miteinander kommunizieren. Der Dienst im Rahmen eines SOA ist auch stets auf das Anwendungssystem zugeschnitten, d.h. seine universelle Nutzbarkeit ist beschränkt. Bei Microservices dagegen wird eine Anwendung aus einer Reihe von unterschiedlichen Diensten, die jeweils einen bestimmten Zweck erfüllen, kombiniert. Die Services sind selten an ein konkretes Anwendungssystem gebunden. Beispielsweise kann der Service eines Zahlungsdienstleisters in unterschiedlichen Anwendungen genutzt werden. Im Vergleich zu den Microservices ist die SOA weniger flexibel bei der Bereitstellung. Beide Architekturen setzen für die Bereitstellung und Ausführung auf die Cloud- oder Hybrid-Cloud-Umgebung.

Die Architektur von Microservices basiert auf voneinander unabhängig arbeitenden Diensten. Die Kommunikation zwischen diesen Diensten erfolgt über API-Schnittstellen, zum Beispiel auf der Basis von REST. Die Microservices können schnell und einfach bereitgestellt werden. Sie werden eigenständig und ohne gegenseitige Abhängigkeiten entwickelt und sind in den unterschiedlichsten Anwendungen technikneutral einsetzbar. Die Unabhängigkeit führt zu einer höheren Stabilität des Systems. Ob SOA oder Microservices vorteilhafter sind, darauf gibt es keine eindeutige Antwort und muss für jeden Einzelfall separat entschieden werden.

Vorteile und Nachteile von Microservices

Als vorteilhaft kann man folgende Eigenschaften von Microservices betrachten:

• Leichtgewichtig: Microservices sind leichtgewichtig und funktional begrenzt. Die Inbetriebnahme von einzelnen Diensten erfolgt i. d. R. unabhängig. Das ermöglicht ein einfaches Deployment (Bereitstellung). Änderungen können schnell eingearbeitet bzw. mit wenig Aufwand kann eine Neuimplementierung erfolgen.

• Skalierbarkeit: Eine Microservice basierte Architektur ermöglicht eine schnelle und effiziente Anpassung an wechselnde Lasten. Das Gesamtsystem kann über den Austausch, die Anpassung und die Erweiterung der Services einfach skaliert werden.

• Unabhängigkeit: Die Dienste sind voneinander komplett unabhängig. Aus diesem Grund sind Microservices für ausfallsichere Systeme gut geeignet. Fehler in einem Microservice haben keine Auswirkung auf andere Dienste. Ausfälle einzelner Dienste können ohne Beeinträchtigung des Gesamtsystems behoben werden.

• Kombinierbarkeit: Microservices können miteinander beliebig kombiniert werden. So können neue Funktionen gestaltet werden.

• Innovationsfördernd: Jeder Microservice stellt eine kleine Applikation dar. Die Technologieauswahl für einzelne Dienste ist nicht eingeschränkt, d.h. Experimente mit neuen Technologien können einfach umgesetzt und die am besten zu dem jeweiligen Service passende Technologie ausgewählt werden.

• Wiederverwendbar: Die Microservice-Architektur fördert eine Wiederverwendbarkeit von Komponenten, beispielsweise auch die mehrfache Nutzung einer komplexen Geschäftslogik.

• Agil: Microservices unterstützen den agilen Ansatz in dem Sinne, dass die Arbeit an einzelnen Diensten in kleineren Teams unabhängig voneinander erfolgen kann.

Nachteilig beim Einsatz von Microservices sind mögliche höhere Latenzzeiten. Die Microservice-Architektur bildet eine Art verteiltes System. Die Kommunikation in solchen Systemen erfolgt über das Netzwerk. Diese Art der Kommunikation ist langsamer als diejenige zwischen Prozessen auf einem monolithischen System. Ein weiterer Nachteil besteht darin, dass Microservices als unabhängige Einheiten angesehen werden, die auch einen eigenen Bereitstellungsprozess benötigen. Dafür ist eine separate Infrastruktur notwendig, was einen höheren Aufwand bedeutet. Auch eine organisatorische Umstrukturierung von Teams, die für die Einführung einer Microservice Architektur notwendig ist, könnte als Nachteil angesehen werden.

Vom Monolithen zum Microservice

Die Umsetzung eines Softwaresystems auf der Basis einer Microservice-Architektur stellt eine größere Herausforderung dar. Die Rest-basierten Endpunkte müssen die Geschäftslogik spiegeln. Gefragt ist ein umfassendes Knowhow in den Basistechnologien, wie REST, JSON, Authentication, Cloud-Services usw. und die Wahl des passenden Toolings. Dieses soll dazu beitragen, dass das Design der Schnittstellen (APIs) der Microservices und die Implementierung der Fachlogik effizient erfolgen. Entwicklungsaufgaben für Frontend und Backend können voneinander entkoppelt werden. Ist die Schnittstelle – meist in Form einer REST-basierten API – definiert, dann können die Entwicklung der Client-Applikationen und die Implementierung der serverseitigen Backendlogik parallel und voneinander unabhängig erfolgen.
 

Microservices können für neue Softwaresysteme oder im Rahmen von Migrationsprojekten verwendet werden. Bei Letzteren existiert die Businesslogik bereits teilweise oder ganz in einem Legacy-System, zum Beispiel einen monolithischen Softwaresystem, und sollte zu universell über REST adressierbare Microservices transformiert werden. Ein Blick auf eine mögliche Gesamtarchitektur zeigt die Zusammenhänge.

Folgende technische Komponenten arbeiten zusammen:

• Clientseitige Applikationen: Die gewählte Architektur beschränkt die Möglichkeiten nicht. Denkbar sind Web-, Desktop- und Mobile- Applikationen. Es spielt keine Rolle, über welche Technologie diese erstellt werden. Die technologische Freiheit garantiert eine maximale Flexibilität, um das Anwendungssystem an die bestehenden Anforderungen und die Wünsche seiner Nutzer anzupassen.

• Serverseitige Infrastruktur: Sie besteht aus mehreren Komponenten. Im Mittelpunkt steht der Applikations-Server, dessen Aufgabe es ist, die Businesslogik in Form von Mikroservices zur Verfügung zu stellen. Im Beispiel kommt das Produkt RAD Server zum Einsatz.

• Datenbanken: Der Zugriff auf die Daten, welche zum Beispiel in einem relationalen Datenbanksystem gespeichert sind, erfolgt serverseitig durch die Microservices.

• Middleware: Serverseitig bietet der RAD Server vielfältige Möglichkeiten, u.a. die Integration von weiteren Unternehmensdatenbanken, die Verwaltung von IoT-Hardware und die Integration von Cloud- und BaaS-Diensten – wie Google, Amazon, Facebook usw. Die Middleware sorgt einerseits für einen Zugriff auf diese Dienste und vermittelt anderseits die Anfragen und Daten dann über REST-fähige Schnittstellen in Form von Microservices an die Clients weiter.

• Anwendungsdienste: Der RAD Server bietet diverse Anwendungsdienste, wie Benutzerverzeichnisverwaltung und Authentifizierung, Push-Benachrichtigungen, Mail-Service usw.

• Netzwerk: Sämtliche Kommunikation zwischen den Clients und dem Server erfolgt über eine sichere Internetverbindung (https). Anfragen der Clients werden via REST an die serverseitigen Microservices übermittelt. Der Datenaustausch basiert auf den standardisierten Formaten XML bzw. JSON.

Ein besonderes Merkmal des RAD Servers ist die nahtlose Bereitstellung der Dienste über die integrierte Entwicklungsumgebung RAD Studio – wahlweise auf den Betriebssystemen Windows (IIS, Apache) oder Linux (Apache). Damit ist es möglich, die Geschäftslogik in den Hochsprachen Delphi oder C++ zu implementieren und die Vorteile eines hoch integrierten Tools zu nutzen.