Tag

netflix-blogserie Archives - embarc

Netflix-Architektur Blogserie – Teil 3: Netflix Open Source Services (OSS)

By | Allgemein, Inhaltliches | No Comments

In Teil 1 der umgekehrten Architekturbewertung gab es eine kurze Einführung, Teil 2 kümmerte sich um den Microservice-Ansatz von Netflix. Nun kommen wir zu einem Teil der Netflix-Architektur, der auch von Ihnen potentiell gut nutzbar ist, wenn Sie sich für eine ähnliche Architekturrichtung entscheiden: Die Open Source Services (kurz OSS) von Netflix. Sie bilden einen guten Teil dessen ab, was Netflix neben der eigenen Fachlichkeit an Services baut. Nicht alle Plattform-Services und andere technisch motivierten Services haben es in die Open Source Welt geschafft, aber es werden stetig mehr. Insgesamt erleichtert Netflix damit anderen Firmen den Einstieg in die Welt von Microservices. Doch was hat Netflix selbst davon?

Was leisten die OSSs?

Das folgende Bild zeigt die zentrale Architekturidee hinter den Open Source zur Verfügung gestellten Services. Auf Basis der Infrastruktur der Amazon Cloud wird eine Plattform etabliert, die es einfacher macht individuelle Software bzw. individuelle Services zu schreiben. Netflix selbst sagt: „The Netflix Open Source Platform Components fill gaps in Amazon Web Services. The goal is to make cloud infrastructure more robust, flexible and glitch free.”

Netflix OSS als PaaS (vereinfacht)

Ein schönes Zitat von Dianne Marsh zu den Open Source Services: „Das haben wir nicht für Euch gebaut, das haben wir gebaut, weil wir es brauchten, und es nicht da war. Aber jetzt ist es da.”. Einige Firmen bedienen sich dieser Plattform auch bereits. Yelp, Yahoo, Sincorp oder Hotels.com wären Beispiele, über das Spring Cloud Projekt und die dortigen Netflix-Abstraktionen kommt auch noch einmal ein breiteres Publikum in den Genuss einiger Services.

Wie passen die Komponenten dieser technischen Plattform nun zu den Microservices, die Netflix baut? In Teil 2 dieser Serie habe ich einen Architekturüberblick beschrieben. Im Folgenden ist der gleiche Überblick um die Information ergänzt, wo sich OSS Projekte einfügen (und wo AWS bereits hilft).

OSS und AWS Komponenten in der Netflix Architektur (vereinfacht)

Neben den Projekten die direkt der Struktur und dem laufenden Programm zugeordnet werden können hat Netflix auch OSSs für Deployment, Monitoring oder zum Test der Fehlertoleranz (die berühmte Simian Army). Auf einige dieser Projekte kommen wir in Teil 4 dieser Serie noch zu sprechen. Eine vollständige und aktuelle Liste der Projekte finden Sie unter https://github.com/netflix.

Auswirkungen und Rückschlüsse

Was kann man aus der OSS-Initiative von Netflix für Rückschlüsse auf deren Ziele und Rahmenbedingungen ziehen?

  1. Netflix braucht Entwickler. Die Open Source Services sind gut sichtbar und auf vielen Konferenzen präsent. Damit erscheint Netflix als Vorreiter und attraktiver Arbeitgeber. Mit den Open Source Services sinken die Anforderungen an jeden einzelne Entwickler – sie werden bei der Entwicklung von vielen technischen Details entkoppelt und auch die Infrastruktur ist einfacher einzubinden und anzusprechen. Das ermöglicht wiederum schnelleres Wachstum.
  2. Für Netflix ist schnelle Handlungsfähigeit und Time-to-Market wichtig. Entwickler kennen den Stack vermutlich bevor sie sich bei Netflix bewerben und neue Services sind schnell aufgesetzt. Funktionale Erweiterbarkeit scheint ein wichtiges Qualitätskriterium zu sein.
  3. Innere Qualität der Services ist relevant. Fachliche Services werden mit intern anerkannten technischen Lösungen ergänzt, die sich bewährt haben. Die technischen Services selbst werden durch das Open Source stellen in ihrer Qualität gefördert. Es gibt damit ein Mindestmaß an Dokumentation im Wiki oder Techblog und das Design wird aufgeräumt. Ideen von Anwendern helfen zusätzlich.
  4. Netflix muss Qualitätsanforderungen wie Verfügbarkeit und Skalierbarkeit sicherstellen. Viele OSS-Projekte kümmern sich um diese beiden Themen und man kann so spezialisierte Teams mit Experten auf die Lösungen ansetzen. Gleichzeitig verhindert man damit Wildwuchs in diesen heiklen Gebieten (siehe auch letzter Absatz dieses Posts).

