Migrer d’AWS vers le bare metal et économiser 230 000 $ par an

• OneUptime, une plateforme open source d’observability, a migré son infrastructure d’AWS vers une solution bare metal, obtenant un meilleur contrôle sur ses ressources et des économies financières substantielles.
• La plupart de ses clients utilisent le cloud public, et un data center indépendant est nécessaire pour fournir un service d’alerting lors des pannes du cloud.

Configuration initiale : Kubernetes sur AWS

• Adoption d’un cluster Kubernetes via Elastic Kubernetes Service (EKS), le service managé d’AWS.
• OneUptime est construit sur des logiciels open source non spécifiques à AWS, comme Redis, Postgres, Clickhouse, Docker, NodeJS et BullMQ.
• Cela évite une dépendance à AWS et permet aux clients d’auto-héberger OneUptime sur leur propre cluster.

Transition : migration vers le bare metal

• Décision de passer à une solution bare metal dans le cadre d’une recherche d’excellence technique.
• Choix d’exploiter un cluster Microk8s dans une installation de colocation, sur la base de l’expérience passée et d’objectifs tournés vers l’avenir.
• Microk8s peut aussi être utilisé en production, et le passage à des serveurs bare metal permet de disposer de ressources dédiées et d’optimiser les performances.

Le rôle de Kubernetes et Helm

• Kubernetes et Helm ont joué un rôle clé dans la transition du cloud vers des serveurs en propre.
• Kubernetes est une plateforme open source destinée à automatiser le déploiement, la mise à l’échelle et l’exploitation des conteneurs applicatifs.
• Helm est un gestionnaire de paquets qui simplifie la définition, l’installation et la mise à niveau des applications Kubernetes.

Stockage et load balancer

• Dans le cluster Kubernetes bare metal, les volumes utilisent Network File System (NFS) et le load balancer repose sur MetalLB.
• NFS est un protocole de système de fichiers distribué qui permet à des ordinateurs clients d’accéder à des fichiers via le réseau.
• MetalLB est une implémentation de load balancer pour les clusters Kubernetes bare metal utilisant des protocoles de routage standard.

Impact financier : plus de 230 000 $ économisés par an

• L’utilisation d’AWS coûtait plus de 38 000 $ par mois, soit plus de 456 000 $ par an.
• Après la migration vers le bare metal, l’entreprise utilise une configuration sur un seul rack chez son partenaire de colocation, ramenant les coûts d’exploitation à environ 5 500 $ par mois.
• En amortissant le coût des serveurs sur cinq ans, cela représente plus de 230 000 $ d’économies annuelles, ce qui permet de renforcer les équipes et d’allouer des ressources à d’autres domaines de l’activité.

Points à considérer

• Les données sont sauvegardées plusieurs fois par jour dans deux bureaux, et peuvent aussi être sauvegardées dans le cloud public.
• Il est possible d’exploiter un cluster Kubernetes multi-sites dans deux installations de colocation situées sur différents continents.
• Un cluster de secours est prêt sur AWS et peut être lancé en moins de 10 minutes en cas de sinistre.
• Passer au bare metal ne nécessite pas forcément d’embaucher un administrateur système, la maintenance matérielle étant en grande partie assurée par l’installation de colocation.
• Microk8s est utilisé non seulement pour le développement mais aussi en production, et il est facile de migrer vers une autre distribution Kubernetes si nécessaire.

Conclusion

• Les services cloud comme AWS offrent flexibilité et puissance, mais ne constituent pas forcément le choix le plus économique pour toutes les entreprises.
• En s’appuyant sur des technologies open source et en investissant dans leur propre matériel, les entreprises peuvent mieux contrôler leurs ressources et réduire fortement leurs coûts d’exploitation.
• Chaque activité ayant des besoins spécifiques, une évaluation complète est nécessaire avant toute transition.

L’avis de GN⁺

