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 distribution élevée, et les coûts de son exploitation et de sa gestion peuvent rapidement devenir prohibitifs.

Kubernetes se dirige dans la même direction 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 l'autre sens. Dans quelques années, on dira la même chose à propos de Kubernetes et des services construits au-dessus, tels qu'Agones.

Agones n'est-il pas simplement 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. Il s'agit d'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 devenir un cauchemar. Exécuter Agones est à la fois difficile et chronophage, même pour les é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. C'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 d'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 formidable. Cependant, vous réaliserez rapidement que les coûts et les ressources nécessaires pour le mettre en place 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 de l'expérience avec des technologies de conteneurisation telles que Docker et containerD et être familiers 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 sur le matériel sur site. C'est probablement pourquoi les ingénieurs DevOps de la baie gagnent, en moyenne, 200 000 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ébergez sur votre matériel. Dans ce cas, le coût sera le prix des serveurs physiques, l'électricité et d'autres ressources nécessaires à leur fonctionnement, 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 Google cloud chaque mois, je confirme que cela peut rapidement se transformer en une facture coûteuse (IP public, trafic réseau, équilibreurs de charge, stockage, appels API, frais de support…)

En plus des coûts d'infrastructure et de logiciel, il peut y avoir des coûts associés à tout outil ou service supplémentaire que vous utilisez avec Kubernetes. Par exemple, vous pourriez avoir besoin de 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 bercez pas d'illusions, vous pourriez penser qu'une machine virtuelle à 50 $ par mois suffira à faire fonctionner ce logiciel open-source, mais la réalité est tout autre.

Vers des services gérés

Comme la transition depuis les 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, il soulage votre équipe de la gestion et de la maintenance du cluster. Cela peut faire gagner à votre équipe un temps et des efforts précieux, 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 sur Kubernetes ou incertaines sur la meilleure façon d'utiliser la technologie. Avec un service géré, vous pouvez obtenir de l'aide et des conseils de professionnels expérimentés qui ont une compréhension profonde de la technologie et peuvent fournir des informations et des conseils précieux.

Un autre avantage de l'utilisation d'un service Kubernetes entièrement géré est la possibilité d'évoluer rapidement et facilement. Une fois que votre organisation grandit et que vos charges de travail deviennent plus complexes, un service géré peut fournir la flexibilité et l'évolutivité dont vous avez besoin pour suivre la demande. C'est particulièrement important pour les clusters hautement distribués, qui peuvent être difficiles à gérer et à faire évoluer de manière autonome. Votre objectif est de créer un excellent et réussi jeu 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, y compris des gains de temps et d'efforts, l'accès à un soutien d'experts et la possibilité de se développer rapidement et facilement.

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

Kubernetes a été initialement conçu pour des technologies basées sur le web. Il gère des milliers de connexions sans état, servant de petites demandes pour 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 pendant 5 à 45 minutes.

L'industrie du jeu a l'habitude de configurer autant de serveurs que possible et de les avoir "en attente" pour que les joueurs puissent se connecter. AWS Gamelift a été un précurseur de cette architecture. Avec cette architecture à l'esprit, Agones est un CRD qui permet de telles instances d'attente au sein de Kubernetes. Cependant, avoir des instances d'attente n'est pas nécessaire et apporte peu de valeur étant donné que Kubernetes n'est pas censé 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 de petites équipes à mettre en place et à gérer, et il ne résoudra pas le problème des grandes équipes ayant besoin de serveurs hautement distribués.

Tirez le bon parti de l'architecture d'Agones, laissez 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 aux serveurs bare metal, y compris 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 hôte, tandis que chaque machine virtuelle fonctionne sur son système d'exploitation invité, ce qui peut être gourmand en ressources. En partageant le système d'exploitation hôte, les conteneurs peuvent utiliser moins de ressources et offrir de meilleures performances 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érentes environnements et plateformes. Cela facilite le déploiement et l'exécution de vos applications sur d'autres infrastructures, que ce soit sur site, dans le cloud ou sur une configuration hybride.

En plus d'une efficacité accrue et d'une portabilité, 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 de microservices, où les applications sont décomposées en composants plus petits et indépendants.

