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

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 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 1: Die umgekehrte Architekturbewertung
Teil 2: Microservices
Teil 3: Netflix Open Source Services (OSS)