Kolumne: Stropek as a Service

Microservices ohne Cloud und DevOps? Keine Chance!
Kommentare

Microservices sind seit einiger Zeit in aller Munde. Diese Architektur verspricht Lösungen für Probleme, die vielen Organisationen unter den Nägeln brennen: Schneller auf neue Anforderungen reagieren, mehr Eigenverantwortung für Teams, bessere Skalierbarkeit, einfacheres Deployment, weniger Abhängigkeiten durch lose Kopplung und vieles mehr. Leider übersehen viele, die mit dem Gedanken spielen, ihren Monolithen in kleine, autonome Services zu zerteilen, dass Microservices ohne DevOps zum Scheitern verurteilt sind.

Wie soll man schließlich ein Sammelsurium von dutzenden oder sogar hunderten Services ohne hochgradige Automatisierung, Software-driven Data Center, solide Telemetrie und Ähnliches managen?

Die Probleme, die sich beim Monolithen in Sachen Quellcodeverwaltung, Versionisierung, automatisiertem Testen, Continuous Integration, Continuous Deployment, Release Management und Monitoring zeigen, löst ein Beschluss, auf Microservices zu schwenken, nicht in Luft auf. Im Gegenteil, sie werden erst so richtig akut.

Warum die Cloud in der Praxis eine Voraussetzung für Microservices ist

Wenn ich zu alteingesessenen Unternehmen eingeladen werde, die in Richtung Microservices gehen möchten, ist der Hinweis auf DevOps als Grundlage für die Veränderung nicht selten eine Überraschung. Man erschrickt, weil die notwendige Infrastruktur in der Anschaffung, Einführung und im Betrieb teuer wäre. Die bei uns üblichen Rechenzentren sind selten auf die DevOps-Anforderungen des 21. Jahrhunderts ausgelegt. An dieser Stelle folgt häufig das Zweifeln, ob Microservices vielleicht doch nur etwas für die ganz großen IT-Unternehmen sind.

In solchen Situationen ist es höchste Zeit für einen Weckruf. Ich zeige dann gerne, wie man mit Public Clouds wie Microsoft Azure in wenigen Stunden eine Paradeinfrastruktur für Microservices bauen kann: Quellcodeverwaltung und CI/CD mit Visual Studio Team Services, Deployment-Automatisierung und Releasemanagement in Verbindung mit Azure, PaaS-Angebote für hochverfügbaren Speicher (SQL, NoSQL) und Message Broker, Serverless Operations mit App Services – alles fix und fertig vorhanden und in kürzester Zeit einsatzbereit. Es ist dann doch mehr bei der Public Cloud involviert als nur das Austauschen von Servern im Keller durch virtuelle Maschinen irgendwo im Internet.

Meiner Erfahrung nach können es sich nur sehr wenige Organisationen leisten, eine für Microservices und DevOps geeignete, professionelle Infrastruktur im eigenen Haus aufzubauen. Ich finde es schade, dass in unseren Breitengraden bei vielen Unternehmen ein „unangenehmes Bauchgefühl“ oder dubiose Datenschutzängste den Einsatz von Public Cloud kategorisch verhindern.

Nicht, dass die Public Cloud per se ein Wundermittel wäre. Die Verweigerung der Cloud und das gleichzeitige Unvermögen, etwas Vergleichbares im eigenen Rechenzentrum aufzubauen, verhindern das Profitieren von nachgewiesenermaßen effizienten Architekturen wie Microservices. Die „No Cloud“-Strategie wird dadurch zu einem echten Wettbewerbsnachteil.

Homogene Technologie? Ein frommer Wunsch

Ein zweiter Grund für die Cloud als Voraussetzung für Microservices ist die Autonomie der Entwicklungsteams. Es ist ein wichtiger Grundpfeiler der Microservices-Idee, dass Teams autonom die besten Werkzeuge für ihre individuellen Herausforderungen wählen können. Zentrale Architekten geben nur grundlegende Prinzipien und Richtlinien heraus. Mikromanagement ist dabei unerwünscht.