Le temps de démarrage lent des serveurs d'Agones

Le dernier défi d'Agones est sa capacité à démarrer des serveurs de jeux rapidement pour répondre à l'expérience attendue des joueurs.

Comme le souligne son test en conditions réelles sur PUBG, le responsable de l'équipe DevOps de KRAFTON, JungHun Kim, a souligné que le temps de démarrage global des serveurs d'Agones lors de la montée en charge peut être de 10 à 15 minutes entre le provisionnement des instances (1-3 minutes), le démarrage des instances (2-3 minutes) et le provisionnement des pods (5-10 minutes) :

Cela signifie que les joueurs attendant le déploiement d'un serveur de jeux doivent faire la queue pendant que la ressource actuelle est recyclée. Plus concrètement, cela signifie qu'un serveur de jeux n'est pas en mesure d'être déployé et que les joueurs attendant en queue se frustrent et arrêtent de jouer à votre jeu multijoueur complètement, car 34 % d'entre eux abandonneront votre jeu selon le rapport sur la latence en ligne.

Pendant ce temps, grâce à son approche d'optimisation de la cohabitation, tous les jeux utilisant la plateforme d'Edgegap garantissent un temps de démarrage du serveur de jeu à partir d'un démarrage à froid en moyenne de 3 secondes d'après Philip Cote, CTO d'Edgegap.

La propriété d'Agones par Google

Bien qu'Agones se présente comme un logiciel open-source, il est effectivement contrôlé par Google.

Mark Mandel, le créateur d'Agones qui a quitté Google en 2024, l'a souligné dans un message sur le canal Slack d'Agones. Il a noté que bien que la communauté puisse contribuer des améliorations, seule Google a l'autorité de les approuver. Dans cet exemple, il a souligné que le “dernier release Helm avec la correction est cassé,” mais “je, ou tout autre contributeur n'étant pas dans Google, ne peut pas accéder au projet de production de Google, donc nous devrons attendre qu'ils corrigent les choses.”

Tout comme Google a une histoire d'abandon de projets qui l'intéressent moins, Agones pourrait facilement cesser de recevoir des mises à jour — le rendant vulnérable à des problèmes critiques, à des failles de sécurité, et plus encore. Chaque développeur devrait donc réfléchir à la question de savoir s'il souhaite lier son infrastructure à la volonté de Google de maintenir Agones. Comme le dit Mark lui-même : “Pour la longévité de ce projet, je ne pense sincèrement pas que nous puissions avoir un accès aux systèmes de production accessible seulement à Google.” À ce jour, Google n'a pas indiqué s'il avait l'intention d'offrir à la communauté Agones un accès plus large.

Voir ci-dessous le message complet de Mark Mandell :

Malheureusement, moi ou tout autre contributeur n'étant pas dans Google ne pouvons accéder au projet de production de Google, donc nous devrons attendre qu'ils corrigent les choses. Voir mon commentaire précédent dans le fil ci-dessus à propos de la rédaction d'une proposition pour déplacer cela vers la Linux Foundation -- pour la longévité de ce projet, je ne pense sincèrement pas que nous puissions avoir un accès aux systèmes de production accessible seulement à Google, et la communauté n'a aucune input ou supervision sur ce qui se passe dans ce projet Google Cloud.

• Mark Mandel, créateur d'Agones, 27 septembre 2025

Vélocité vs. Faites-le vous-même

Il existe une vague de fournisseurs émergents proposant des environnements SaaS pour que les développeurs de jeux hébergent et gèrent le cycle de vie de leurs jeux sans le tracas de la gestion d'Agones et de Kubernetes. Pour une raison quelconque, l'industrie du jeu a tendance à constamment essayer de réinventer la roue, et Agones est l'un de ces exemples. Du point de vue des coûts à la vélocité et à la qualité du service, le seul moteur pour gérer Agones en interne est de satisfaire les développeurs backend qui préfèrent continuer à gérer des serveurs plutôt que de faire un travail productif dans le développement de jeux. Au bout du compte, le studio de jeux et les joueurs paient souvent le prix.