Il y a un peu plus de deux ans maintenant, nous avons décidé de renforcer les équipes de Clever Cloud. Notre objectif était alors de mieux accompagner nos clients dans leur croissance, répondre à leurs demandes et finaliser le développement de nouveaux produits de manière plus efficace.
Depuis, nous sommes passés d’une quinzaine de personnes à près d’une soixantaine, avec une approche “remote first” mais tout de même plusieurs bureaux en France : Brest, Nantes, Lille, Lyon, Paris, d’autres étant en cours d’étude. Il s’agit principalement de développeurs et d’ingénieurs, organisés en différents pôles pour traiter de l’ensemble de nos métiers, le “cloud“ couvrant un spectre assez large. Un défi organisationnel, géré par notre CTO Steven Le Roux.
Nous avons également opéré un changement d’ampleur du côté de notre infrastructure : nous ne sommes plus locataires de nos serveurs, nous en sommes propriétaires. Nous avons des contrats directs avec les datacenters (DC) où nous sommes présents sur Paris et nos différents prestataires, avec un contrôle accru sur notre réseau.
Nous avons aussi profité de cette période pour initier un large programme de certification et de qualification de nos pratiques et processus. Depuis l’année dernière nous sommes ainsi certifiés ISO 9001 et nous venons de passer l’audit pour l’ISO 27001 qui devrait nous être confirmée dans les prochaines semaines. Les étapes suivantes sont déjà définies : l’hébergement de données de santé (HDS) puis la qualification SecNumCloud, déjà commencée.
Opérer tous ces changements aura été long et parfois difficile. Nous avons appris tout au long de ce parcours et parfois fait des erreurs. Certains de nos clients ont pu particulièrement le noter depuis la rentrée lorsque nous avons effectué une migration d’ampleur sur l’ensemble de notre infrastructure. Si nous reviendrons plus en détails sur certains sujets lors de prochains billets, voici un premier bilan d’étape de tout ce qui a été entrepris et ce qui s’est (plus ou moins bien) passé.
Trois nouveaux datacenters
L’année dernière nous annoncions la première étape de notre plan : la mise en place de nouveaux serveurs, basés sur le format ouvert OCP et des processeurs AMD EPYC chez Green Data à Nanterre. Outre la mise en place des processus et les aspects contractuels, nous avions ici pour objectif de repenser la manière de déployer et de gérer nos serveurs et une partie de notre réseau. Un sujet sur lequel nous avons travaillé en collaboration avec NVIDIA/Mellanox.
En effet, nos switchs “Top of Rack” (ToR) ne sont pas équipés d’un système d’exploitation sur étagère, avec sa myriade de fonctionnalités et de licences. Nous y installons notre propre OS, basé sur Exherbo Linux et le standard ONIE, où nous déployons notre propre couche logicielle. Le tout est accéléré grâce à switchdev.
Mis en production à la rentrée 2022, ce site nous a permis d’assurer notre croissance. Mais aussi de rencontrer quelques soucis et d’apprendre à les gérer puis à les corriger. De temps à autres, certains de nos hyperviseurs finissaient en “kernel panic” sans raison, ce qui a été corrigé par l’introduction de la version 6.0 du noyau Linux. Nous avions aussi des instabilités réseau, non sur nos ToR mais sur un équipement reliant nos datacenters entre eux, ce qui a retardé la montée en charge sur ce site. Cela n’a pu être le cas que peu avant cet été, le temps que tout soit compris et corrigé.
Confiants sur notre capacité à traiter ces sujets, nous avions décidé en décembre 2022 de dupliquer cette expérience sur deux nouveaux DC, afin qu’ils remplacent à terme les deux où nous étions historiquement présents. Le contrat qui nous liait à notre prestataire prenait fin un peu moins d’un an plus tard et nous faisions face à des désaccords importants sur les termes de son renouvellement. Depuis, nous nous sommes mis en ordre de bataille pour qualifier et commander le matériel, les sites où il sera installé puis passer à la mise en œuvre.
Un travail de plusieurs mois qui a mené cet été à la mise en place de ces deux nouveaux datacenters puis à leur interconnexion et leur configuration, avec là encore une nouveauté qui a son importance : nous y annonçons nos propres IP, travaillant à la fois avec notre partenaire historique sur le réseau mais également des transitaires en contrat direct.
Nous en avons d’ailleurs profité pour revoir toute notre couche DNS afin qu’elle soit plus résiliente, plus rapide en résolution et en update. Chacune de nos régions a maintenant ses propres serveurs DNS répliqués depuis Paris. En cas d’indisponibilité (par exemple suite à une attaque DDoS), les autres régions ne sont plus impactées pour les accès aux enregistrements existants. Chaque région dispose également d’une copie de toute la configuration DNS localement, afin de pouvoir répondre directement. Nous avons aussi revu le modèle de création et de mise à jour d’un enregistrement qui se fait maintenant en moins d’une seconde.
Le temps de la migration
C’est alors qu’est venu le temps de la migration. L’opération peut paraître simple, mais il s’agissait d’un travail titanesque : déplacer l’ensemble de nos clients de nos deux sites historiques parisiens vers nos trois nouveaux sites. Cela avait déjà été fait en partie sur celui de Nanterre depuis sa mise en production, mais pas à une telle échelle.
Il nous a donc fallu renforcer notre outillage afin de disposer du niveau d’automatisation et d’information des clients nécessaire. Mais nous avons surtout dû faire l’inventaire de tout ce qui avait été fait manuellement pour certains clients au fil des années. De quoi occuper certaines de nos équipes, notamment celle en charge des bases de données, pendant plusieurs semaines.
Cela a mené à une phase de préparation qui explique les emails et notifications que vous avez pu recevoir à partir de cet été. Chacun des clients concernés pouvait ainsi déplacer ses services quand il le voulait, avant une date butoir à partir de laquelle nos équipes prenaient cette opération en charge.
Nous nous sommes ainsi rapprochés d’un grand nombre de nos utilisateurs pour les accompagner dans cette période afin de ne (presque) pas interrompre leurs services. Un travail orchestré par notre chef des opérations, Cédric Biron.
Si cela s’est globalement bien passé, nous avons pu constater depuis que dans certains cas, cela n’avait pas été suffisant puisque ces alertes envoyées plusieurs fois par e-mail n’ont pas toujours été vues. Nous allons mener une réflexion dans les semaines à venir pour mieux en comprendre les raisons et revoir et améliorer nos processus.
Load balancers : de grandes évolutions pour Sōzu (et quelques accrocs)
Mais depuis le mois d’octobre, nous avons noté un nombre croissant et inhabituel d’instabilités sur la plateforme, concernant une brique critique et habituellement stable : notre load balancer, Sōzu. Ces dernières semaines, nos équipes ont donc investigué afin de comprendre non pas le, mais les problèmes rencontrés par certains clients, qui se sont produits de manière conjointe à la migration sans pour autant y être liés. Désormais, ils sont tous réglés.
Il faut tout d’abord noter que nous avons profité de cette période pour faire faire un bond majeur à Sōzu qui est passé de sa branche 0.13.x à 0.15.x, avec de nombreuses améliorations à la clé, dont sa capacité à nous remonter des métriques, préparer de futures nouveautés comme le support de HTTP/2, etc.
Notre objectif était au départ de nous préparer à certains problèmes que nous nous attendions à rencontrer avec une charge plus importante du trafic ou une croissance des flux chiffrés, mais également de renforcer la sécurité de cet outil. Néanmoins, certains effets de bord ont mal été anticipés.
Sur ce dernier point notamment, nous avions initialement décidé de passer de clés RSA sur 2048 bits à 4096 bits pour disposer d’un chiffrement plus fort sans impact sur la compatibilité pour nos clients. Mais une fois cette amélioration mise en place, les ressources consommées et le délai de traitement des requêtes ont explosé. Le temps de trouver l’origine du souci et de revenir à la configuration initiale, le mal était fait.
Depuis, nous avons retravaillé ce point et planifions de passer à des clés ECDSA. Leur support est d’ores et déjà actif dans Sōzu mais ne sera déployé au sein de nos services qu’après une étude de l’impact et une communication auprès de nos clients qui pourront s’assurer que cela ne leur posera pas de souci, avec des moyens de contournement si jamais cela était le cas. Nous avons d’ailleurs rencontré un problème similaire avec la gestion de ciphers plus modernes mais qui posaient des soucis de compatibilité à certains clients. Nous leur avons depuis proposé des load balancers dédiés, gérant les anciens ciphers, leur permettant d’adapter progressivement leurs applications.
D’autres changements ont pu impacter des clients lorsqu’il y avait par exemple des caractères non conformes au standard dans certains headers. Lors de cette montée en version, nous avons rencontré un “double bug“ qui nous a pris du temps à comprendre et à corriger et nous avons parfois rencontré des problèmes dans nos processus de mise en production qui ont pu impacter nos clients de manière excessive par rapport à nos standards de qualité habituels.
Là aussi, nous avons depuis renforcé nos processus, tant sur la préparation de la mise en production de nouvelles versions que l’information des clients sur les nouveautés qui peuvent potentiellement les impacter. Le monitoring complet mis en place durant cette période nous a confirmé ces dernières semaines que l’ensemble des sujets étaient réglés et que même s’il reste quelques améliorations à faire ici ou là, plus aucun incident ne nous a été signalé.
Nous allons ainsi pouvoir nous concentrer sur la suite, avec notamment la mise en API de nombreuses fonctionnalités liées à la gestion des domaines et de l’accès à vos applications. Nous vous en reparlerons très bientôt.
Une nouvelle stack de logs
Les plus attentifs auront remarqué que d’autres éléments ont évolué de manière plus ou moins visible ces derniers mois, là aussi grâce au travail de nos équipes pour moderniser des pans entiers de notre infrastructure. Ainsi, un nouveau cluster Pulsar a été mis en production, permettant notamment de revoir complètement notre expérience des logs.
Cela fait quelques temps maintenant que cette fonctionnalité a été introduite dans notre CLI, les Clever Tools, avec un affichage désormais systématiquement ordonné des logs, la gestion des couleurs et émojis, ou la possibilité de filtrer par date/heure. Des améliorations fonctionnelles sont encore en cours sur ce sujet et une nouvelle interface est en préparation au sein de la console pour vous permettre de mieux consulter les logs de vos applications.
Il en sera de même pour les logs d’accès dans un second temps, une adaptation du fonctionnement de Sōzu étant en cours pour les traiter avec un bon niveau de performance (via Protobuf).
La mise en place de ce nouveau cluster nous permettra par ailleurs de sortir Pulsar de son statut “Beta”. Nous détaillerons le plan pour sa disponibilité générale en version finale dans les prochaines semaines.
Une nouvelle fondation pour notre data
Autre sujet de fond, peu visible mais pas sans conséquences : la mise en production de notre premier cluster serverless basé sur FoundationDB. Il a pris la suite de HBase que nous avons remercié lors d’une cérémonie d’adieu organisée dans nos bureaux de Brest un soir pluvieux du mois d’octobre.
Jusqu’alors, nos métriques et données de facturation reposaient sur cette technologie de stockage qui nécessitait une centaine de machines. Mais cela nous posait des problèmes opérationnels et montrait ses limites en termes d’évolutions possibles. Lors de discussions avec les équipes de SenX, à l’origine du projet open source Warp 10, nous avons constaté qu’ils rencontraient des problématiques similaires. Nous avons alors travaillé ensemble, ce qui a mené à la version 3.0 de Warp 10 nous permettant de construire un backend de stockage fonctionnant de pair avec notre nouveau cluster, avec succès.
FoundationDB sera au cœur de certains de nos nouveaux produits. Elle est d’ores et déjà utilisée pour les démonstrateurs de nos futures offres de store Key/Value (compatible Redis) ainsi que le stockage de secrets (compatible Vault)… entre autres. Des solutions en cours de test en interne et avec certains clients.
Nous ouvrirons peu à peu les vannes à ceux voulant tester ces solutions courant 2024, avec des démonstrations prévues sur les différents salons où nous serons présents.
De meilleurs Clever Tools
Bien entendu, une offre de cloud n’est rien sans ses interfaces. Outre le travail d’amélioration continue faite par notre équipe en charge de la Console, qui vient par exemple de passer à la v12 de nos Web Components, nous avons remis en place une équipe chargée de l’évolution et de la documentation de notre CLI, les Clever Tools.
Un nouveau processus de déploiement vient d’être finalisé et sera utilisé pour leur prochaine version, de nombreuses nouveautés étant prévues dès le début de l’année 2024. Cette structuration nous permettra de proposer des évolutions plus régulières, cohérentes avec les remontées des clients et de mieux gérer les participations externes (issues, PR, etc).
Des retouches un peu partout
Nous avons d’ailleurs revu complètement notre site internet après l’été, avec une nouvelle interface pour notre documentation, qui va progressivement être complètement retravaillée, guides et tutoriels à la clé.
Notre équipe en charge des images a elle aussi revu de manière profonde le processus de leur conception afin d’en simplifier la mise à jour, mais surtout disposer d’une base commune à l’ensemble de nos runtimes, nous permettant de les rendre plus flexibles et d’en proposer de nouveaux dans les mois à venir. Là aussi, nous avons revu la question de l’organisation de nos équipes et la gestion du cycle de vie afin que chaque runtime soit désormais traité par des personnes identifiées, qui feront le lien entre la manière dont nous déployons les applications et les communautés respectives.
Une part croissante de nos API migre en /v4, pour nos usages internes, mais aussi pour répondre aux besoins de nos clients qui intègrent Clever Cloud à leurs produits et interfaces. La documentation des nouveaux endpoints est en cours. Cette année, nous avons d’ailleurs commencé à supporter Terraform, avec une volonté d’aller plus loin dans le domaine de l’Infrastructure-as-Code et la gestion de tels outils dans le courant de l’année qui vient.
Ces derniers mois, nous avons également livré un support préliminaire de Tailscale, une offre Clever Edge 4G/5G à certains clients, commencé à en embarquer d’autres sur notre offre FaaS reposant sur WASM, etc.
What’s Next ?
Nos plans pour la suite restent ainsi inchangés, et maintenant que cette phase de migration et de consolidation est derrière nous, ils vont pouvoir s’accélérer : continuer à itérer pour améliorer notre plateforme, avancer sur la livraison des produits actuellement en test, livrer une version préliminaire de nos Networks Groups, préparer le terrain pour l’arrivée d’une offre IaaS et Kubernetes “by Clever Cloud” et continuer à nous occuper au mieux de nos clients, nos premiers partenaires.
D’ailleurs, nous enregistrons l’épisode 100 de notre podcast Message à caractère informatique (MACI) le 16 janvier au Palace à Nantes, en public. Vous êtes cordialement invités à venir échanger avec nos équipes pour parler du futur de notre plateforme et comment elle peut répondre mieux à vos besoins. Tout comme nous serons présents sur de nombreux salons dès les premières semaines de l’année 2024.