Le déploiement continu nécessaire pour servir des séries TV et des films à plus de 75 millions de spectateur.trice.s par Netflix est expliqué dans un post de blog par trois de leurs employés : Ed Bukoski, Brian Moyles et Mike McGarr.
Le pattern Immutable Server ("serveur immuable") est à la base des déploiements de Netflix. Chaque déploiement créé une Amazon Machine Image (AMI) toute neuve.
L'architecture microservices de Netflix rend ses équipes relativement indépendantes. Chaque équipe pousse ses modifications à son propre rythme.
Netflix n'impose aucun outil à ses équipes, mais elles sont responsables de la maintenance des outils qu'elles implémentent. Des équipes centralisées de Netflix mettent à disposition de ses ingénieur.e.s, des outils qui servent de "feuille de route" afin de réduire leur charge cognitive.
La "feuille de route" des livraisons de code est constituée de plusieurs étapes. Le code est buildé et testé localement en utilisant Nebula. Les modifications sont commitées sur un repo central Git. Une tâche Jenkins, build, teste et package l'application pour le déploiement. A l'aide de Spinnaker, la plateforme de livraison continue de Netflix, ces packages sont déployés sous la forme d'Amazon Machine Images (AMI).
Build
Nebula est un ensemble de plugins pour le système de build Gradle qui build, test et package les applications Java. La majorité du code de Netflix est rédigé en Java. Ces plugins s'appuient sur les fonctionnalités d'automatisation de Gradle pour inclure la gestion de dépendances, de release et de packaging. Le fichier de build contient les dépendances et les plugins nécessaires à chaque projet.
Intégration
L'étape suivante consiste à pusher sur un repo Git les sources préalablement testées et buildées localement. Les équipes choisissent elles-mêmes de quelle manière elles procèdent.
Le commit déclenche une tâche Jenkins qui build, test et package le code à déployer. Le type de package généré diffère selon qu'il s'agit d'une librairie ou d'une application.
Déploiement
La "Boulangerie" (Bakery) de Netflix expose une API qui permet de créer une AMI. En réalité, c'est Aminator qui se charge de créer l'image. L'utilisateur.trice détermine le modèle d'image et les packages à ajouter à l'AMI. L'image originelle est un environnement Linux qui contient les outils et les services communs à l'écosystème Netflix.
En cas de succès de la tâche Jenkins, se déclenche une pipeline Spinnaker. Spinnaker lit les packages Nebula et utilise l'API de la "Boulangerie" pour créer l'AMI.
Spinnaker met ensuite l'AMI à disposition de dizaines, de centaines, ou de milliers d'instances.
Le premier déploiement se fait sur l'environnement de test où il subit une batterie de tests d'intégration. S'il réussit les tests, Spinnaker fournit aux équipes la possibilité d'affiner leur processus de déploiement en production avec par exemple des déploiements multi-régions, des releases canaries (canary releases) ou encore des déploiements rouge/noir (red/black).
Pour illustrer l'efficacité de l'automatisation du processus, il suffit de 16 minutes pour faire passer le service de maintenance et de résilience cloud, le Janitor Monkey, de la vérification de code à un déploiement multi-régions.
Pistes futures
Il existe une demande croissante d'agnosticité du langage chez Netflix. Les langages non JVM ont besoin d'être incorporés au procédé de build.
Une grande partie du temps nécessaire au déploiement réside dans la cuisson au sein de la "Boulangerie" (Bakery) et Netflix essaye de le réduire.
Netflix cherche par ailleurs à voir si les conteneurs peuvent aider à relever ces deux défis.
Les conteneurs peuvent aussi améliorer le procédé de build, cuisson et déploiement, et ainsi améliorer leur cycles de développements et de tests. Un conteneur qu'on peut déployer localement et en production sans modification, aiderait à déterminer si un bug est dû à une différence d'environnement. Cela permet aux ingénieur.e.s de se concentrer sur les nouvelles fonctionnalités.