Microservices - kurz und bündig

Microservices sind ganz klar auf dem Vormarsch. Besonders die Trends zu SaaS und Cloud-Produkten befeuert diesen Trend noch zusätzlich, da für deren Nutzung eine Service-orientierte Architektur große Vorteile bringt. Der folgende Artikel soll dem geneigten Leser einen Überblick darüber bieten, welche Vor- und Nachteile Microservices bieten und was man bei deren Betrieb und Qualitätssicherung beachten muss.

Was verstehen wir unter Microservices?

Ein Microservice ist ein abgeschlossenes und unabhängiges Programm, das für genau einen bestimmten Zweck eingesetzt wird. Die Kommunikation mit dem Microservice erfolgt über sprachunabhängige API-Schnittstellen (in den meisten Fällen haben sich REST-Webservices durchgesetzt).

Folgende Eigenschaften haben Microservices:

  • Sie haben einen bestimmten, eng begrenzten Zweck
  • Implementierungsdetails sind nach außen hin nicht bekannt, die Schnittstellen bieten keine Hinweise darauf
  • Sie sind isoliert und unabhängig lauffähig, auch mehrere Instanzen eines Microservices können nebeneinander laufen

Welche Vorteile bieten Microservices bzw. eine Architektur, die auf Microservices aufbaut?

Unabhängige Entwicklung
Die Implementierung eines Microservices kann durch ein relativ kleines Entwicklungsteam ohne großen Abstimmungsaufwand (zumindest im Vergleich zu Modulen, die Teil eines großen monolithischen Programms sind) erfolgen. Die Entwicklung kann dadurch auch sehr gut an externe Dienstleister ausgelagert werden oder das Service generell zugekauft werden.

Unabhängiger Betrieb
Das Microservice kann auf genau angepassten Umgebungen betrieben werden. Auch der Betrieb kann hier einfach bei Bedarf ausgelagert werden.

Geringe Komplexität
Durch den eng abgesteckten Einsatzzweck mit eng abgesteckter Funktionalität bestehen die einzelnen Microservices aus relativ kurzen, einfachen und verständlichen Code.

Einfache Änder- bzw. Erweiterbarkeit
Solange die API-Schnittstellen sich nicht ändern, kann ein Microservice verändert, erweitert oder komplett ausgetauscht werden, ohne dass sich Auswirkungen auf das Gesamtsystem ergeben.

Sehr gute Skalierbarkeit
Bei einem richtig geplanten System, das auf eine Microservice-Architektur aufbaut, können die einzelnen Microservices bei Bedarf mehrfach gestartet und so die Last einfach verteilt werden.

Große Robustheit des Gesamtsystems
Ein Ausfall eines Microservices bedeutet nicht den Ausfall des Gesamtsystems.

Nachteile gegenüber einem großen, monolithischen Programms

Größere Komplexität des Gesamtsystems
Zwar sind die einzelnen Microservices selbst relativ einfach und wenig komplex, das Zusammenspiel der unterschiedlichen Komponenten kann allerdings schwierig zu durchschauen sein und erfordern gute Planung und auch gute Dokumentation.

Potentieller Kommunikationsoverhead
Die Kommunikation über API-Schnittstellen zwischen den Microservices bedeutet im Normalfall einen Mehraufwand gegenüber dem Datenaustausch von Modulen innerhalb eines monolithischen Programmes.

Zusätzlicher Bedarf an Netzwerkressourcen
Da die Microservices typischerweise miteinander über das Netzwerk kommunizieren, wird dies zusätzlich belastet.

Wie stellt man einen effizienten Betrieb und einfache Wartbarkeit des Gesamtsystems sicher?

Verteilung der Last, Virtualisierung und Containerisierung
Die einzelnen Services sollten virtualisiert und in OS-Containern betrieben werden. Tools zur Lastverteilung sollten eingesetzt werden und den Services vorgeschaltet sein.

Nutzung von Orchestrierungstools
Es gibt etliche Orchestrierungsaufgaben, die im Betrieb einer Microservice-Architektur anfallen:

  • Überwachung der Services
  • Sammlung und Archivierung von Log-Einträgen der Services
  • Starten und Stoppen der Services
  • Überwachung des Ressourcenverbrauchs der OS-Container
  • Anpassung der Ressourcen für die OS-Container
  • Anpassung der Anzahl der laufenden Instanzen der Services an die aktuelle Last

Es gibt Tools, die diese Aufgaben automatisieren oder zumindest erheblich erleichtern können. Prominente Vertreter dieser Tools sind Kubernetes und Docker Swarm.

Die Implementierung eines gemeinsamen “Cockpits”, in dem diese Aufgaben zentralisiert übernommen werden können, ist mit modernen Tools möglich und sinnvoll.

Einsatz von Continuous Integration und Continuous Delivery
Im Gegensatz zu typischen “Big Bang” Deployments bei großen monolithischen Programmen werden Änderungen in Microservice-Architekturen typischerweise in mehreren kleinen Updates einiger weniger Services ausgeliefert. Die Gesamtzahl dieser Auslieferungen ist in Summe viel höher als bei einem monolithischen System und bedeutet aufgrund der verteilten Services mehr Aufwand. Dieser Aufwand ist jedoch hochgradig automatisierbar und es gibt eine große Menge an CI/CD Lösungen am Markt, die so etwas übernehmen können.

Wie sichert man die Qualität des Gesamtsystems effizient?

Großer Fokus auf automatisierte API-Tests
API-Tests sind unabdingbar notwendig zur Qualitätssicherung des Gesamtsystems. Man muss jederzeit damit rechnen, dass Microservices anders implementiert werden oder ausgetauscht werden. Auch kann es sein, dass man auf die Testergebnisse (z.B.Unit-Tests) keinen Zugriff hat, weil das Service extern entwickelt und / oder betreut wird.

API-Tests sollten unbedingt automatisiert und idealerweise in eine CI/CD Pipeline inkludiert werden.

Einsatz von “Mock” - Services
Beim Durchführen der API-Tests für ein einzelnes Microservice muss sichergestellt werden, dass potentiell gefundene Fehler wirklich von diesem Service stammen und nicht aufgrund von fehlerhaften anderen Services, von denen das zu testende Microservice abhängt. Um dies sicherzustellen, müssen in der Testumgebung alle ausgehenden Aufrufe an sogenannte Mock-Services geleitet werden. Diese müssen nicht die Funktion der produktiv im Einsatz befindlichen Services erfüllen, sondern müssen nur auf die Aufrufe des zu testenden Systems die für den Test passenden Antworten liefern. Im Idealfall ist so etwas relativ leicht mittels einer Key - Value Datenbank umsetzbar, die eben zu jedem Aufruf (Key) die passende Antwort (Value) liefert.

Autor
SEQIS Autor Markus Schwabeneder

Markus Schwabeneder

Senior Consultant und Senior Agile Architect



Newsletter

Um neue Beiträge per E-Mail zu erhalten, hier die E-Mail-Adresse eingeben.

Unsere Autoren

Informieren Sie sich über unsere Autoren und erfahren Sie mehr über unsere Spezialisten und ihre Fachbereiche:

Zu den Autoren

Sie haben eine Frage?

Zurück

Zum Seitenanfang navigieren