Im abschließenden Teil (5) dieser Blogserie werde ich diese Rückschlüsse noch einmal verdichten und gemeinsam mit den anderen Erkenntnissen dieser Serie aufgreifen.

Ein spannender Aspekt der Open Source Plattform von Netflix ist übrigens, dass technische Konzepte und Ideen damit kommuniziert werden. Durch die Verwendung von Hystrix müssen sich die Service-Eigner weniger Gedanken um Ausfälle und Latenzprobleme machen, gute Architektur-Prinzipien und –Patterns werden automatisch umgesetzt. Ribbon erleichtert die RESTvolle Kommunikation und fördert damit deren Einsatz. Es steht Teams bei Netflix frei was sie machen, aber eine gewisse „Anti-Zähigkeit im Design“ leitet sie mehr oder weniger sanft in eine bestimmte Richtung. Wenn ein Team vom einfachen Weg abweicht hat es bestimmt einen Grund und hat sich das gut überlegt. Ein interessanter Ansatz der Architekturboards, Unternehmensstandards und Assessments etwas alt aussehen lässt. Diese und andere Techniken der Architekturgestaltung werde ich am 22. Oktober auf einer Session beim Architecture Gathering in München vorstellen. Titel: NoBullshit – Architekturarbeit neu gedacht.

Netflix-Architektur Blogserie – Teil 2: Microservices

By | Inhaltliches | No Comments

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.

Netflix-Architektur Blogserie – Teil 1: Die umgekehrte Architekturbewertung

By | Inhaltliches | No Comments

 
Netflix is the king of online streaming, using more global bandwidth than cat videos and piracy combined

Netflix – das größte Internet-Business in den USA – zeichnet sich zeitweise für ein Drittel des gesamten Downstream-Traffics des Webs verantwortlich. Über 2 Milliarden Stunden Filme und Serien sind für Mitglieder verfügbar (nicht in jedem Land, aber dennoch eine beeindruckende Zahl). Die Erfolge der Video-on-Demand Plattform basieren nicht nur auf einer guten Geschäftsidee, sondern auch auf top-modernen und effizienten Technologien, Frameworks und Architekturansätzen. Netflix ist nicht nur groß, sondern auch robust und hochgradig auf Benutzbarkeit ausgerichtet. Der Qualitätsanspruch ist enorm: „Netflix-Mitglieder können Serien und Filme schauen – so viele sie wollen, jederzeit, überall, auf fast jedem Internet-verbundenem Bildschirm”. Eine zentrale Ansage, ein Versprechen und eine Architekturherausforderung. Was können wir nun daraus lernen? Ist es an der Zeit unsere Systeme und Architekturen in Microservices zu refactoren, große Datenbanksysteme aufzubrechen, polyglott zu programmieren und reaktive Ansätze zu verwenden?
In dieser kleinen Blogserie wollen wir uns um die Beantwortung dieser Fragen kümmern. In einer umgekehrten Architekturbewertung haben wir jene Anforderungen und Rahmenbedingungen herausgearbeitet, die man haben müsste, um die Netflix-Architektur als ideal zu bewerten. Welche Qualitätsaussagen müssten Ihnen wichtig sein? Zu welchen Kompromissaussagen müssten Sie ‚ja‘ sagen? Welche Risiken müssten Sie eingehen und welche Rahmenbedingungen bräuchten Sie?

Architekturbewertung und umgekehrte Bewertung

