In einem Blogbeitrag aus dem Jahr 2016 hat Netflix bekanntlich seine siebenjährige Migrationsreise in die Cloud detailliert beschrieben . Der Artikel geht auf die damals radikale Entscheidung des Unternehmens ein, seine gesamte IT-Infrastruktur auf Amazon Web Services (AWS) zu standardisieren, nur zwei Jahre nachdem AWS 2006 öffentlich eingeführt wurde. Wie so viele grundlegende Infrastrukturinnovationen vor seiner Zeit hob Netflix die Vorteile der Abstrahierung bestimmter Aspekte des Softwareentwicklungslebenszyklus hervor – in diesem Fall dort, wo Anwendungen ausgeführt werden.

Es war nicht der schwierige Teil, alle Systeme des Unternehmens unverändert aus einem Rechenzentrum in AWS zu transportieren. Die größte Herausforderung bei der siebenjährigen Migration war die Entscheidung von Netflix, die Art und Weise, wie Anwendungen erstellt, verwaltet und bereitgestellt werden, grundlegend zu ändern. Architektonisch hat das Unternehmen seine Dienste von einer monolithischen App auf Hunderte kleinerer Microservices migriert. Dies hat Netflix letztendlich zu einem Cloud-nativen Unternehmen gemacht. AWS hat uns vielleicht gezeigt, was in Bezug auf die Ausführung von Anwendungen in der Cloud möglich ist, aber Netflix hat uns die Blaupause dafür gegeben, wie Anwendungen auf Cloud-native Weise erstellt und bereitgestellt werden.

Als die Architektur von Netflix auf Tausende von Mikrodiensten skaliert wurde, die jeweils ihre eigene spezifische Funktion erfüllten, benötigte das Unternehmen eine Möglichkeit, wie all diese Anwendungen und Dienste miteinander kommunizieren können, damit die zu einem bestimmten Zeitpunkt gespeicherten Daten korrekt und vollständig sind. dass ein Workflow zwischen Diensten seine beabsichtigte Aktion und Aktivität abgeschlossen hat; dass der Arbeitsablauf geprüft werden könnte; und dass das System wusste, wie es mit Fehlern umgehen sollte, wenn etwas passierte, das den Workflow unterbrach. Dies wurde als Workflow-Orchestrierung bekannt.

Herkömmlicherweise wurden Anwendungs- und Service-Workflows ad hoc orchestriert, indem eine Kombination aus Pub/Sub verwendet, direkte REST-API-Aufrufe durchgeführt und eine Datenbank verwendet wurde, um den Status dieser Workflows zu verwalten. Je mehr Anwendungen von monolithischen zu Microservice-basierten Architekturen migrierten und die Koordination von Workflows eine Choreographie über mehrere Services hinweg erforderte, desto komplexer wurde die Erfüllung einer Geschäftsfunktion.

Geben Sie Orkes ein *

Während seiner Zeit bei Netflix leistete ein Team von Ingenieuren Pionierarbeit bei der Lösung für Anwendungs- und Microservice-Workflow-Orchestrierung, die das Open-Sourcing einer Technologie namens Conductor beinhaltete. Unternehmen wie Tesla, GitHub, American Express und viele andere aus Branchen wie Finanzen, Gesundheitswesen und Versicherungen standen vor denselben Herausforderungen. Entwickler begannen, die Workflow-Logik von der Anwendungslogik zu entkoppeln, und Conductor wurde de facto zum zentralen Weg, um verteilte Workflows zu schreiben, auszuführen, zu visualisieren und zu verfolgen.

Nach einer kurzen, anschließenden Dienstreise bei Unternehmen wie Uber, Google, Robinhood und Redfin tat sich das ursprüngliche Netflix-Team hinter Conductor – bestehend aus Viren Baraiya , Jeu George und Boney Sekh – mit Dilip Lukose zusammen , der Produktteams bei geleitet hatte AWS und Azure, da er die gleichen Herausforderungen der Microservices-Orchestrierung sah, die von Conductor gelöst wurden, als er bei Redfin war. Gemeinsam gründeten sie Orkes, um für die Anwendungs- und Microservice-Workflow-Orchestrierung das zu tun, was Netflix vor einem Jahrzehnt für die Anwendungsentwicklung getan hat: es Cloud-nativ zu machen.

Mit über fünf Jahren Open-Source- und Netflix-getesteter Technologie dahinter wird die Conductor-Plattform von Unternehmen wie Netflix für die Bildverarbeitung und Inhaltsmigration verwendet; Tesla für Auftragsmanagement-Workflows; GitHub zum Orchestrieren von GitHub-Aktionsaufgaben; Swiggy für die Verwaltung seines Bestellsystems; und Oracle für die Unterstützung seines Bankprodukts. Es gibt Hunderte weitere Unternehmen, die Conductor verwenden, um Workflows in Cloud-nativen Anwendungen zu erstellen und zu verwalten, und eine wachsende Open-Source-Community mit über 4.000 GitHub-Stars, 1.300 Projektverzweigungen und 160 Mitwirkenden im Zusammenhang mit dem Projekt. Die Nachfrage nach verstärktem Cloud-Support und Unternehmensfunktionen zur Verbesserung von Conductor-Bereitstellungen wird nun mit der Einführung von Orkes realisiert.

Orkes und Netflix arbeiten eng zusammen, um die Open-Source-Conductor-Community zu unterstützen, sowohl durch die Zusammenarbeit an der Veröffentlichungs-Roadmap von Conductor OSS als auch durch Veranstaltungen. Kürzlich veranstalteten Netflix und Orkes ein gemeinsames Treffen, an dem über 80 Entwickler von Unternehmen wie GE, JP Morgan Chase, Microsoft, Salesforce, SAP, Slack, VMWare, Walmart und Zoom teilnahmen. In der Dirigenten-Community herrscht bereits große Aufregung darüber, was Orkes tut, um sie zu unterstützen.

Wir freuen uns, unsere Investition in Orkes bekannt zu geben, da das Unternehmen weiterhin Pionierarbeit in seiner Technologie leistet und sich zu einer Cloud-gehosteten, vollständig verwalteten Version von Netflix Conductor für die breite Masse entwickelt.