Chez Edgegap, notre priorité a toujours été de simplifier l'utilisation des infrastructures distribuées pour les développeurs. Notre plateforme, basée sur la conteneurisation et les microservices, automatise le déploiement et la gestion des serveurs de jeu sur une infrastructure hautement distribuée afin que les studios puissent se concentrer sur ce qui compte vraiment : leur jeu et leurs joueurs.

Nous rencontrons parfois des studios de jeux vidéo qui comparent ce que nous faisons avec le projet Agones. Cependant, nous avons constaté que pour certains cas d'usage, Agones n'était pas idéal, et les coûts liés à son exploitation et à sa gestion peuvent rapidement devenir prohibitifs.

Kubernetes s'oriente-t-il vers les services gérés ?

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 petits pains. 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 les licences Exchange auto-hébergées, mais leur corrélation est directement inverse. D'ici quelques années, on dira probablement la même chose de Kubernetes et des services conçus par-dessus.

Agones n'est-il pas simplement un logiciel basique ?

Qu'implique réellement l'exploitation d'Agones ?

En apparence, Agones semble être un rêve pour la plupart des développeurs de jeux multijoueurs. Il s'agit d'un logiciel de gestion de flotte open-source conçu sur Kubernetes pour gérer et faire évoluer les serveurs de jeu à la demande.

Cependant, les équipes de développement s'aperçoivent souvent que la réalité opérationnelle est plus exigeante que prévu. L'exploitation d'Agones est à la fois complexe et chronophage, même pour des équipes expérimentées. Elle nécessite une compréhension approfondie de la technologie elle-même ainsi que l'expertise adéquate pour maintenir et administrer 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 gestion du déploiement et de la configuration du cluster s'accroît également, ce qui peut rendre difficile la garantie que tous les composants du cluster sont correctement configurés et fonctionnent ensemble.

S'agissant d'un projet open source, le coût du logiciel Agones en lui-même est généralement nul, ce qui paraît formidable. Cependant, vous réaliserez rapidement que les coûts et les ressources nécessaires pour le configurer et le gérer peuvent devenir substantiels.

L'installation et la gestion d'Agones exigent une bonne compréhension de Kubernetes (K8), des systèmes d'exploitation Linux et la maîtrise d'un langage de programmation comme Python ou Go. De plus, les ingénieurs doivent avoir de l'expérience avec les technologies de conteneurisation telles que Docker et containerd, et être familiers avec les réseaux, la sécurité et l'automatisation. Enfin, votre équipe doit disposer d'un savoir-faire sur les technologies cloud ou le matériel sur site. C'est sans doute pour cela que les ingénieurs DevOps de la région de San Francisco gagnaient, en moyenne, 200 000 USD par an fin 2022.

Le coût de l'infrastructure sous-jacente dépendra de l'endroit où vous choisissez d'héberger votre ou vos clusters Kubernetes. Par exemple, si vous l'hébergez sur votre propre matériel, le coût correspondra au prix des serveurs physiques, à l'électricité et aux autres ressources nécessaires à leur fonctionnement, ainsi qu'à l'assurance des locaux, aux ingénieurs et à tout ce qui s'ensuit. Si vous l'hébergez chez un fournisseur cloud, le coût sera celui des machines virtuelles et de tous les autres services utilisés, tels que le stockage et le réseau. Les factures d'infrastructure cloud peuvent rapidement grimper en raison de postes tels que les adresses IP publiques, le trafic réseau, les équilibreurs de charge, le stockage, les appels d'API et les frais d'assistance — et la vue d'ensemble est souvent plus difficile à déchiffrer qu'elle ne devrait l'être. Nous avons créé notre simulateur de prix précisément pour offrir aux studios une vision plus claire de ce que coûtent réellement l'hébergement et l'orchestration des serveurs de jeu.

En plus des coûts d'infrastructure et de logiciels, des coûts peuvent être associés aux outils ou services supplémentaires 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 continus (CI/CD). Les coûts spécifiques dépendront des outils et des services que vous choisirez.

Il est facile de supposer qu'une machine virtuelle économique suffira pour exécuter ce logiciel open source, mais le coût total de l'infrastructure est généralement bien plus élevé.

Vers les services gérés

À l'instar de la transition opérée pour 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, cela vous libère de la charge de la gestion et de la maintenance du cluster. Cela peut faire gagner un temps et une énergie précieux à votre équipe, lui permettant de se concentrer sur des tâches plus importantes.

De plus, un service entièrement géré peut donner accès à un accompagnement et à une assistance d'experts. Cela peut être particulièrement utile pour les organisations qui découvrent Kubernetes ou qui ne savent pas exactement comment exploiter au mieux cette technologie. Avec un service géré, vous pouvez obtenir de l'aide et des conseils auprès de professionnels chevronnés qui comprennent la technologie en profondeur et peuvent apporter des éclairages et des recommandations précieuses.

Un autre avantage de l'utilisation d'un service Kubernetes entièrement géré est la capacité de monter en charge rapidement et facilement. Dès lors que votre organisation grandit et que vos charges de travail deviennent plus complexes, un service géré peut offrir la flexibilité et l'évolutivité dont vous avez besoin pour suivre le rythme. C'est particulièrement crucial pour les clusters hautement distribués, qui peuvent être difficiles à gérer et à mettre à l'échelle de manière autonome. Votre objectif est de concevoir un jeu exceptionnel et couronné de succès, plutôt que de gérer la plomberie sous-jacente qui achemine votre jeu jusqu'aux joueurs.

