Le mois dernier, nous avons commencé à partager le parcours DevOps de Microsoft en présentant les histoires de plusieurs équipes Microsoft et leur approche de l’adoption DevOps. Dans la suite de cette série, nous allons partager la transition d’une équipe d’un rôle d’exploitation classique à un rôle d’ingénierie de la fiabilité des sites (SRE, Site Reliability Engineering), celle de l’équipe xREO (Xbox Reliability Engineering and Operations).

Cette transition n’était pas facile et est devenue nécessaire lorsque Microsoft a décidé de mettre à disposition les jeux Xbox auprès des joueurs, où qu’ils se trouvent, via le streaming de jeux cloud (project xCloud). Pour fournir une technologie de pointe avec une expérience client de premier ordre, l’équipe a dû redéfinir sa façon de travailler, en améliorant la collaboration avec l’équipe de développement, en investissant dans l’automatisation et en étant impliquée dans les premières étapes du cycle de vie des applications. Dans ce billet de blog, nous allons examiner certains des principaux enseignements que l’équipe a retirés en cours de route. Pour explorer l’histoire complète de l’équipe, consultez le parcours de l’équipe xREO.

Des exigences de gameplay cohérentes et la nécessité de collaborer

Une expérience cohérente est essentielle à la réussite d’une session de streaming de jeu. Quand les joueurs ont accès à un jeu diffusé en streaming à partir du cloud, ils doivent avoir l’impression que le jeu s’exécute sur une console proche. Cela implique la création d’une solution cloud distribuée dans le monde entier et qui s’exécute sur de nombreux centres de données, proches des utilisateurs finaux. L’infrastructure mondiale d’Azure rend cela possible, mais le fait d’exploiter un système s’exécutant sur autant de régions Azure constitue un véritable défi.

Les développeurs Xbox qui ont commencé à concevoir et à créer cette technologie ont compris qu’ils ne pouvaient pas se contenter de créer ce système et de « renvoyer la balle » à l’équipe chargée des opérations. Les deux équipes ont dû se réunir et collaborer tout au long du cycle de vie de l’application afin que le système puisse être conçu dès le départ en prenant en considération la façon dont il fonctionnera dans un environnement de production.

Création de l’architecture d’une solution cloud en gardant son exploitation à l’esprit

Dans de nombreuses grandes organisations, il est courant de voir les équipes de développement et d’exploitation travaillant chacune dans leur propre silo. Les développeurs ne prennent pas toujours en compte l’exploitation lors de la planification et de la création d’un système, tandis que les équipes d’exploitation ne sont pas habilitées à toucher le code, même si elles le déploient et l’utilisent en production. Avec une approche SRE, la fiabilité du système est intégrée au cycle de vie complet de l’application et l’équipe qui exploite le système en production est un contributeur privilégié dans la phase de planification. Dans le cadre d’une nouvelle approche, impliquer l’équipe xREO dans la phase de conception a donné naissance à un environnement collaboratif, en effectuant des choix technologiques communs et en concevant un système capable de fonctionner avec les exigences nécessaires à la mise à l’échelle.

Tirer parti des conteneurs pour définir clairement l’appartenance

L’une des premières décisions techniques prises en commun par les équipes de développement et xREO fut d’implémenter une architecture de microservices utilisant des technologies de conteneur. Cela a permis aux équipes de développement de mettre en conteneur les microservices .NET Core qu’elles détenaient et de supprimer la dépendance de l’infrastructure cloud qui exécutait les conteneurs et était détenue par l’équipe xREO.

Une autre décision technologique prise en commun par les deux équipes a consisté à utiliser Kubernetes en tant que plateforme d’orchestration de conteneur sous-jacente. Cela a permis à l’équipe xREO de tirer parti d’Azure Kubernetes Service (AKS), plateforme cloud Kubernetes managée qui simplifie le déploiement de clusters Kubernetes, en éliminant une grande partie de la complexité opérationnelle à laquelle l’équipe aurait du faire face lors de l’exécution de plusieurs clusters dans plusieurs régions Azure. Ces choix conjoints ont permis d’éclaircir la propriété : les développeurs sont responsables de tout ce qui se trouve à l’intérieur des conteneurs et l’équipe xREO est responsable des clusters AKS et d’autres services Azure constituant l’infrastructure cloud hébergeant ces conteneurs. Chaque équipe est propriétaire du déploiement, de la surveillance et de l’exploitation de son rôle respectif en production.

Ce type d’approche crée une responsabilité claire et permet de faciliter la gestion des incidents en production, ce qui peut être très difficile dans une architecture monolithique où l’infrastructure et la logique d’application ont des dépendances de code et sont difficiles à démêler quand les choses vont mal.

Mise à l’échelle via l’automatisation de l’infrastructure

L’équipe xREO a mis en place une autre meilleure pratique, à savoir l’automatisation de l’infrastructure. Le déploiement manuel de plusieurs services cloud sur chaque région Azure n’était pas scalable et aurait pris trop de temps. À l’aide d’une pratique appelée IaC (Infrastructure as Code), l’équipe a utilisé des modèles Azure Resource Manager pour créer des définitions déclaratives d’environnements cloud qui autorisent les déploiements dans plusieurs régions Azure avec un minimum d’effort.

Avec l’infrastructure managée en tant que code, le déploiement peut aussi s’effectuer via l’intégration continue et la livraison continue (CI/CD) pour automatiser davantage le processus de déploiement de nouvelles ressources Azure sur des centres de données existants, la mise à jour des définitions d’infrastructure ou la mise en ligne de nouvelles régions Azure en cas de besoin. Les approches IaC et CI/CD ont permis à l’équipe de travailler à flux tendu, d’éviter les tâches banales répétitives et de supprimer la plupart des risques d’erreur humaine inhérents aux opérations manuelles. Au lieu de consacrer du temps au travail manuel et aux listes de vérification, l’équipe peut se concentrer sur l’amélioration de la plateforme et de sa résilience.

L’ingénierie de fiabilité des sites en action 

Le parcours de l’équipe xREO est né du besoin d’offrir la meilleure expérience client aux joueurs. C’est un excellent exemple qui montre comment les équipes qui souhaitent faire plaisir à des clients avec de nouvelles expériences par le biais de l’innovation de pointe doivent faire évoluer la façon dont elles conçoivent, créent et exploitent des logiciels. La véritable transformation de l’équipe xREO a été de basculer vers une approche orientée opérations et de collaborer plus étroitement avec les équipes de développement.

Avec cette nouvelle mentalité en place, l’équipe est à présent bien positionnée pour continuer à créer davantage de résilience et à mettre à l’échelle le système et, par conséquent, à proposer le streaming de jeux cloud à chaque joueur.

Ressources

• L’histoire complète de l’équipe xREO
• Témoignages supplémentaires : Le parcours DevOps chez Microsoft
• Microsoft Game Stack