Container und Microservices spielen dabei eine zentrale Rolle. Egal ob Facebook, Netflix, Instagram oder Whatsapp im Consumer-Bereich oder Slack, Trello, Google Analytics oder Salesforce im Business-Umfeld: Als Endanwender hat man sich heutzutage längst daran gewöhnt, dass die Apps und Online-Dienste, die man jeden Tag nutzt, regelmäßig aktualisiert werden. Man erwartet, dass Bugs in kürzester Zeit behoben und neue Features lanciert werden und das auf Kundenfeedback geachtet und die Benutzererfahrung entsprechend verbessert wird. Ist das nicht der Fall kann man heute häufig, ohne allzu großen Aufwand, zu einem anderen Anbieter wechseln. Der Konkurrenzdruck in der Softwarebranche ist enorm. Vor diesem Hintergrund liefern führende Cloud-Services neue Funktionen, Fehlerbehebungen und Verbesserungen in regelmäßigen Abständen, die immer kürzer werden.

Das war nicht immer so. Rund um die Jahrtausendwende, als die ersten SaaS-Lösungen auf den Markt kamen, haben Anbieter ihren Kunden zwar versprochen, ihre Online-Dienste immer auf dem aktuellsten Stand zu halten, ohne dass die Kunden Updates einspielen oder zusätzliche Lizenzen kaufen müssen. Als SaaS-Kunde konnte man damals jedoch froh sein, wenn die Software ein paar Mal im Jahr aktualisiert wurde. Die Release-Zyklen von Cloud-Services sind in den letzten Jahren dramatisch kürzer geworden. Facebook aktualisiert seine Apps mindestens einmal am Tag. Netflix liefert neuen Code sogar bis zu hundertmal am Tag. Und das sind keine Ausnahmen. Moderne Cloud-Technologien versetzen Entwickler in die Lage, selbst hochkomplexe Systeme, die rund um die Uhr von Millionen Anwendern genutzt werden, flexibler und schneller als je zuvor aktualisieren zu können, und das natürlich ohne Downtime.

Hier kommen Microservices und Container ins Spiel. Microservices stellen ein Architekturmodell für die Entwicklung von Software dar, das derzeit voll im Trend liegt. Eigentlich ist das Konzept nicht neu. Service-orientierte Architekturen, kurz SOA, sind im Enterprise-Software-Sektor schon seit über 20 Jahren ein Begriff. Und auch wenn beide Architekturmodelle und deren Implementierungsansätze in der Praxis sehr unterschiedlich sind, so dienen sie im Prinzip nur einem: Der effizienten Modularisierung von Software.

Modularisierung ist schon immer ein zentrales Thema in der Softwareentwicklung gewesen, denn es ist eine bewährte Methode, um die Komplexität von Software-Projekten zu reduzieren. Schon die Business-Anwendungen in der PC-Ära waren modular aufgebaut. Ein großes, komplexes System wurde aus mehreren (mehr oder weniger) voneinander unabhängigen Modulen zusammengebaut. Alle Module teilten sich in der Regel jedoch die gleiche Code-Basis und wurden als ein einziges System deployt. Das heißt, dass Änderungen an einem Modul schnell zu unerwarteten Fehlern bei anderen Modulen oder weiteren Teilen des Systems führen konnten. Und auch wenn Entwickler mit einem durchdachten Architekturdesign versuchten, Abhängigkeiten zwischen den verschiedenen Modulen auf ein Minimum zu halten, so wurden solche monolithische Systeme mit jedem neuen Feature, mit jedem neuen Modul immer komplexer. Die Folge: Die Implementierung neuer Funktionen dauert immer länger, selbst anscheinend harmlose Änderungen am Code werden immer gefährlicher, das Testing immer aufwändiger.

Microservice-Architekturen gehen deshalb noch einen Schritt weiter. Ganz nach dem Prinzip „Divide and conquer“ werden komplexe Softwareanwendungen nicht als ein großes (modular aufgebautes) Monolith, sondern als ein verteiltes System entwickelt, das aus mehreren, strikt voneinander unabhängigen Diensten besteht. Diese Dienste sind schlank, fokussieren sich nur auf eine kleine, bestimmte Aufgabe und werden gegenüber anderen Services vollkommen isoliert. Die Implementierungsdetails werden hinter einer einfachen Programmierschnittstelle (API) versteckt – häufig auf Basis von REST oder RPC (Remote Procedure Call) –, über die die einzelnen Microservices miteinander kommunizieren. Da jeder Microservice unabhängig vom Rest des Systems entwickelt werden kann, können verschiedene Teams eigenverantwortlicher und unabhängiger arbeiten. Das ermöglicht die Implementierung agiler Development-Prozesse, bei denen der Kommunikations- und Koordinationsaufwand auf ein Minimum reduziert wird. Aber nicht nur das. Entwickler haben gleichzeitig mehr Flexibilität was den Technologie-Stack angeht. So können sie nun für jeden Microservice die passende Programmiersprache beziehungsweise das passende Datenbanksystem wählen.

Ein weiterer, entscheidender Vorteil einer Microservice-Architektur besteht darin, dass sich Deployment-Prozesse optimieren und leichter automatisieren lassen. Denn bei jedem Deployment muss man anders als bei traditionellen Monolithen nicht das ganze System aktualisieren, sondern die Microservices, die tatsächlich aktualisiert werden müssen. Diese lassen sich auf verschiedenen Server-Instanzen betreiben und bei Bedarf separat vom Rest der Anwendung skalieren. Hier kommen Container ins Spiel.

