Bis vor kurzem war es notwendig, bei der Durchführung einer kleinen Änderung an einer Webanwendung auf einen monolithischen Block zuzugreifen, der den gesamten Quellcode der betreffenden App enthielt, wobei oft verschiedene Unternehmensabteilungen in den Prozess einbezogen wurden, von der Qualitätssicherung über den Systemadministrator bis hin zum Marketing.

Dieser Ansatz – nicht ohne Grund traditionell als „monolithisch“ bezeichnet – ist auch heute noch die am weitesten verbreitete Methode im Bereich der Webanwendungsentwicklung, aber es deutet alles darauf hin, dass seine Tage gezählt sind.

Ein Unternehmen wie Netflix, das zu den ersten gehörte, das diesen Weg eingeschlagen hat, hat tatsächlich einen revolutionären Prozess angestoßen, der den gesamten IT-Sektor betrifft, indem die monolithischen Strukturen der Webdienste zugunsten der sogenannten Microservices aufgebrochen werden.

Aber was sind Microservices? Und warum haben die größten IT-Unternehmen der Welt die nativen Strukturen ihrer Dienste aufgegeben, um zur Microservice-Architektur überzugehen?

Microservices: der Fall Netflix

Die meisten Unternehmen entwarfen ihre Webdienste nach einer einzigen Struktur – monolithisch – die eine schnelle Feinabstimmung und eine einfache Bereitstellung des Dienstes ermöglicht. Dieses System ist auch heute noch perfekt auf die Bedürfnisse kleiner Unternehmen oder einiger Start-ups abgestimmt, deren Kerngeschäft eng mit der Aktivierung und Bereitstellung neuer Dienste und Produkte verbunden ist.

Wenn ein IT-System jedoch wächst, erhöht sich die Komplexität des Codes, ebenso wie die Wartungs- und Verwaltungsaufgaben des Monolithen zunehmen. Zudem beeinträchtigt ein monolithisches System mit zunehmendem Wachstum des Systems immer mehr Geschwindigkeit, Agilität und Flexibilität der Dienste – Aspekte, die für jedes Geschäft mit intensiver Webaktivität, wie z.B. ein E-Commerce oder ein Streaming-Dienst, entscheidend sind.

Deshalb führen die größten IT-Unternehmen der Welt, beginnend mit Netflix, den epochalen Übergang zur Microservice-Architektur an. Der Fall von Netflix ist bezeichnend: Das Unternehmen begann 2009 mit dem Prozess der Migration aller seiner Dienste in die Cloud als Microservices und schloss die Operation erst 2011 ab.

Zwei Jahre Arbeit führten dazu, dass Netflix mehr als 1000 Microservices und API-Gateways entwickelte, die täglich über zwei Milliarden Anfragen von Nutzern verwalten. Es sei daran erinnert, dass Netflix ein Unternehmen mit über 200 Millionen Nutzern weltweit ist, die laut den neuesten Statistiken täglich über 165 Millionen Stunden damit verbringen, die Inhalte der Plattform zu „konsumieren“.

Der Fall Netflix, neben dem ersten erfolgreichen Beispiel für den Übergang zur neuen Architektur, ist emblematisch für die wichtige Beziehung zwischen der neuen Form der Dienste und der Migration der Inhalte zu den Cloud-Servern.

Das zentrale Bedürfnis, das beiden Prozessen zugrunde liegt, ist die Skalierbarkeit der Dienste: Adrian Cockcroft, der Cloud-Architekt, der für den epochalen Übergang bei Netflix verantwortlich ist, hat klar erklärt, wie dieser Übergang mit der Zunahme der Nutzer des Dienstes unerlässlich wurde.

Es war unmöglich, erklärt Cockcroft, genügend physischen Speicherplatz zu haben, um alle Daten der neuen Nutzer des Dienstes zu speichern, der damals tatsächlich auf die heute bekannten Dimensionen anwuchs.

Der Übergang zur cloud-basierten Konfiguration ermöglichte gleichzeitig die Aufteilung des riesigen Netflix-Systems in die oben genannten Microservices. Aber was sind Microservices und warum ist der Übergang zur Microservice-Architektur für IT-Unternehmen hinsichtlich Skalierbarkeit und Implementierung von Diensten inzwischen unerlässlich?

Die Skalierbarkeit von Diensten: Microservices, n-Tier-Modell und APIs

Um den Horizont zu verstehen, in dem der zunehmend dringende Bedarf besteht, sich mit der Softwarearchitektur auseinanderzusetzen, ist es notwendig, von einer mittlerweile klaren Voraussetzung auszugehen: Die Verbreitung von Smartphones und anderen Geräten mit Webkonnektivität hat sowohl die Nutzung auf der Benutzerseite als auch die Entwicklungsbedürfnisse von Webanwendungen revolutioniert.

