Microservices, have you met… DevOps?

„Die Entwicklung von Microservices muss auf DevOps-Ebene stattfinden“

Jeff Sussna

© Shutterstock.com/EM Karuna

Jeff Sussna plädiert dafür, die Entwicklung von Microservices auf DevOps-Niveau zu heben. Um dies zu erreichen, müssen Organisationen ihre Definition der System-Level-Qualität ändern: Von der Stabilität zur Resilienz. Beginnen wir damit, Microservices als die komplexen Systeme zu behandeln, die sie sind!

Bereits zahlreiche Kommentatoren haben angemerkt, dass Microservices Komplexität im Code gegen betriebliche Komplexität eintauschen. Gary Oliffe beispielsweise hat Microservices als „Services with the Guts on the Outside“ beschrieben. Wahr ist, dass Microservices den Betrieb potentiell mit einer regelrechten Explosion aus beweglichen Teilen und Abhängigkeiten konfrontieren können.

Um zu verhindern, dass der Betrieb unter dieser neuen Komplexität begraben wird, muss man verstehen, dass Microservices sowohl ein neues Organisationsmodell als auch ein neues Architekturmodell darstellen. Die organisatorische Transformation, die Microservices handhabbar macht, darf nicht auf die Entwicklung beschränkt werden. Vielmehr muss sie auf der DevOps-Ebene stattfinden.

Microservices funktionieren, indem sie den Umfang der zu bedenkenden Aufgaben einschränken: Entwickler müssen sich um weniger Codezeilen, weniger Features und weniger Interfaces kümmern. Sie können deutlich schneller und öfter wertvolle Funktionalität schaffen und müssen sich gleichzeitig merklich weniger Sorgen machen, etwas zu zerschießen. Dabei verlassen sie sich auf übergeordnete, emergente Prozesse, um ihre Arbeit in ein kohärentes globales System zu integrieren.

Damit Microservices allerdings wirklich funktionieren, benötigt der Betrieb einen ähnlichen konzeptionellen Rahmen. Der Versuch, ein ganzes Universum an Microservices von außerhalb zu verwalten, erhöht den Umfang der zu bedenkenden Aufgaben, anstatt ihn zu verringern. Die Lösung besteht darin, den Begriff „Service“ ernst zu nehmen. Jeder Microservice ist genau das: ein Software-Service. Das Team, das den Service baut und betreibt, muss sich nur um ihn und seine unmittelbaren Abhängigkeiten kümmern. Abhängige Dienste sind Kunden; Services, von denen ein gegebener Microservice abhängt, sind Anbieter.

Wie stellt man aber Robustheit sicher, und wie geht man mit Ausfällen um, wenn man den Aufgabenbereich auf lokale Belange beschränkt? Der Grund, warum wir versuchen, Microservice-Architekturen monolithisch zu betreiben, ist, dass wir davon ausgehen, dass „alles funktionieren muss“. Die Lösung des Problems besteht darin, dass wir Microservice-Architekturen als das behandeln müssen, was sie sind, nämlich als „komplexe“ Systeme im Gegensatz zu den „komplizierten“ Systemen, die sie ersetzen. Während jeder Microservice ein Service erster Klasse ist,  sind seine Abhängigkeiten Dritt-Partei-Komponenten, so wie etwa Google Maps, Twilio oder jeder andere externe Service. Services von Drittanbietern können immer einmal ausfallen, weshalb Systeme, die auf sie angewiesen sind, gar keine andere Wahl haben, als im Hinblick auf Ausfallsicherheit entwickelt zu werden.

Microservices versprechen eine höhere Agilität bei verbesserter Qualität. Um beide Ziele zu erreichen, müssen Organisationen ihre Definition von System-Level-Qualität ändern: weg von der Stabilität, hin zur Resilienz. Wenn sie das schaffen, können sie diese Definition von Qualität in ihrer organisatorischen Struktur widerspiegeln. Genauso wie ein SaaS-Unternehmen als ganzes DevOps praktizieren würde, um Service-Qualität und Agilität zu erreichen, würde auch jeder Microservice dasselbe tun.

DevOpsCon Istio Cheat Sheet

Free: BRAND NEW DevOps Istio Cheat Sheet

Ever felt like service mesh chaos is taking over? As a follow-up to our previous cheat sheet featuring the most important commands and functions, DevOpsCon speaker Michael Hofmann has put together the 8 best practices you should keep in mind when using Istio.

Dieser Artikel ist im Original auf Ingineering.IT erschienen. In seinem Buch Designing Delivery – Rethinking IT in the Digital Service Economy vertieft er viele seiner Konzepte und Ideen über eine Neuausrichtung der IT.

Aufmacherbild: Exchange business card for first time meet von Shutterstock / Urheberrecht: EM Karuna

Geschrieben von
Jeff Sussna
Jeff Sussna
Jeff Sussna is the founder of Ingineering.IT, a Minneapolis technology consulting firm that helps enterprises and Software-as-a-Service companies adopt 21st-century IT tools and practices. He is also the author of ‘Designing Delivery: Rethinking IT in the Digital Service Economy’ and is a regular speaker on the topics of design and DevOps.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: