Chez Edgegap, nous nous sommes concentrés sur la simplification de l'utilisation des infrastructures distribuées pour les développeurs. Notre plateforme, basée sur la conteneurisation et les micro-services, automatise le déploiement et la gestion des serveurs de jeux sur une infrastructure hautement distribuée afin que les studios de jeux puissent se concentrer sur ce qui est important pour leur jeu et leurs joueurs. Nous rencontrons parfois des studios de jeux qui comparent ce que nous faisons avec le projet Agones. Cependant, nous avons constaté par expérience qu'Agones n'a pas été conçu pour une haute distribution, et les coûts de fonctionnement et de gestion peuvent rapidement devenir prohibitifs.

Kubernetes se dirige vers le même chemin que les serveurs de messagerie

Il y a dix ans, chaque entreprise hébergeait et gérait ses propres serveurs de messagerie. Microsoft vendait des licences pour son serveur de messagerie sur site, Microsoft Exchange, comme des bonbons. Aujourd'hui ? La plupart des PME utilisent un serveur de messagerie géré. Microsoft ne publie pas la répartition entre les licences Office 365 et Exchange auto-hébergées, mais elles sont directement corrélées dans la direction opposée. Dans quelques années, il en sera de même pour Kubernetes et les services construits dessus, tels qu'Agones.

Agones n'est-il pas juste un logiciel simple ?

En surface, Agones se présente comme un rêve pour la plupart des développeurs de jeux travaillant sur des jeux multijoueurs. C'est un logiciel de gestion de flotte open-source construit sur Kubernetes pour gérer et faire évoluer les serveurs de jeux à la demande.

Cependant, les équipes de développement réaliseront rapidement que le rêve peut se transformer en cauchemar. Faire fonctionner Agones est à la fois difficile et chronophage, même pour des équipes expérimentées. Cela nécessite une compréhension approfondie de la technologie elle-même et le bon type d'expertise pour maintenir et gérer correctement le cluster. Cela est particulièrement vrai pour les clusters hautement distribués, qui peuvent être encore plus complexes. À mesure que le nombre de régions et de pays augmente, la complexité de la gestion du déploiement et de la configuration du cluster augmente également, ce qui peut rendre difficile de s'assurer que tous les composants du cluster sont correctement configurés et fonctionnent ensemble.

Étant un projet open-source, le coût du logiciel Agones lui-même est généralement gratuit, ce qui semble génial. Cependant, vous réaliserez rapidement que les coûts et les ressources nécessaires pour le configurer et le gérer peuvent devenir écrasants.

Installer et gérer Agones nécessite une bonne compréhension de Kubernetes (K8), des systèmes d'exploitation Linux et une maîtrise d'un langage de programmation comme Python ou Go. De plus, les ingénieurs doivent avoir une expérience avec les technologies de conteneurisation telles que Docker et containerD et être familiarisés avec le réseau, la sécurité et l'automatisation. Enfin, votre équipe doit avoir des connaissances sur les technologies basées sur le cloud ou le matériel sur site. C'est probablement pourquoi les ingénieurs DevOps dans la région de la baie gagnent, en moyenne, 200k USD par an.

Le coût de l'infrastructure sous-jacente dépendra de l'endroit où vous choisissez d'héberger votre(s) cluster(s) Kubernetes. Par exemple, supposons que vous l'hébergiez sur votre matériel. Dans ce cas, le coût sera le prix des serveurs physiques, l'électricité et d'autres ressources nécessaires pour les faire fonctionner, ainsi que l'assurance pour le bâtiment, les ingénieurs et tout ce qui se trouve entre les deux. Si vous l'hébergez chez un fournisseur de cloud, le coût sera le prix des machines virtuelles et de tous les autres services que vous utilisez, tels que le stockage et le réseau. En tant que personne essayant de comprendre les factures cloud chaque mois, je confirme que cela peut rapidement se transformer en une facture coûteuse (IP publique, trafic réseau, équilibreurs de charge, stockage, appels API, frais de support…)

En plus des coûts d'infrastructure et de logiciels, il peut y avoir des coûts associés à d'autres outils ou services que vous utilisez avec Kubernetes. Par exemple, vous devrez peut-être payer pour un équilibreur de charge, des services de surveillance et de journalisation, ou une plateforme d'intégration et de déploiement continu (CI/CD). Les coûts spécifiques dépendront des outils et des services que vous choisissez.

Ne vous trompez pas, vous pourriez penser qu'une machine virtuelle à 50 $ par mois suffira pour faire fonctionner ce logiciel open-source, mais la réalité est bien différente.

Vers des services gérés

Comme la transition des serveurs Exchange il y a quelques années, les services gérés ont commencé à remplacer l'auto-hébergement. L'utilisation d'un service Kubernetes entièrement géré offre de nombreux avantages. Pour commencer, cela vous décharge de la gestion et de la maintenance du cluster. Cela peut faire gagner à votre équipe un temps et des efforts considérables, leur permettant de se concentrer sur des tâches plus importantes.

De plus, un service entièrement géré peut fournir un accès à un support et à des conseils d'experts. Cela peut être particulièrement utile pour les organisations nouvelles en matière de Kubernetes ou incertaines sur la meilleure façon d'exploiter la technologie. Avec un service géré, vous pouvez obtenir de l'aide et des conseils de la part de professionnels expérimentés ayant une compréhension approfondie de la technologie et pouvant fournir des idées et des conseils précieux.

Un autre avantage d'utiliser un service Kubernetes entièrement géré est la capacité à évoluer rapidement et facilement. Une fois que votre organisation grandit et que vos charges de travail deviennent plus complexes, un service géré peut offrir la flexibilité et l'évolutivité nécessaires pour suivre. Cela est particulièrement important pour les clusters hautement distribués, qui peuvent être difficiles à gérer et à faire évoluer de manière indépendante. Votre objectif est de créer un jeu génial et réussi plutôt que de gérer la plomberie sous-jacente qui sert votre jeu aux joueurs.

Dans l'ensemble, utiliser un service Agones/Kubernetes entièrement géré peut offrir de nombreux avantages, notamment un gain de temps et d'efforts, un accès à un support d'experts et la capacité de se développer rapidement et facilement.

La véritable question est : avez-vous vraiment besoin d'Agones en premier lieu ?

Kubernetes a été initialement conçu pour les technologies basées sur le Web. Elles gèrent des milliers de connexions sans état, servant de petites demandes pendant une fraction de seconde. Les serveurs de jeux sont à l'opposé de cette philosophie. Les serveurs de jeux et les relais sont avec état, gérant des connexions persistantes de 5 à 45 minutes.

Industrie du jeu est habituée à configurer autant de serveurs que possible et à les avoir "en attente" pour que les joueurs se connectent. AWS Gamelift a été un précurseur de cette architecture. Avec cette architecture à l'esprit, Agones est un CRD pour permettre de tels serveurs d'attente au sein de Kubernetes. Cependant, avoir des instances en attente n'est pas nécessaire et apporte peu de valeur considérant que Kubernetes n'est pas destiné à gérer de telles applications avec état en premier lieu.

La réalité est que depuis son lancement en 2018, Agones a été une solution à la recherche d'un problème. Il est trop complexe pour les petites équipes à configurer et à gérer, et il ne résoudra pas le problème des équipes plus grandes ayant besoin de serveurs hautement distribués.

Prendre le bon côté de l'architecture d'Agones, laisser le mauvais derrière (ou à quelqu'un d'autre)

Agones prend comme entrée de votre part, le développeur de jeux, une image de conteneur. Pour ceux qui ne le savent pas, les conteneurs sont une technologie populaire pour déployer et exécuter des applications de manière légère et portable. Ils offrent plusieurs avantages par rapport aux machines virtuelles et serveurs bare metal, notamment une efficacité accrue, une portabilité et une flexibilité.

Un des principaux avantages des conteneurs est qu'ils sont plus efficaces que les machines virtuelles ou les serveurs bare metal. Les conteneurs partagent le système d'exploitation de l'hôte, tandis que chaque machine virtuelle fonctionne sur son système d'exploitation invité, ce qui peut être gourmande en ressources. En partageant le système d'exploitation de l'hôte, les conteneurs peuvent utiliser moins de ressources et offrir une meilleure performance que les machines virtuelles.

Un autre avantage des conteneurs est leur portabilité. Contrairement aux machines virtuelles, qui sont liées à un hyperviseur spécifique et à un système d'exploitation hôte, les conteneurs peuvent être facilement déplacés entre différents environnements et plateformes. Cela facilite le déploiement et l'exécution de vos applications sur différentes infrastructures, que ce soit sur site, dans le cloud, ou dans une configuration hybride.

En plus de l'efficacité et de la portabilité accrues, les conteneurs offrent également une plus grande flexibilité. Avec les conteneurs, vous pouvez facilement empaqueter et déployer votre jeu et ses dépendances en tant qu'unité unique, ce qui facilite la mise à jour et la maintenance de vos applications. Cela peut être particulièrement utile pour les architectures microservices, où les applications sont décomposées en composants plus petits et indépendants.

Vitesse contre faire soi-même

Il existe une multitude de nouveaux fournisseurs proposant des environnements SaaS pour les développeurs de jeux afin d'héberger et de gérer le cycle de vie de leurs jeux sans avoir à s'occuper d'Agones et Kubernetes. Pour une raison quelconque, l'industrie du jeu a tendance à essayer de réinventer la roue constamment, et Agones en est un des exemples. D'un point de vue coût à la vitesse et la qualité de service, le seul moteur pour gérer Agones en interne est de satisfaire les développeurs back-end qui souhaitent continuer à gérer des serveurs au lieu de faire un travail productif de développement de jeux. À la fin de la journée, le studio de jeux et les joueurs en payent souvent le prix.