Was heißt das in der Praxis? Ein Team setzt aus historischen Gründen noch PHP ein, eines nutzt .NET 4, ein drittes wechselt schon auf .NET Core unter Linux und durch einen Zukauf hat man einen Service auf Basis von Ruby ins Haus bekommen. Der Albtraum für jede Betriebsmannschaft, oder? Der Microservices-Ansatz will diese Vielfalt ermöglichen, nicht verhindern. Man geht davon aus, dass nennenswerte Unternehmen sowieso keine Wahl haben. Durch Zusammenlegungen, historische Entwicklung, Vorlieben von Teams mit entsprechender Durchsetzungskraft etc. ist eine homogene Technologie ein frommer Wunsch und in der Praxis nicht durchsetzbar.

Streng hierarchisch organisierte Unternehmen reagieren oft durch detaillierte Richtlinien. Abweichungen sind unerwünscht oder sogar verboten. Die Folge ist eine unflexible, träge und ineffiziente Softwareentwicklung. Änderungen dauern ewig, Big Design Up Front („Wasserfall“) ist allgegenwärtig und zudem gelingt es kaum, junge Talente dauerhaft für eine Mitarbeit zu begeistern.

Cloud ermöglicht Vielfalt

Public-Cloud-Anbieter können durch Anbieten entsprechender PaaS-Lösungen ein Ausweg sein. In Azure App Service kann man beispielsweise Anwendungen auf Basis von .NET, PHP, Java, Node.js, Python und vielem mehr betreiben. Der Punkt dabei ist, dass man dafür keine Expertin für die jeweilige Plattform sein muss. Microsoft kümmert sich um die Wartung der Server und Laufzeitumgebungen.

Instabil durch Microservices

Analoges gilt für zentrale Komponenten von Microservices-Umgebungen wie persistente Queues, hochverfügbare Message Broker, viele verschiedene Speicherdienste (SQL und NoSQL) oder Telemetrie. Eine IT-Organisation, die es nicht gewohnt ist, Systeme mit einer Verfügbarkeit von mindestens 99,9 Prozent zu betreiben, wird mit Microservices ein Problem bekommen. Der Ausfall zentraler Kommunikations- oder Speichersystemen hat sehr unangenehme Konsequenzen. Instabilitäten beim Deployment von Systemkomponenten wirken sich bei einer Menge kleiner Services schlimmer aus als beim Monolithen, der nur auf einer Handvoll großer Server installiert ist. Ohne eine adäquate Basis drehen sich die Vorteile der Microservices ins Gegenteil.

Docker als Ausweg?

Containertechnologie, insbesondere Docker, wird von einigen als Lösung für das DevOps-Problem gesehen, vor dem viele Unternehmen im eigenen Rechenzentrum stehen. Man holt sich einfach die passenden Docker Images aus dem Docker Hub und braucht sich, wie bei PaaS (Platform as a Service), in der Public Cloud um nichts mehr zu kümmern.

Ich finde diese Darstellung greift zu kurz. Der sichere und verlässliche Betrieb eines Docker-Clusters ist alles andere als einfach. Public-Cloud-Rechenzentren sind darauf optimiert, Clusterknoten so zu verteilen, dass sowohl Auslastung als auch Verfügbarkeit optimiert werden. Wie sieht es damit im typischen Rechenzentrum eines mittelständischen Betriebs aus? Was hilft ein Cluster aus mehreren Docker-Hosts wenn es im Netzwerk vor Single Point of Failure nur so strotzt?

Es ist richtig, dass Docker eine große Hilfe sein kann, wenn man den Lock-in-Effekt der Public Cloud reduzieren möchte. Wer jedoch meint, dass das Zauberwort Docker alle Infrastrukturprobleme im Zusammenhang mit Microservices löst, der irrt.

Fazit

Microservices sind ein mächtiges Konzept. Ich bin ein großer Anhänger dieser Herangehensweise. Die Voraussetzungen für eine erfolgreiche Einführung sind aber nicht zu unterschätzen. Die modernen Public Clouds sind ausgezeichnet auf Microservices vorbereitet. Wer aber trotzdem kategorisch „No Cloud“ sagt, hat eine Menge Hausaufgaben zu erledigen.

Lesen Sie alle Ausgaben der Kolumne „Stropek as a Service„!
In der Kolumne greift Rainer Stropek spannende Aspekte wie die Finanzierung, den Customer Lifetime Value, aber auch wichtige Themen wie Billing, Kundenbindung durch Qualität oder APIs auf – alles aus der Sicht eines Unternehmers, der seit 20 Jahren in der IT-Branche tätig ist und seit fünf Jahren intensive Erfahrungen mit SaaS gesammelt hat.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -