Microservices sind in aller Munde. Immer wieder kommen wir in Gesprächen mit unseren Kunden auf dieses Thema. Doch was sind Microservices? Wann ist deren Einsatz sinnvoll? Und wann nicht?

Was sind Microservices?

Wikipedia definiert den Begriff folgendermassen:

Microservices sind ein Architekturmuster der Informationstechnik, bei dem komplexe Anwendungssoftware aus unabhängigen Prozessen komponiert wird, die untereinander mit sprachunabhängigen Programmierschnittstellen kommunizieren. Die Dienste sind weitgehend entkoppelt und erledigen eine kleine Aufgabe.

Nehmen wir als Beispiel einen Webshop. Typische Geschäftsprozesse bestehen aus dem Suchen von Artikeln, der Verwaltung eines Warenkorbs, dem Lager- oder Artikelmanagement, dem Checkout und vielen weiteren. Jeder dieser Prozesse soll nun in einer eigenen Software implementiert werden. Der Webshop selber besteht letztendlich noch aus einem Frontend, das die verschiedenen Dienste über eine Schnittstelle (typischerweise eine REST API über HTTP verknüpft.

Und was hab ich davon?

Das Zerlegen einer grossen Applikation in kleinere Einheiten hat einige Vorteile:

• Die einzelnen Teile können sehr einfach von verschiedenen Teams entwickelt werden. Man muss allerdings darauf achten, dass die Schnittstellen klar dokumentiert sind und eingehalten werden!

• Die einzelnen Dienste können separat getestet werden. Solange sich die Schnittstelle nicht verändert ist davon auszugehen, dass das Gesamtsystem stabil bleibt.

• Deployments sind weniger risikoreich. Solange die Schnittstelle gleich bleibt, kann ein Service sehr schnell deployed oder - nötigenfalls - zurückgerollt werden.

• Es ist wesentlich einfacher die Übersicht über eine kleine Applikation zu halten, als über einen grossen Monolithen mit zahlreichen internen Abhängigkeiten.

• Ein Microservice kann sehr einfach durch einen anderen ersetzt bzw. abgelöst werden, solange dessen Schnittstelle gleich bleibt.


Doch auch diese Architektur hat ihre Stolperfallen. Sind die einzelnen Dienste nicht konsequent genug voneinander getrennt, baut man sich einen verteilten Monolithen. Das macht das System noch komplexer, als es vielleicht sonst schon war.

Wann sind Microservices sinnvoll?

Die folgenden Fragen sollen die Entscheidung erleichtern, sich beim Design eines Systems für oder gegen Microservices zu entscheiden.

• Unterschiedliche Änderungsrate
  • 
Werden Teile der Applikation massiv öfter verändert, als andere? Das könnte ein Hinweis darauf sein, dass diese Teile eine eigene Domäne abbilden und daher extrahiert werden können.

• Unterschiedliche Lifecycles

  • Durchlaufen Teile der Applikation einen anderen Software-Lifecycle, als andere? Benutzen sie andere Test Frameworks? Haben sie verschiedene Pipelines im CI System? Müssen sie speziell deployed werden?

• Unabhängige Skalierung
  • 
Sind Teile der Applikation einer höheren Last ausgesetzt, als andere? Dann macht es unter Umständen Sinn, diese auch separat zu skalieren. Dafür müssen sie aber vom Rest der Applikation getrennt werden.

• Externe Abhängigkeiten isolieren

  • Sind Teile der Applikation von einem externen Dienst abhängig, der oft die Schnittstelle ändert oder oft ausfällt? Durch einen "Fassaden"-Dienst kann diese Abhängigkeit standardisiert und stabilisiert werden.

• Das richtige Werkzeug für den Job

  • Sind gewisse Funktionalitäten der Anwendung performance-kritisch und es gibt eigentlich bessere Technologien diesen Teil abzubilden? Dann kann man den kritischen Teil in einen Service verlagern, der die besten Werkzeuge für den Job nutzt. Zudem kann man es so verschiedenen Teams ermöglichen die Technologie einzusetzen, mit dem sie am effizientesten arbeiten.

• Mehrere Konsumenten
  • 
Wird ein Teil der Applikation von mehreren Konsumenten benutzt? Ein Online-Newsportal kann zum Beispiel in einen Content- und einen Frontend-Teil zerlegt werden. So können die verschiedenen Mobile-Apps auf den Content-Teil zugreifen, während der Frontend-Teil unabhängig weiterentwickelt wird.


Voraussetzungen

Im Vergleich zu herkömmlichen Architekturen gibt es keine zusätzlichen technischen Voraussetzungen. Allerdings gibt es ein paar Werkzeuge und Technologien, die beim Betrieb von Microservices helfen können.

Automatisierte Tests sind nun definitiv zwingend. Unit Tests sichern das interne Verhalten des Dienstes ab, während Integrationstests das Zusammenspiel zwischen verschiedenen Services auf eine automatische Weise sicherstellen können.

Um das einfachere Deployment und die unabhängige Skalierbarkeit von kleineren Diensten voll auszunutzen, ist es sinnvoll auf eine Container-Technologie wie Docker zu setzen. Grosse Plattformen - wie RedHat OpenShift oder Cloud Foundry - haben Funktionen für automatische Deployments oder Auto-Scaling eingebaut.

Zudem lohnt es sich, in das Thema Infrastructure-As-Code zu investieren. Mehr Services bedeutet auch mehr Infrastruktur. Diese von Hand zu pflegen ist Fehleranfällig und aufwändig. Tools wie Puppet, Ansible und Terraform können helfen, viele Prozesse zu automatisieren und die Infrastruktur zu versionieren.

Weil eine Aufgabe sich über mehrere verschiedene Dienste in der Applikationslandschaft erstrecken kann, ist es wichtig, eine zentrale und strukturierte Stelle für Logging-Daten zu schaffen. Ein Frontend-Request sollte bis zum letzten Dienst in der Schlange identifizierbar sein, damit Debugging und eine Auditierung möglich sind.

Fazit

Microservices können helfen, grosse und komplexe Systeme in kleinere und übersichtlichere Einheiten aufzuteilen. Es ist jedoch enorm wichtig, auf eine sinnvolle Zerlegung zu achten und die Dienste unabhängig voneinander zu gestalten. Die Anzahl produzierter Microservices sollte keine Messgrösse für die Effektivität eines Entwicklungsteams sein.

Erhalten Sie weitere spannende Informationen zu technischen Hintergründen und Erfahrungsberichten von unseren Engineers. Melden Sie sich für die Engineering Logbook Updates an, damit Sie nichts verpassen.