Le point le plus important de cet article est l’avantage en matière de contrôle et de réduction des coûts qu’une entreprise peut obtenir en passant des services cloud à une infrastructure bare metal. Cet article est intéressant parce qu’il montre, à travers un cas concret, comment des décisions techniques peuvent avoir un impact sur les résultats financiers. Grâce aux progrès de technologies comme Docker, Kubernetes, Helm et Microk8s, ce type de transition est devenu bien plus facile qu’il ne l’était il y a quelques années, ce qui souligne l’importance des choix technologiques et la valeur d’une approche stratégique.

[hhcrux]

230�000 dollars... est-ce que ce nest pas une somme qui dispara�00t rien quen embauchant deux admins pour g�00rer des serveurs en colocation ? Si on utilise des services enti�rement manag�s, cest justement pour �viter ce genre de co�t.

[gunrok]

C’est vrai aussi, mais le piège avec AWS, c’est qu’il faut également des ingénieurs AWS experts, spécialisés par domaine.

[wedding]

Les avis sont globalement assez négatifs. À voir le résumé, cela donne aussi une impression d'exagération.

[GN⁺]

Avis Hacker News

• L’utilisation d’instances réservées et de Savings Plans peut réduire fortement les coûts AWS. Cela s’applique aussi aux coûts de transfert et de stockage, ce qui permet réellement d’économiser beaucoup, mais l’écart n’est pas aussi spectaculaire qu’on pourrait le penser au départ.
• Vu la situation économique actuelle, beaucoup disent que cela permettrait « d’embaucher un ingénieur de plus », mais il faut se rappeler que cela peut surtout permettre « d’en garder un de plus ». La vraie question est de savoir s’il faut licencier des membres de l’équipe pour continuer à rester sur AWS.
• Gérer des racks de serveurs n’a rien d’extraordinaire, contrairement à ce que beaucoup imaginent. Les ingénieurs cloud-native hésitent à apprendre la gestion du matériel.
• Lorsqu’on n’utilise pas les services cloud mais simplement des machines virtuelles, cela n’a que rarement de la valeur. Pour beaucoup, louer des serveurs dédiés peut être la meilleure décision business. Cela peut coûter bien moins cher qu’EC2 et, avec une grande capacité inutilisée, résoudre les problèmes de scalabilité habituels.
• Il faut se concentrer sur les objectifs business et ne pas se laisser emporter par le hype. Dans certains cas, le downtime est un vrai problème, mais pour beaucoup d’entreprises, quelques minutes d’interruption coûtent bien moins cher que l’ingénierie de mécanismes complexes de haute disponibilité (HA).
• Au lieu d’acheter une Ferrari chez AWS, acheter une Toyota Camry permet d’économiser beaucoup. Ce genre d’histoire ressemble souvent à du spam de blog où une entreprise prétend avoir réussi un hack incroyable. En réalité, elle brûlait simplement son cash faute de savoir contrôler ses dépenses.
• Je cherchais encore un prestataire de colocation hier, donc l’affirmation d’avoir économisé 230 000 dollars si rapidement laisse sceptique.
• En termes de rapport coût/efficacité, si vous n’avez pas consacré une année-personne à gérer vos propres serveurs, alors vous avez probablement fait le bon choix.
• Le billet est trop vague sur les détails pour qu’on puisse juger de sa valeur réelle.
• Une entreprise est faite pour gagner de l’argent, et c’est le produit qui en rapporte, pas la capacité à gérer du matériel et une infrastructure IT.
• Dépenser 500 000 dollars par an sur AWS peut réellement justifier une sortie du cloud si l’infrastructure est relativement simple et qu’on ne s’attend pas à une forte hausse des dépenses.
• Dépenser 500 000 dollars par an sur AWS suffit à montrer, rien qu’en mettant les montants dans un tableur et en les examinant pendant une heure, qu’il existe des économies évidentes à faire — ce travail devrait être fait bien avant d’atteindre plusieurs centaines de milliers de dollars de dépenses annuelles sur AWS.