« Pourquoi nous quittons le cloud » : les raisons d'un retour en arrière

Se passer du cloud ? En octobre dernier, David Heinemeier Hansson faisait une annonce à ce sujet. Pas sous sa casquette de créateur de Ruby on Rails, mais en tant que CTO de 37signals.

Basecamp et HEY sont les deux principaux produits de cette entreprise américaine. Le premier « a un pied dans le cloud depuis plus d'une décennie », faisait remarquer l'intéressé. Le second y réside quasi intégralement depuis son lancement en 2020.

« Nous sommes passés par Amazon et Google », expliquait D. H. Hansson. Nous avons vu ce que le cloud a à offrir. [...] Louer des ordinateurs n'est (globalement) pas une bonne affaire pour des PME comme la nôtre. Les économies promises [...] ne se sont jamais matérialisées ».

Le cloud « excelle à deux extrémités du spectre », résumait le directeur technique. La première, c'est quand votre application est suffisamment simple et qu'elle génère assez peu de trafic : débuter avec des services managés réduit alors vraiment la complexité. La deuxième, c'est quand la charge est imprévisible.

« Aucune des deux ne s'applique aujourd'hui à nous », affirmait D. H. Hansson. Et de donner, pour exemple, le coût de HEY : « près d'un demi-million de dollars par an payés à Amazon pour des services de base de données (RDS) et de recherche (Elastic) ».

Quant à l'argument de la simplicité, il rétorquait : « À notre échelle, j'attends encore de voir des organisations qui ont significativement réduit leur équipe d'exploitation. [...] Notre modèle économique est compatible avec l'achat de hardware et son amortissement sur plusieurs années. » Et de poser, en filigrane, la question de la centralisation d'internet chez les « grands » du cloud.

Tout n'avait pas basculé dans le cloud

Début janvier, un membre de l'équipe SRE de 37signals publiait un billet titré « Nos dépenses cloud en 2022 ». Avec, en premier lieu, un rappel : Basecamp et HEY sont les deux seuls produits encore commercialisés. Les autres (Basecamp Classic, Basecamp 2, Highrise, Backpack, Campfire, Writeboard et Ta-da List) sont en mode maintenance.

À ce moment-là, Basecamp tourne essentiellement sur site, à base de matériel Dell hébergé chez Deft. Trois briques sont dans le cloud : la recherche (OpenSearch), le stockage fichier (S3) et le CDN (CloudFront). C'est l'inverse pour HEY, qui réside sur AWS (EKS, Aurora RDS, Elasticache...) exception faite de certains services de traitement d'e-mails et d'images. Les autres applications, « legacy », sont aussi sur EKS et exploitent RDS comme base de données.

En 2022, la facture cloud pour l'ensemble de ces applications s'est élevée à 3,2 M$. Dont un peu plus d'un million pour la prod de HEY. Les dépenses sur S3 ont dépassé 900 000 $ (stockage de 8 Po, réplication sur deux régions). Celles sur OpenSearch et RDS ont avoisiné 500 000 $. Un budget déjà optimisé, non seulement par du travail en interne, mais aussi par des engagements d'usage auprès d'AWS.

Kubernetes or not Kubernetes ?

Cette semaine, un autre SRE a pris la parole, pour faire un point d'étape sur le retour des applications au bercail.

À l'origine, la migration cloud s'était faite vers ECS. Face au manque de flexibilité, 37signals était passé à GKE. Des pannes sur le plan de contrôle l'avaient poussé à revenir chez AWS, sur le socle EKS. Sur chacune de ces plates-formes, il a fallu adapter la stratégie de déploiement, repenser le monitoring et la sécurité, etc.

Même constat que David Heinemeier Hansson : « La promesse de simplification ne s'est jamais concrétisée. » 37signals en veut pour preuve l'architecture de Ta-da List, son application « la plus simple », lorsqu'elle était sur EKS.

Elle ne s'y trouve effectivement plus. C'est avec elle qu'a commencé le retour sur site. Un point de départ logique, s'agissant de la moins critique des applications de 37signals (gratuite, sans SLO).

La première impulsion fut donnée dans le sens d'un basculement vers du Kubernetes on-prem. Avec, parmi les défis, celui de continuer à satisfaire les exigences legacy prises en compte plusieurs années auparavant lors de la conteneurisation initiale.

msrk en soutien

Face à la complexité de la démarche, 37signals s'est rabattu sur msrk, un outil open source qui utilise SSHKit et Traefik pour déployer des applications via Docker. Ayant éliminé la couche Kubernetes, l'éditeur a, en parallèle, modernisé son système de gestion de configuration, avec la dernière version de Chef. Il a aussi revu son processus de provisionnement de VM, réduisant le délai d'initialisation « d'environ 20 minutes par invité à moins d'une minute ».

Pour la journalisation, 37signals a choisi une stack ELK. Côté DNS, il est passé à Cloudflare, placé devant ses répartiteurs de charge F5 Networks. Et pour le CI/CD, GitHub Actions a remplacé Buildkite. Tandis que les bases de données supportant les déploiements msrk ont été mises à jour vers Percona MySQL 8, avec un système de backup interne fondé sur cron.

Il a fallu environ six semaines pour construire ces fondations et y déployer Ta-da List. A suivi, en deux semaines environ, la migration de Writeboard. Puis celle de Backpack, pour laquelle il a fallu tenir compte d'un pipeline à état implémenté avec postfix pour le traitement des e-mails.

L'initiative, dans son ensemble, a aussi permis de simplifier le code des applications, assure 37signals. Et de constater que les applications n'avaient pas vraiment besoin du cloud, ni de Kubernetes...

Photo d'illustration © Ar_TH - Adobe Stock