Dans l'ensemble, l'utilisation d'un service Agones/Kubernetes entièrement géré peut apporter de nombreux avantages, notamment un gain de temps et d'efforts, l'accès à une assistance spécialisée et la capacité de monter en charge rapidement et simplement.

La vraie question est : avez-vous vraiment besoin d'Agones, pour commencer ?

Kubernetes a été conçu à l'origine pour les technologies web. Celles-ci gèrent des milliers de connexions sans état (stateless), répondant à de petites requêtes en une fraction de seconde. Les serveurs de jeu sont à l'opposé de cette philosophie. Les serveurs de jeu et les relais ont un état (stateful), gérant des connexions persistantes pendant 5 à 45 minutes.

L'industrie du jeu vidéo a l'habitude de configurer un maximum de serveurs et de les garder « en veille » (standby) pour la connexion des joueurs. AWS Gamelift a été un précurseur de cette architecture. Avec cette architecture à l'esprit, Agones est un CRD permettant d'activer de tels serveurs de secours au sein de Kubernetes. Cependant, disposer d'instances de secours est inutile et apporte peu de valeur étant donné que Kubernetes n'est pas conçu à l'origine pour gérer de telles applications avec état.

Depuis son lancement en 2018, Agones a eu du mal à trouver un positionnement clair : la complexité peut s'avérer prohibitive pour les petites équipes ne disposant pas d'importantes ressources d'ingénierie dédiées, tandis que les grandes équipes ont souvent besoin de capacités hautement distribuées pour lesquelles il n'a pas été conçu.

Prenez le meilleur de l'architecture d'Agones, laissez le reste de côté (ou à quelqu'un d'autre)

Agones prend en entrée de votre part, en tant que développeur de jeux, une image de conteneur. Pour ceux qui l'ignorent, 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, notamment une efficacité, une portabilité et une flexibilité accrues.

L'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, alors que chaque machine virtuelle fonctionne sur son propre système d'exploitation invité, ce qui peut consommer beaucoup de ressources. En partageant le système d'exploitation hôte, les conteneurs peuvent consommer 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 et à un système d'exploitation hôte spécifiques, les conteneurs peuvent être facilement déplacés d'un environnement ou d'une plateforme à l'autre. Il est ainsi aisé de déployer et d'exécuter vos applications sur d'autres infrastructures, que ce soit sur site, dans le cloud ou sur une configuration hybride.

En plus d'une efficacité et d'une portabilité accrues, les conteneurs offrent également une plus grande flexibilité. Grâce aux conteneurs, vous pouvez facilement empaqueter et déployer votre jeu et ses dépendances sous la forme d'une unité unique, ce qui simplifie la mise à jour et la maintenance de vos applications. Cela peut s'avérer 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 réside dans sa capacité à démarrer rapidement les serveurs de jeu pour répondre aux attentes des joueurs.

Comme l'ont mis en évidence des tests en conditions réelles sur PUBG, JungHun Kim, responsable de l'équipe DevOps chez KRAFTON, a présenté que le temps global de démarrage d'un serveur Agones lors d'une montée en charge peut être de 10 à 15 minutes entre le provisionnement de l'instance (1-3 minutes), l'amorçage de l'instance (2-3 minutes) et le provisionnement du pod (5-10 minutes) sans compter l'intégration de Karpenter, comme présenté à l'AWS re:Invent 2024 :

Cela signifie que les joueurs en attente du déploiement d'un serveur de jeu doivent patienter dans une file d'attente pendant que la ressource actuelle est recyclée. Plus concrètement, cela implique qu'un serveur de jeu ne peut pas être déployé et que les joueurs qui attendent dans la file sont frustrés et finissent par abandonner totalement votre jeu multijoueur — selon le rapport d'Edgegap sur la latence en ligne, 34 % d'entre eux quitteront votre jeu dans ces conditions.

Pendant ce temps, grâce à son approche de colocation hautement optimisée, la plateforme d'Edgegap enregistre un temps médian de déploiement de serveur de 2 secondes à partir d'un démarrage à froid (provisionné de zéro et mesuré jusqu'à ce que le conteneur soit prêt ; données de la plateforme, en date de septembre 2026).

Vélocité vs faire soi-même

Un nombre croissant de fournisseurs proposent des environnements SaaS permettant aux développeurs de jeux d'héberger et de gérer le cycle de vie de leurs jeux sans les contraintes liées à l'exploitation directe d'Agones et de Kubernetes. L'industrie du jeu vidéo a une longue tradition de développement d'infrastructures sur mesure, et Agones reflète cet instinct — même si la tendance des services gérés est en train de faire évoluer ce calcul. La principale motivation pour gérer Agones en interne est souvent une préférence pour le contrôle et la personnalisation, mais cela entraîne une charge non négligeable que les studios devraient soigneusement évaluer face à leur vélocité de développement. Les arbitrages — en matière de coûts, de temps et d'expérience des joueurs — incombent finalement au studio et à ses joueurs.