Um herauszufinden in welchen Kontexten und für welche Fragestellungen die Architekturkonzepte von Netflix tauglich sind, haben wir uns bewährten Mitteln bedient. Architekturbewertungsmethoden leisten im Kern das, was wir hier brauchen. Sie gehen jedoch meist davon aus, dass der Kontext gesetzt ist und man ein System für die Eignung in diesem Kontext bewertet. Das folgende Bild zeigt einen konzeptionellen Überblick.

Wie Architekturbewertung grob funktioniert

Bewertungsmethoden wie die ATAM (Architecture Tradeoff Analysis Method), CBAM (Cost-Benefit-Analysis-Method) oder SACAM (Software-Architecture comparison Analysis Method) verfeinern die an die Architektur gestellten Ziele und Rahmenbedingungen bis zu konkreten Qualitätsaussagen (sogenannten Qualitässzenarien). Hält man diese Aussagen gegen die getroffenen Architekturentscheidungen und –ansätze offenbaren sich potentiell Risiken, Probleme oder Schwächen der Softwarelösung.

In der umgekehrten Architekturbewertung wollen wir nun genau den anderen Weg einschlagen. Wir gehen von der Lösung aus, sehen uns die Entscheidungen, Konzepte und Prinzipien an. Basierend darauf überlegen wir uns welche Ziele und Rahmenbedingungen man haben müsste bzw. Qualitätsaussagen einem wichtig sein müssten um solche Entscheidungen zu treffen. Das folgende Bild illustriert diesen Prozess.

Umgekehrte Architekturbewertung (Copyright embarc)

Wir werden in diesem Blogpost nun grob in die Welt von Netflix eintauchen und in weiteren Posts die Details der umgekehrten Bewertung zusammenfassen.

Neben diesen Beiträgen habe ich auch einen ausführlichen JavaMagazin-Artikel zu Verfügbarkeit und Resilience bei Netflix geschrieben der mittlerweile online verfügbar ist: Keine Angst vor Chaos

Wie groß ist groß?

Um zu verstehen wie groß die Herausforderung eigentlich ist, zeigt Abbildung 1 eine topologische Sicht auf Netflix. Die grünen Bereiche zeigen Services von Netflix. Insgesamt sind es über 600 verschiedene Services, die jeweils drei bis mehrere hundert Mal installiert sind. Der Übersicht halber zeigt Abbildung 1 diese Redundanz nicht. Die blauen Linien zeigen Abhängigkeiten bzw. Aufrufwege. Greift man auf die Webseite zu, trifft man etwa 20-30 Prozesse im Front Tier, dahinter wird es komplizierter.

Netflix: Topologie-Sicht. Screenshot aus AppDynamics (Quelle: A. Tseitlin, „Resiliency through failure“, QCon NY, 2013

Insgesamt arbeiten etwa 50-60 Teams an diesem System, das auf zehntausenden Ec2 Instanzen der Amazon Cloud (Amazon Web Services – AWS) betrieben wird.
Terabytes an Daten liegen in einem globalen Cassandra-Ring – und das schließt die Video-Dateien, also den eigentlichen Content NICHT ein.

Es ist eine gewisse Hürde ein solches System in einer realistischen Testumgebung nachzubauen, Daten(-verteilungen) und Benutzerverhalten realistisch zu simulieren und dieses System analytisch zu betrachten. Netflix möchte trotz allem äußerst innovativ bleiben, neue Features schnell ausliefern und damit den Vorsprung auf die Konkurrenz zumindest halten. 60 Teams in diesem Umfeld zu koordinieren ist schwierig, Konsistenz in allen Lösungsdetails nicht oder nur nur sehr aufwändig herstellbar. Kein Wunder, dass Netflix hier kreativ wurde und neue Architekturansätze suchte. Wir rollen Sie in den folgenden Posts Stück für Stück auf und zeigen ob sie generell anwendbar sind, ob es sich eher um Sonderlösungen handelt, oder ob um Netflix eher eine inhaltsleere Hype-Blase wächst.

Teil 2: Microservices bei Netflix wird zeigen wie Netflix die Architekturidee von Microservices lebt und welche Konsequenzen daraus erwachsen.
Die weiteren Teile dieser Blogserie:
Teil 3: Der Netflix Open Source Stack
Teil 4: Fachliche Weiterentwicklung und Deployment
Teil 5: Bewertungsergebnisse und Kompromissaussagen