Container passen perfekt zu einer solchen Microservice-basierten Softwarearchitektur. Aus dem Grund werden diese beiden Trends häufig im gleichen Atemzug genannt. Wenn von Container die Rede ist, denken die meisten an Docker. Doch inzwischen gibt es weitere professionelle Alternativen. Docker und Co. haben die Art und Weise, wie Softwareanwendungen deployt werden, revolutioniert. Noch nie ist es nämlich so einfach gewesen, eine Applikation auf verschiedene Plattformen und Umgebungen (Entwicklung, QA, Produktion) zu bringen, wie es heutzutage dank Docker der Fall ist. Der Clou: Docker packt die Anwendung und alle für deren Ausführung benötigten Systemkomponenten (Betriebssystem, Anwendungsserver, Datenbanksystem) in einer einzigen Datei, den sogenannten „Container“. Docker-Container sorgen dafür, dass die Anwendung verlässlich läuft, nachdem sie von einer Umgebung in eine andere versetzt worden ist. Dies vereinfacht nicht nur das Deployment komplexer Anwendungen, die auf verschiedenen Servern laufen, sondern ermöglicht gleichzeitig eine flexiblere Anwendungsinfrastruktur, die sich leichter ändern, erweitern und skalieren lässt. Aus dem Grund gilt Docker als die perfekte Verpackung für Microservices.

Aufgrund dieser Vorteile werden überall große Monolithen durch eine flexible Architektur auf Basis von Microservices ersetzt, die als Container deployt werden. Amazon und Netflix investieren seit Jahren stark in Microservices und gelten in diesem Bereich als Vorreiter. Inzwischen gibt es aber unzählige Erfolgsgeschichten für die Migration von klassischen Monolithen hin zu flexibleren Microservice-orientierten Architekturen. Schnellwachsende Startups wie Uber, Zalando oder Soundcloud, aber auch etablierte Internetunternehmen wie Ebay oder Groupon haben gezeigt, dass die Umstellung von Monolithen auf Microservices große Potenziale mit sich bringen kann. Entwickler können agiler arbeiten, Deployment-Prozesse besser automatisieren und Release-Zyklen drastisch verkürzen.

Groupon hat schon im Jahr 2013 die Frontend-Komponenten seines Monoliths (auf Basis von Ruby on Rails) durch Microservices ersetzt. Auch Soundcloud ersetzte sein Legacy-Rails-System durch Microservices, die nun in unterschiedlichen Programmiersprachen implementiert werden können (Scala, Clojure und JRuby). Diese Flexibilität zu haben, je nach Anforderung die am besten geeignete Programmiersprache auswählen zu können, war auch für Uber ein zentrales Argument, sich für Microservices zu entscheiden. So ersetzte das Unternehmen sein monolithisches System durch über 500 Microservices in verschiedenen Sprachen wie Node.js, Go und Python. Auch Zalando hat ein ähnlich großes Migrationsprojekt gewagt und sein auf Java Enterprise, Spring und Postgre basiertes Monolith durch 200 Microservices ersetzt.

Interessant bei solchen Praxisbeispielen sind nicht nur die implementierten Ansätze, von denen man lernen kann, sondern vor allem auch die Probleme und Schwierigkeiten, mit denen die Entwickler bei den Projekten zu kämpfen hatten. Denn bei all den Vorteilen, die Microservices und Container mit sich bringen, ist die Umsetzung in der Praxis gar nicht so einfach – ganz im Gegenteil. Die Administration eines verteilten Systems ist um ein vielfaches schwieriger als bei einem Monolithen. Das Testing und Monitoring gestaltet sich ebenfalls schwerer. Bei der Kommunikation und Koordinierung zwischen den einzelnen Microservices können ebenfalls neue Probleme auftauchen, die man effizient lösen muss.

Und tatsächlich tun sich viele Unternehmen noch schwer, wenn es um die praktische Umsetzung einer Microservices-Strategie geht. Dies zeigt eine Studie von der Firma LeanIX, Spezialist für Enterprise-Architecture-Management, bei der rund 100 Unternehmen aus Europa und den USA befragt wurden. Demnach haben erst neun Prozent der befragten IT-Entscheider den Schritt Richtung Microservices gewagt. In den meisten Fällen, so die Studie weiter, behalten diese Organisationen ihre Softwaremonolithen und stellen nur neue Komponenten in Form von Microservices bereit. Ein Fünftel der Interviewten nannte eine höhere Komplexität als Hinderungsgrund. Die größten Hürden sehen die befragten IT-Experten aber vor allem im mangelnden Know-how und fehlenden Experten. Doch immerhin ein Drittel der interviewten IT-Manager plant, bestehende Softwaresysteme mithilfe von Microservices zu transformieren.

Microservices und Container machen Entwicklung, Deployment und Betrieb komplexer Softwareanwendungen schneller und agiler. Softwareanbieter, die den Schritt gewagt und ihre Softwaremonolithen bereits durch eine flexible Microservice-Architektur ersetzt haben, liefern neue Features, Verbesserungen und Fixes deutlich schneller und häufiger als die Konkurrenz. Die Umstellung ist in der Praxis allerdings nicht einfach. Die Migration eines alten Softwaremonolithen hin zu einer Microservice-Architektur ist ein langes, komplexes Projekt, das sich über viele Monate hinziehen kann. In vielen Unternehmen fehlt schlicht und einfach das erforderliche Know-how. Doch Legacy-Systeme lassen sich auch Schritt für Schritt durch Microservices ersetzen, sodass neue Features ohne umfangreiche Änderungen der bestehende Code-Basis hinzugefügt werden können. Man muss also kein „Hypergrowth-Startup“ wie Uber oder Soundcloud sein, um von Microservices profitieren zu können.