Stefan Toth
05.08.2015
Teil 2 der Blogserie erklärt, was Microservices sind: unabhängig deploybare, spezialisierte Dienste, die gemeinsam ein Gesamtsystem bilden. Anhand von Netflix wird gezeigt, wie dieser Ansatz Skalierbarkeit und technologische Freiheit unterstützt.
In Teil 1 der umgekehrten Architekturbewertung gab es eine kurze Einführung, nun machen wir uns an die auffälligsten Elemente der Netflix-Architektur. Ein sehr zentrales Merkmal der Netflix-Architektur ist der Einsatz von Microservices. Der Trend ist praktisch mit Netflix großgeworden - Hier beleuchten wir wie Netflix die Idee von Microservices lebt und was das für Rückschlüsse auf die Qualitätsmerkmale und Ziele von Netflix erlaubt, bzw. mit welchen Herausforderungen und Kompromissen Netflix lebt.
Microservices sind nicht formal definiert. Am häufigsten werden Martin Fowler/James Lewis oder Chris Richardson zitiert. “In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.” (James Lewis, Martin Fowler)
Nun ist diese „Definition“ nicht sehr scharf und Mircoservices werden in der Praxis sehr unterschiedlich gelebt. In diesem Artikel von Martin Fowler werden jedoch Eigenschaften identifiziert, die die meisten Microservice-Architekturen einen:
Dabei ist die Größe der wohl am meisten umstrittene Punkt. Von der Daumenregel jeder Service hat maximal 100 Zeilen Code bis zum Prinzip Microservices an den „Bounded Contexts“ einer Domäne festzumachen (ein Konzept aus dem Domain Driven Design, das eher der klassischen Komponente oder einem Subsystem entspricht) ist alles dabei. Pragmatisch betrachtet ist eine allgemeine Regel nicht ausreichend. Die Größe der Services wird sich an Einflussfaktoren wie der Teamgröße und –aufteilung, der Reife im Deployment oder der Komplexität der Domäne festmachen. In Teil 4 werde ich insbesondere den Aspekt beleuchten, dass gerade eine große Anzahl an Microservices hohe Ansprüche an Automatisierung und Deployment stellen.
Netflix besteht aus über 600 Services, die sie selbst Applikationen nennen. Viele Services sind eher technischer Natur, sammeln Daten für Auswertungen oder kontrollieren die Lebendigkeit des Systems. Fachlich motivierte Services gibt es allerdings auch zur Genüge. Ein paar Beispiele, um die Granularität etwas zu illustrieren:
Das Bild unten zeigt einen (vereinfachten) strukturellen Überblick von Netflix. Nicht gezeigt ist der gesamte Bereich des Content Delivery Networks „Open Connect“, das sich um die Speicherung und Verteilung der eigentlichen Video-Inhalte kümmert. Einige Services werden in Wirklichkeit breiter eingesetzt als dargestellt. Für eine erste Näherung sollte das Bild jedoch genügen.
Netflix Struktursicht (vereinfacht)
Alles unterhalb des Load-Balancing ist ein Service (oder eine Applikation nach Netflix-Sprech). Die Benennungen rechts zeigen die unterschiedlichen Service-Kategorien von Netflix. Fachliche Mid-Tier-Services werden ergänzt um technische Plattform Services und Services zur einfacheren Speicherung oder Kommunikation. Alle Services laufen in einem separaten Prozess. Die eingezeichnete Schichtung ist lediglich zum besseren Verständnis gezeigt. Services der gleichen Ebene sind genauso isoliert voneinander wie Services unterschiedlicher Ebenen. Die Kommunikation zwischen Services erfolgt allermeist über HTTP und REST – dieser Weg wird für die Teams durch den Plattform Service Ribbon stark vereinfacht.
Wie sieht es technologisch aus? Hier arbeitet Netflix durchaus polyglott, wenn auch mit starker Schlagseite. Als Programmiersprache kommen unter Anderem Java, Scala, JavaScript, Dart, C++, Groovy, Python und Ruby zum Einsatz. Als Persistenzlösung neben Cassandra auch in-memory caches (ebenfalls ein eigenes Netflix Service), Amazon S3, sowie noch immer MySQL – ein Überbleibsel aus den alten Tagen mit eigenem Datenzentrum. Aufgrund des Toolings und der bereitgestellten Hilfen für Teams tendieren die meisten Services stark zum Einsatz von Apache Tomcat, Java, und Cassandra. Vorschriften gibt es hier jedoch nicht (mehr dazu im folgenden Abschnitt)
Die Teams von Netflix sind vollumfänglich für ihre Services verantwortlich. Das beinhaltet Design, Entwicklung, Release, Deployment und Betrieb. Diese Verantwortung ist auch treibend: Es gibt hohe Ansprüche an die Fehlertoleranz oder an das Antwortverhalten von Services. Solange die eingehalten werden (Verantwortung) wird dem Team in Design und Umsetzung freie Hand gewährt (Freiheit). Freedom and Responsibility ist ein zentrales Prinzip von Netflix. Es gibt also wenige technologische Vorgaben, Teams können fast nach Belieben releasen und deployen, es gibt keine klassische Management-Steuerung oder Beeinflussung durch eine zentrale Instanz. Wie das alles nicht im Chaos endet? Ein Schlüssel ist die stark toolgestütze und automatisierte Umgebung für Entwicklung und Deployment, inklusive einer herausragenden Monitoring-Unterstützung (mehr dazu in Teil 4 dieser Serie). Ein zweiter Schlüssel ist die Art von Netflix den Teams bestimmte Entscheidungen nahe zu legen. Es gibt zwar keine Vorgaben, aber Optionen die vereinfacht oder stark gefördert werden. Cassandra ist z.B. sehr gut mit Tooling versorgt, das man sich sonst selber schreiben müsste. Gleiches gilt für die REST-Kommunikation und andere Aspekte. Außerdem werden bestimmte Technologien oder Konzepte auf internen Konferenzen hochgejubelt und der Einsatz wird mit Anerkennung belohnt (so gesehen bei Reactive Extensions).
Die Freiheit wird bei Netflix also groß geschrieben, allerdings teilweise auch gelenkt, wenn es um Skalierbarkeit oder Verfügbarkeit geht. Jedes Unternehmen das auf Microservices setzt muss sich mit diesem Kompromiss auseinandersetzen. Ziel sollte immer die größtmögliche Freiheit sein um passende und schnell verfügbare Lösungen zu fördern. Überschrieben wird diese Freiheit nur durch die allerwichtigsten Geschäftsziele, die als Kompromiss im Weg stehen.
Was kann man aus dem Einsatz von Microservices bei Netflix für Rückschlüsse auf deren Ziele und Rahmenbedingungen ziehen?
Wir werden diese Rückschlüsse mitnehmen und im letzten Teil dieser Serie noch einmal zusammenfassend mit den anderen Teilen dieser Serie aufgreifen.
Teil 1: Die umgekehrte Architekturbewertung
Teil 2: Microservices
Teil 3: Netflix Open Source Services (OSS)