Dans un billet de blog publié en 2016, Netflix a détaillé son parcours de migration de sept ans vers le cloud. L'article passe en revue la décision alors radicale de l'entreprise de standardiser toute son infrastructure informatique sur Amazon Web Services (AWS), deux ans seulement après le lancement public d'AWS en 2006. Comme tant d'innovations d'infrastructure fondamentales avant l'heure, l'effort de Netflix a mis en évidence les avantages de l'abstraction de certains aspects du cycle de vie du développement logiciel - dans ce cas, l'endroit où les applications sont exécutées.

Transférer tous les systèmes de l'entreprise, inchangés, d'un centre de données vers AWS n'était pas la partie la plus difficile. Le plus grand défi de cette migration de sept ans a été la décision de Netflix de changer fondamentalement la façon dont les applications étaient construites, créées, gérées et déployées. Sur le plan architectural, l'entreprise a fait migrer ses services d'une application monolithique vers des centaines de microservices plus petits. C'est ce qui a finalement transformé Netflix en une entreprise "cloud-native". AWS nous a peut-être montré ce qu'il était possible de faire en termes d'exécution d'applications dans le nuage, mais Netflix nous a donné le modèle de création et de déploiement d'applications dans le nuage.

Au fur et à mesure que l'architecture de Netflix évoluait vers des milliers de microservices qui remplissaient chacun une fonction spécifique, l'entreprise avait besoin d'un moyen pour que toutes ces applications et tous ces services communiquent entre eux afin que les données stockées à un moment donné soient exactes et complètes, qu'un flux de travail entre services effectue l'action et l'activité prévues, que le flux de travail puisse être audité et que si quelque chose se produisait et interrompait le flux de travail, le système sache comment gérer les erreurs. C'est ce qu'on a appelé l'orchestration du flux de travail.

Traditionnellement, les flux d'applications et de services étaient orchestrés de manière ad hoc en utilisant une combinaison de pub/sub, en effectuant des appels directs d'API REST et en utilisant une base de données pour gérer l'état de ces flux. Comme de plus en plus d'applications ont migré d'architectures monolithiques à des architectures basées sur des microservices et que la coordination des flux de travail exigeait une chorégraphie entre plusieurs services, la complexité pour remplir une fonction commerciale a augmenté.

Enter Orkes*

Pendant qu'elle était chez Netflix, une équipe d'ingénieurs a été la première à trouver une solution pour l'orchestration des flux de travail des applications et des microservices, ce qui a impliqué l'open-sourcing d'une technologie appelée Conductor. Des entreprises telles que Tesla, GitHub, American Express, et bien d'autres dans des secteurs tels que la finance, les soins de santé et les assurances ont rencontré les mêmes difficultés. Les développeurs ont commencé à découpler la logique de flux de travail de la logique applicative et Conductor est devenu le moyen de facto d'écrire, d'exécuter, de visualiser et de tracer des flux de travail distribués de manière centralisée.

Après un bref passage dans des entreprises telles que Uber, Google, Robinhood et Redfin, l'équipe originale de Netflix à l'origine de Conductor - composée de Viren Baraiya, Jeu George et Boney Sekh- s'est associée à Dilip Lukose, qui avait dirigé des équipes de produits chez AWS et Azure, car il avait vu les mêmes défis d'orchestration de microservices résolus par Conductor lorsqu'il était chez Redfin. Ensemble, ils ont fondé Orkes pour faire pour les applications et l'orchestration du flux de travail des microservices ce que Netflix a fait il y a dix ans pour le développement d'applications : le rendre natif en nuage.

Avec plus de cinq ans de technologie open-source et testée à l'échelle de Netflix derrière elle, la plateforme Conductor est utilisée par des entreprises telles que Netflix pour le traitement d'images et la migration de contenu ; Tesla pour les flux de gestion des commandes ; GitHub pour orchestrer les tâches d'action de GitHub ; Swiggy pour gérer son système de commande ; et Oracle pour alimenter son produit bancaire. Des centaines d'autres entreprises utilisent Conductor pour créer et gérer des flux de travail à travers des applications cloud-natives, et une communauté open-source en pleine expansion avec plus de 4 000 étoiles GitHub, 1 300 forks de projet et 160 contributeurs liés au projet. La demande d'une prise en charge accrue du cloud et de fonctionnalités d'entreprise pour améliorer les déploiements de Conductor se concrétise maintenant avec le lancement d'Orkes.

Orkes et Netflix travaillent en étroite collaboration pour soutenir la communauté open-source de Conductor, à la fois en collaborant à la feuille de route de la version OSS de Conductor, mais aussi par le biais d'événements. Récemment, Netflix et Orkes ont organisé une rencontre conjointe à laquelle ont participé plus de 80 développeurs d'entreprises telles que GE, JP Morgan Chase, Microsoft, Salesforce, SAP, Slack, VMWare, Walmart et Zoom. Il y a déjà beaucoup d'excitation dans la communauté Conductor à propos de ce que Orkes fait pour les soutenir.

Nous sommes ravis d'annoncer nos investissements dans Orkes, alors que la société continue de faire progresser sa technologie et d'évoluer vers une version hébergée dans le nuage et entièrement gérée de Netflix Conductor pour les masses.