GitHub, EKS, OpenTelemetry… Les regrets d’un directeur infrastructure

Bottlerocket ou les AMI EKS standards ? Le directeur infrastructure de Cresta avait d’abord choisi la première option. Après des problèmes avec le pilote réseau, il a finalement basculé vers la seconde, jugée plus simple à déboguer.

Voilà quatre ans que l’intéressé* gère, dans cette entreprise qui fournit des solutions de centre de contact, un back-end fondé essentiellement sur AWS et Kubernetes. Il a récemment fait le bilan de ses décisions. Parmi celles considérées comme positives :

– Être passé de Jira à Linear (satisfaisant sur le plan fonctionnel)
– Avoir adopté Atlantis plutôt que Terraform Cloud (surtout pour une question de coût)
– Être resté sur Ubuntu pour les serveurs de dev
– Avoir préféré Renovatebot à Dependabot
– Avoir acheté ses propres adresses IP (notamment pour faciliter les accès partenaires)

Entre AWS et K8s, dix points de regret

Avoir contracté le support premium AWS
La raison invoquée est simple : le coût. « Presque aussi cher, si ce n’est plus, qu’un ingénieur. Cela aurait valu le coup si nous avions eu peu de compétences en interne. »

Avoir utilisé les add-on EKS gérés
Le problème, ici, a tenu au besoin systématique de personnaliser les installations (requêtes CPU, ConfigMaps, tags d’images…). Helm a fini par prendre le relais.

La gestion de post-mortem dans Datadog ou PagerDuty
Une fois encore pour des questions de personnalisation. Constat : un outil « type wiki », comme Notion, est plus adapté.

Ne pas avoir utilisé davantage le FaaS (fonctions en tant que service)
Le manque d’options pour les workloads GPU a limité l’adoption du FaaS chez Cresta. Une option appréciée en particulier pour la capacité à suivre plus précisément les coûts que sur des déploiements Kubernetes.

Partager une base de données entre applications
Cet état de fait n’a pas résulté d’une décision : il s’est présenté au gré de l’évolution des projets de développement. Sans DBA, il s’est révélé difficile à gérer : « Comme tout le monde utilise la base de données, plus personne n’en prend soin. […] Ce qui n’est de la responsabilité de personne finit par échoir à l’équipe infra »…

Datadog, GitHub Actions : oui, mais…

GitHub Actions
Chez Cresta, GitHub Actions a remplacé CircleCI. À la clé, un catalogue exhaustif et une syntaxe simple à assimiler. Mais une prise en charge « très limitée » des workloads Kubernetes autohébergés.

Datadog, pour le prix
Constat : c’est bien, mais c’est cher, surtout pour les clusters Kubernetes et les services d’IA. Problème sur le premier point : la tarification fondée sur le nombre d’instances lancées et non le nombre d’instances actives. Sur le deuxième point : un rapport « coût par service » peu intéressant pour les workloads GPU, qui ont généralement chacun leur nœud.

Ne pas avoir adopté plus tôt une plate-forme de gestion des identités
Au départ, il y avait Google Workspace, à partir duquel on créait des groupes d’employés afin de leur assigner des permissions. Pas assez flexible pour Cresta, qui a fini par adopter Okta. Une solution « qui résout beaucoup d’aspects conformité/sécurité » et qui « dispose d’intégrations pour presque tout ».

Avoir utilisé SealedSecrets pour gérer les secrets Kubernetes
Principal écueil de SealedSecrets : la courbe d’apprentissage pour les développeurs. Cresta a par ailleurs perdu les automatisations qu’il avait mises en place sur AWS pour la rotation de secrets. ExternalSecrets s’est avéré plus approprié pour la synchronisation entre environnements, comme pour la prise en main.

Ne pas avoir adopté plus tôt OpenTelemetry
L’équipe infra apprécie particulièrement la gestion des traces. Elle est moins enthousiaste sur les métriques, mais la solution reste plus commode que l’ingestion directe par l’API Datadog.

* Ancien de Facebook, où il a contribué à développer le CDN et les pages d’entreprises. Passé également par Twitch, où il a travaillé sur le système de recommandation de contenus.

Illustration © VICHIZH – Adobe Stock