Netflix-Architektur Blogserie – Teil 2: Microservices

By 5. August 2015 Januar 26th, 2016 Inhaltliches

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 – Was ist das?

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:

  • Zerlegung in relativ kleine (fachliche) Services
  • Services sehr lose gekoppelt
  • Services einzeln installierbar und upgradebar
  • Dezentrale Datenhaltung
  • Hoher Freiheitsgrad bei Technologieauswahl

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.

Microservices & Netflix

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:

  • Registrierung (Sign-up)
  • Suche (Search)
  • Empfehlungen (Recommendation)
  • Bewertungen (Ratings)
  • Leihhistorie (Rental History)

Hinter jeder Seite, die man als Benutzer bei Netflix bedient, sind also mehrere Services in Aktion. Netflix selbst spricht von etwa 20-30 Prozessen im Front-Tier.

Bild 2 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)

Der organisatorische Aspekt

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.

Auswirkungen und Rückschlüsse

Was kann man aus dem Einsatz von Microservices bei Netflix für Rückschlüsse auf deren Ziele und Rahmenbedingungen ziehen?

  1. Verfügbarkeit ist wichtig. So wichtig dass sogar das zentrale Prinzip „Freedom and Responsibility“ verletzt wird.
  2. Neue Technologien oder Frameworks sollen leicht ausprobiert werden können. Nicht das Gesamtsystem, sondern nur Systemteile können als Versuchsumfeld dienen und reales Feedback geben, ob sich eine breitere Adoption lohnt. Der Technologie-Stack kann so auch nach und nach modernisiert werden. Das spricht für eine langfristige Ausrichtung des Produkts.
  3. Fehler in einzelnen Services zu isolieren und nicht auf andere Services überspringen zu lassen ist wichtiger als der Gesamtaufwand oder das letzte Quäntchen Performanz. Deshalb die strikte und feingranulare Auftrennung der Services – eine wichtige Resilience-Grundlage.
  4. Gute Time-to-Market für neue Funktionalität ist wichtiger als Konsistenz und auch insgesamt weit oben in der Qualitätshierarchie anzusiedeln. Netflix betreibt hohe Aufwände um trotz der hohen Verfügbarkeitsanforderungen auch schnell neue Funktionalität auszuliefern.
  5. Einige Herausforderungen bestehen bei diesem Ansatz und scheinen für Netflix eine untergeordnete Rolle zu spielen:
    • Die Gesamtmenge der verwendeten Technologien ist sehr heterogen. Das erschwert Service-übergreifende Wiederverwendbarkeit, Teamwechsel einzelner Entwickler oder konsequente Standardisierung.
    • Abstimmung oder Koordination von Features und ein abgestimmtes Deployment sind schwer erreichbar. Überhaupt ist teamübergreifende Planung schwierig, die Koordination von 600+ Services sowieso. Kein starker Management-Druck also. Mehr in Teil 4 dieser Serie.
    • Jedes Service-Team muss Know-How für eigentlich querschnittliche Themen haben. Das wird durch Plattform-Sevices etwas entschärft (siehe Teil 3), ist jedoch immer noch ein anspruchsvolles Umfeld. Netflix hat also eher gute Leute zur Verfügung.

Wir werden diese Rückschlüsse mitnehmen und im letzten Teil dieser Serie noch einmal zusammenfassend mit den anderen Teilen dieser Serie aufgreifen.

Leave a Reply