« Pourquoi nous avons quitté le cloud » : le bilan après un an
Publié par Clément Bohic le | Mis à jour le
En octobre 2022, 37signals, l'éditeur de Basecamp, amorçait une démarche de retour sur site pour ses applications. Elle est bouclée depuis cet été. Quel en est le bilan ?
Dix millions $ économisés en quittant le cloud ? Telle est la dernière estimation de 37signals.
Voilà près d'un an que l'éditeur américain a officialisé une démarche de rapatriement sur site pour ses applications. En tête de liste, Basecamp (gestion de projet) et HEY (client de messagerie).
Mi-avril, nous avions fait le point sur ce « retour au bercail ». 37signals était alors près de le boucler pour la version « Classic » de Basecamp, dont il assure encore la maintenance.
Sur son blog principal, le dernier post à ce sujet remonte à la mi-août. Il donne un aperçu du socle technique de destination de Basecamp. Dans les grandes lignes :
- Deux datacenters Deft, à Ashburn (Virginie) et à Chicago
- Dans chacun, quatre armoires 48U
- Un mix d'anciens et de nouveaux serveurs Dell (environ 90 par site)
- Anycast pour la version « moderne » de Basecamp ; implémentation prévue pour HEY
Le compute en 2023 ; le stockage en 2024
Au-delà des économies d'argent, 37signals avait fait remarquer avoir gagné en performances. Et de renvoyer vers un autre post, publié début mai sur le blog de HEY. Basecamp Classic - service legacy mais encore générateur de millions de dollars par an - était alors complètement sorti du cloud.
Constat : la latence médiane est passée de 67 à 19 ms. Et la latence moyenne, de 138 à 95 ms. Globalement, 95 % des requêtes sont servies en moins de 300 ms. Le tout sur une configuration à ni plus ni moins de vCPU qu'auparavant.
Auparavant, justement, il y avait, pour l'application, un environnement AWS EKS reposant sur des VM c5.xlarge et c5.2xlarge. Et, pour les bases de données, des instances db.r4.xlarge et db.r4.2xlarge. Désormais, on est sur des serveurs qui « coûtent moins de 20 000 $ l'unité ».
Les serveurs en question étaient arrivés quelques semaines en amont. Des modèles Dell R7625, au nombre de 20, chacun pourvu de deux processeurs AMD EPYC 9454 (48 coeurs à 2,75 GHz, 96 threads). Capacité globale : 7,68 To de RAM, 384 To de disque NVMe et près de 4000 vCPU. Il était alors question de décommissionner « une bonne partie » du matériel ancien.
À ce moment-là, l'éditeur pensait pouvoir économiser 7 M$ sur cinq ans, sans modifier son équipe ops. Sa base de calcul : 3,2 M$ de dépenses cloud en 2022. Objectif : en éliminer pour 2,3 M$ en 2023. Puis, en 2024, le reste, lié à du stockage S3 (8 Po avec réplication sur deux régions).
37signals envisageait alors d'acheter pour 600 000 $ de serveurs. Soit, amorti sur cinq ans (sachant que certains d'ancienne génération ont fonctionné plus longtemps), 120 000 $/an. À cela, il faut ajouter le réseau et l'alimentation électrique. Une facture estimée à 60 000 $/mois... en comptant la surprovision de capacité pour intégrer des machines supplémentaires.
Sur ces bases, on en arrive à 840 000 $/an. Soit près d'un million et demi de dollars économisés. En mettant un demi-million de côté pour couvrir d'éventuelles dépenses imprévues, restent les 7 M$ sus-évoqués.
37signals avait envisagé Rancher et Harvester
Les toutes dernières prévisions sont plus optimistes. On parle désormais d'un potentiel d'économies de 10 M$. Un chiffre qui résulte de l'extrapolation du niveau de baisse déjà constaté pour les dépenses cloud. Hors S3, elles sont passées de 180 000 à 80 000 $/mois, affirme 37signals. Et un autre recul est à prévoir pour septembre, en lien avec la fin progressive d'engagements sur des instances réservées. « À ce rythme, nous aurons compensé notre investissement en moins de 6 mois », ajoute l'entreprise... qui reconnaît toutefois avec eu recours à des services onéreux tels qu'OpenSearch et Aurora/RDS.
37signals avait initialement décidé de conserver un socle Kubernetes. Son choix s'était porté sur le couple Rancher-Harvester. Mais la proposition que lui a faite SUSE (2 M$ pour licence et support) l'en a dissuadé. Il a finalement éliminé la couche K8s en s'appuyant sur msrk, outil open source qui utilise SSHKit et Traefik pour déployer des applications via Docker.
Tout est aujourd'hui revenu sur site. Y compris, donc, le « gros morceau » HEY qui était né dans le cloud. La stack sous-jacente (KVM.Docker/mrsk) est totalement open source.
Illustration © Ar_TH - Adobe Stock