Bis vor einigen Jahren musste eine Web-App in der Lage sein, mit einer einzelnen Entität auf einmal zu interagieren, in der Regel dem Webbrowser. Heute neigt man dazu, von sehr unterschiedlichen Geräten auf verschiedene Dienste zuzugreifen, was die Geschwindigkeit und Reaktionsfähigkeit einer Webanwendung genauso wichtig macht wie das Produkt selbst.

Die Verwendung einer Softwarearchitektur basierend auf dem Multi-Tier-Modell, oder n-Tier, bei dem verschiedenen Funktionen verschiedene Software-Ebenen entsprechen, ist mittlerweile gängige Praxis für Entwickler. Seit den frühen 2000er Jahren werden Three-Tier-Dienste erstellt, bei denen die drei Ebenen in der Regel die Benutzeroberfläche, die Prozesse selbst und die Datenablage umfassen.

Aber das Drei-Tier-Modell war nicht für die massive Nutzung von Smartphones und IoT ausgelegt. Der Übergang zur Microservice-Architektur erfordert die Hinzufügung von mindestens einer weiteren Schicht, weshalb immer häufiger von einer Four-Tier- oder n-Tier-Architektur die Rede ist.

Die Aufteilung der Anwendung in Ebenen wird durch APIs (Application Programming Interfaces) ermöglicht, kleine funktionale Bausteine, die unabhängig von der Programmiersprache sind und die, zwischen den Ebenen ausgesetzt, die bidirektionale Kommunikation in Echtzeit zwischen zwei Ebenen ermöglichen, z.B. der Datenbank und der Login-Oberfläche einer App.

Was sind die vier Ebenen eines solchen Systems?

- **Client**: Die erste Ebene betrifft weiterhin die Benutzeroberfläche, die auch vollständig geändert werden kann, ohne die anderen drei Ebenen zu beeinträchtigen. Auf diese Weise können perfekt reaktionsschnelle Dienste angeboten werden, die sich auf eine immer bessere Benutzererfahrung konzentrieren;
- **Delivery**: Die Delivery-Ebene kümmert sich darum, die „Lieferung“ von Inhalten und Diensten auf der Grundlage der vom Benutzer erhaltenen Informationen zu optimieren, von der Leistungsfähigkeit der Webkonnektivität bis hin zu den Spezifikationen des beteiligten Geräts;
- **Aggregation**: Die „aggregative“ Ebene ist diejenige, die in Echtzeit interne und externe Dienste und Ressourcen über APIs verbindet. Zum Beispiel nutzt Netflix AWS (Amazon Web Services) für das Cloud-Speichern seiner Datenbanken, weshalb es notwendig ist, dass der Amazon-Service und der Netflix-Service effizient kommunizieren können. Viele Apps auf unseren Smartphones nutzen heute in Echtzeit externe Ressourcen, während wir sie verwenden: genau wie Netflix, das ständig auf Amazon-Dienste zurückgreift, um seine Inhalte an Millionen von Nutzern weltweit zu verteilen.

- **Services**: Die letzte Ebene, in einer solchen Architektur, ist diejenige, die den anderen Ebenen die von der Anwendung benötigten Daten und Funktionen bereitstellt. Die Service-Ebene gewinnt im Kontext der Anwendung einer Microservices-Architektur ihren Sinn: Es geht darum, eine Art Hauptmotor unabhängig von den anderen auf diese Dienste anzuwenden, die für die Verteilung der Software wesentlich sind, wie zum Beispiel der Login-Service oder der Zahlungsabwicklungsdienst für jedes E-Commerce.
In einer Microservices-Architektur hat jede Funktion ihren eigenen kleinen Motor, und mögliche Fehlfunktionen eines einzelnen Dienstes (z.B. die Verwaltung des Profilbilds eines Nutzers auf einer Website) beeinträchtigen nicht den Rest des Systems.

Das ist der letztendliche Sinn der Aufspaltung eines Monolithen wie Netflix, und das ist der unvermeidliche Übergang für jedes Unternehmen, das seine Dienste über eine bestimmte Schwelle hinaus „skalieren“ möchte, sodass das Verhältnis zwischen der Anzahl der Operationen und dem Aufwand des Systems notwendigerweise in ein neues Verhältnis wechseln muss.

Das Netflix-System, wie es 2011 war – kurz vor dem Übergang von Cockcroft – benötigte etwa 100 Entwickler, die ständig an der Wartung eines immer größer und komplexer werdenden Monolithen beschäftigt waren. Damals hatte es etwas weniger als 30 Millionen Nutzer.

Es ist legitim zu fragen, ob das exponentielle Wachstum von Netflix physisch möglich gewesen wäre, ohne die Migration des gesamten Systems auf eine Cloud-basierte Microservices-Struktur.