- Témoignage d’un développeur ayant migré d’AWS vers ses propres serveurs, avec une division par 10 de ses coûts d’infrastructure mensuels, passant de 1 400 $ à 120 $, tout en obtenant des performances serveur supérieures
- Les serveurs bare metal proposés par des acteurs comme Hetzner coûtent autour de 190 $ par mois pour 80 cœurs, soit 7 à 18 fois moins cher que des instances AWS comparables
- Si les ingénieurs cloud s’opposent à l’exploitation de ses propres serveurs, c’est à cause de leur sécurité d’emploi et de leur dépendance à des infrastructures complexes, alors que le coût réel est supporté par l’employeur
- La plupart des petites entreprises n’ont pas besoin de fonctions de niveau entreprise comme la haute disponibilité, la réplication multi-zone ou le failover automatique ; un seul serveur peut déjà traiter plusieurs millions de requêtes par jour
- L’administration serveur reste stable après la configuration initiale, et grâce aux outils d’IA, la barrière d’entrée pour exploiter des serveurs Linux n’a jamais été aussi basse
Cas de réduction des coûts cloud
- Migration récente de tous les projets hors du cloud, avec à la clé une réduction par 10 de la facture AWS mensuelle et plusieurs milliers de dollars économisés
- Facture AWS mensuelle passée d’environ 1 400 $ à moins de 120 $
- Une infrastructure serveur plus puissante obtenue pour moins cher
- Performances doublées et sortie de la dépendance à un fournisseur
- Ce tweet est devenu viral et a mis en lumière deux choses : beaucoup de développeurs voulaient savoir comment faire, et beaucoup d’autres ont exprimé une forte hostilité et une attitude conflictuelle envers cette idée
- Du point de vue métier, il y avait pourtant des bénéfices évidents : coûts divisés par 10, performances multipliées par 2 et fin du verrouillage fournisseur, mais cela a tout de même provoqué une forte opposition
Les intérêts des défenseurs du cloud
- La plupart des personnes opposées à cette idée avaient dans leur profil des mots-clés comme "devops", "cloud engineer", "serverless guy", "AWS certified"
- Elles n’exploitent pas leurs propres projets dans le cloud et ne paient pas elles-mêmes la facture cloud
- Elles sont indifférentes à la facture AWS de leur employeur et ne ressentent pas concrètement la douleur des milliers de dollars gaspillés chaque mois
- Pourquoi AWS leur convient
- Cela semble techniquement complexe et leur donne l’air plus intelligents face aux autres développeurs
- Cela crée de la dépendance et du verrouillage, ce qui les rend difficiles à remplacer comme salariés
- L’usage du cloud garantit des salaires élevés, donc elles n’ont aucun intérêt à prendre des décisions réellement efficaces pour l’entreprise
- Plus l’infrastructure de l’entreprise est complexe et opaque, plus leur poste devient sûr
- Elles ne diront pas la vérité suivante : les serveurs sont en réalité peu chers
Options de location de serveurs bon marché
- Migration vers Hetzner (aucun partenariat, juste des serveurs peu chers)
- Possibilité de louer un serveur bare metal de 80 cœurs pour moins de 190 $ par mois
- Des instances AWS comparables des gammes C5-C6 coûtent entre 2 500 et 3 500 $ par mois, soit 13 à 18 fois plus cher
- Même avec des instances réservées, on reste autour de 1 300 $ par mois, soit encore 7 fois plus cher, avec en plus 46 000 $ à payer d’avance et un engagement de 3 ans
- Les options VPS sont elles aussi intéressantes
- Une machine de 48 vCPU à 300 $ par mois, sans frais d’installation ni engagement long terme, avec une flexibilité totale
- Une machine de 8 cœurs avec 32 Go de RAM à 50 $ par mois, capable de faire tourner tous les projets en même temps tant qu’on n’est pas à plusieurs millions de requêtes par jour
Achat de serveurs et usage de datacenters
- À long terme, acheter un serveur revient moins cher
- On peut acheter un serveur rackable avec 44 CPU, 256 Go de RAM et 2 To de SSD NVMe pour moins de 1 000 $
- De quoi faire tourner une application pendant des années pour moins qu’un mois de cloud
- Option de location d’espace en datacenter
- Possibilité de louer une cage en datacenter ou un rack partagé avec électricité, Internet, refroidissement et sécurité inclus
- Des sites comme DatacenterMap permettent de chercher un datacenter près de chez soi
- Mais cela reste trop complexe pour un petit développeur
- Il faut embaucher des ingénieurs, négocier les prix et gérer divers tracas
- Ce type d’offre vise surtout les moyennes et grandes entreprises, et reste peu pratique pour les petites équipes
- En pratique, c’est presque la même chose que louer un serveur déjà monté chez un acteur comme Hetzner, sans la charge de gestion matérielle
Réponse à la critique « ce n’est pas encore du cloud ? »
- Critique la plus fréquente : « ce n’est pas encore du cloud ? », « tu n’as pas quitté le cloud, tu as juste changé de fournisseur cloud »
- Une critique qui passe à côté de l’essentiel
- Ce qui compte, c’est la différence entre gérer ses propres serveurs et considérer le cloud comme une évidence
- Remplacer des services managés coûteux comme RDS par une petite machine Linux fait tomber la facture à 10 à 100 fois moins
- La plupart des développeurs ont peur des serveurs et n’ont besoin que d’un peu d’encouragement pour comprendre qu’ils peuvent mettre en place leur propre infrastructure à faible coût
- Dans le monde réel, presque personne n’a besoin des services managés hors de prix du cloud ; quelques machines Linux avec des logiciels classiques suffisent largement
- Le débat terminologique brouille le fond
- VPS, bare metal, on-premise ou colo, le nom n’a pas d’importance
- Il faut bien mettre ses serveurs quelque part ; l’important est de savoir si vous gardez plus d’argent dans votre poche ou si vous le donnez aux actionnaires d’Amazon
- Ceux qui tiennent ce discours jouent essentiellement un rôle de gatekeepers
- « Ce n’est pas la bonne manière, il faudrait aussi acheter les switchs, construire le rack et brancher soi-même les câbles Ethernet »
- Un argumentaire toxique et paresseux, obsédé par des détails superficiels pour éviter le point central
Les coûts du cloud sont intrinsèquement élevés
- Tentatives de gaslighting de la part des défenseurs du cloud
- « Tu utilises mal le cloud », « si c’est cher, c’est parce que tu t’y prends mal », « il faut savoir utiliser le cloud »
- Ces personnes n’ont jamais vraiment essayé d’alternative et n’ont aucune expérience réelle de gestion de serveurs pour leurs propres projets
- L’auteur connaît pourtant AWS et a même étudié pour des certifications AWS
- Vérification qu’il n’y avait pas de surprovisionnement d’infrastructure
- Vérification qu’aucun service inutilisé n’était facturé
- Beaucoup de temps consacré à l’optimisation des coûts AWS, avec même des succès où une facture de plus de 5 000 $ par mois a été réduite de plus de moitié
- Il connaît aussi le serverless, les instances réservées, etc.
- Les instances réservées aggravent le problème : elles renforcent le verrouillage fournisseur et vous lient pour 3 ans
- Quand on envisage de quitter le cloud, un engagement de 3 ans est le pire choix possible
- Conclusion après avoir tout essayé : le cloud est tout simplement trop cher
D’où vient cette opposition ?
- Pourquoi autant de gens se soucient-ils autant de ce genre d’économies ?
- Deux grandes conclusions
- Leur gagne-pain est en jeu : si suffisamment de gens sont convaincus par ce type de discours, ils risquent de perdre leur emploi
- Des arguments irrationnels dictés par la peur : depuis dix ans, la construction dans le cloud est à la mode et a créé des millions de postes de « devops » et de « cloud engineers » ; si la mode devient de quitter le cloud, beaucoup de carrières pourraient s’arrêter
- Beaucoup de développeurs savent en secret que le cloud n’est pas aussi formidable que promis au départ
- Ils voient la dépense AWS de leur employeur monter à 10 fois un niveau raisonnable, puis disent quand même « ce n’est pas grave »
- Ils ne veulent pas risquer de contrarier leur manager ni d’endosser la responsabilité
- Ils craignent le coût politique d’être en désaccord avec la personne la plus bruyante de l’équipe
- AWS bénéficie d’un fort suivisme quasi sectaire
- Les certifications apprennent à mémoriser les pages commerciales et les descriptions produit
- Il existe des évangélistes qui prônent le dogme plutôt que le pragmatisme
- On instille la peur du monde extérieur (les serveurs sont dangereux ! ça ne scale pas !)
- L’« ingénieur cloud » devient une identité, facile à adopter mais difficile à quitter
- Comme leur subsistance est en jeu, les fidèles d’AWS répètent des arguments irrationnels dictés par le dogme
- Ils reprennent point par point les argumentaires des landing pages commerciales AWS, sans jamais se demander si ces besoins sont réels
- Comme il s’agit d’un système de croyance, le débat devient irrationnel
Histoire du cloud
- Avant, tout le monde gérait ses propres serveurs
- En VPS, chez un hébergeur, sur du bare metal en datacenter, dans une pièce sombre de l’entreprise ou même à la maison
- Tout le monde était à l’aise avec le fait de se connecter à une machine en SSH
- Au début des années 2010, lancement d’une campagne de marketing/psyops autour du cloud
- Une démarche délibérée visant à vendre des technologies d’entreprise à des startups en phase très précoce
- L’objectif était de les rendre dépendantes le plus tôt possible, afin de pouvoir les exploiter au moment des levées de fonds
- Stratégie d’AWS
- Mise en place de crédits dédiés aux startups
- Tournées dans les accélérateurs pour faire onboarder toutes les startups
- Le piège est simple : rendre l’infrastructure extrêmement bon marché (voire gratuite) au moment de la construction, puis la rendre extrêmement chère dès que l’entreprise grandit, une fois qu’elle est enfermée dans l’écosystème
- IBM Cloud suivait une stratégie similaire (événement de 2014)
- À l’époque, tout tournait sur Heroku et cela fonctionnait très bien
- D’où la question : « c’est quoi exactement, tous ces clouds, et comment ça s’utilise ? »
- Avec l’impression qu’on essayait de vendre quelque chose qui n’avait pas été conçu pour eux
- Ces entreprises ont dépensé des millions de dollars dans des campagnes de promotion du cloud pour pousser les jeunes startups à adopter des technologies d’entreprise
- Les taux zéro de la dernière décennie ont contribué à créer la situation actuelle
- Il existe maintenant un mouvement de contre-culture
- Porté en grande partie par @dhh et la communauté Rails
- Quelque chose de fondamentalement plus frais, plus juste et plus en phase avec la réalité de la plupart des entreprises logicielles sur Terre
Pour la plupart des entreprises, le cloud est inutile
- Certaines personnes ont une vision complètement déconnectée de ce qu’est une vraie entreprise logicielle
- Elles raisonnent avec une perspective Fortune 500 et pensent que l’entreprise de très grande taille est la norme
- Elles imaginent qu’une entreprise moyenne a besoin de haute disponibilité, réplication multi-zone, failover automatique, cluster Kubernetes distribué et de toutes les fonctions du cloud
- En réalité, très peu d’entreprises logicielles ont besoin de cela
- La plupart des entreprises resteront petites selon une logique de loi de puissance
- Aux États-Unis, les petites entreprises représentent 99,9 % de l’ensemble
- Dans l’Union européenne, les PME (moins de 250 salariés) représentent 99 % des entreprises
- La plupart des développeurs surestiment les besoins de montée en charge
- Leur seuil de « fort trafic » est beaucoup trop bas
- Point de comparaison : aujourd’hui, une configuration à 2 serveurs traite plusieurs millions de requêtes par jour pour plusieurs millions de visiteurs mensuels
- Des indépendants comme @levelsio font tout tourner sur un seul serveur
- La plupart des développeurs n’ont jamais fait tourner leur propre projet avec de vrais utilisateurs et du vrai trafic de production sur un seul serveur
- Les besoins techniques sont eux aussi surestimés
- Très peu d’entreprises logicielles ont besoin de ces fonctionnalités, et lorsqu’elles en ont besoin, elles ont en général de bonnes raisons techniques
- Cas comme Netflix : il faut transcoder et diffuser d’énormes volumes de vidéo à l’échelle mondiale, donc il faut des systèmes distribués, des CDN et de l’edge computing
- Une petite application avec mille utilisateurs qui échange juste des objets JSON n’en a absolument pas besoin
- Beaucoup de développeurs ont une vision magique de leur projet, comme s’il s’agissait de Netflix
- C’est une forme de pensée optimiste, compréhensible mais qui mène à de mauvaises décisions techniques
- Ils imaginent qu’un utilisateur remarquera quelques millisecondes de différence quand il appuie sur un bouton, et en concluent qu’il faut des serveurs répartis dans le monde entier
Les serveurs iront très bien
- Beaucoup de gens ont une vision quasi magique du fonctionnement des datacenters
- Ils imaginent que les serveurs en datacenter sont fragiles, instables et peuvent disparaître dans les airs
- Certains pensent même qu’un éclair pourrait faire tomber tout un datacenter
- Les datacenters modernes ont déjà prévu ce genre de problèmes et disposent de nombreuses protections
- Contre la foudre et à peu près tout ce qui pourrait menacer la disponibilité
- Alimentation redondée, refroidissement redondé, connexions Internet redondées, systèmes d’extinction redondés, systèmes de sécurité redondés, avec en plus une importante sécurité physique
- Tout y est conçu pour garantir la disponibilité, avec résilience et redondance à l’esprit (au minimum N+1, parfois 2N)
- Ce sont surtout des réactions fondées sur la peur, nourries par des campagnes de marketing cloud particulièrement efficaces
- Où AWS stocke-t-il ses machines ? Dans un lieu magique sous un arc-en-ciel ?
- Comment les machines AWS seraient-elles magiquement protégées contre des problèmes auxquels les autres datacenters font aussi face ?
- Des catastrophes peuvent arriver (incendie d’OVH en 2021), d’où l’importance des sauvegardes pour se remettre
- Mais sur environ 15 ans d’exploitation de serveurs, l’auteur dit n’avoir jamais connu plus que quelques minutes de panne
L’administration serveur n’est pas un travail à plein temps
- Quiconque a administré des serveurs assez longtemps sait que l’essentiel du temps est consacré à la configuration initiale, puis que les serveurs restent ensuite relativement stables
- Les pannes matérielles sont relativement rares et, une fois en service, un serveur fonctionne souvent parfaitement pendant des années sans intervention majeure
- Gérer ses propres serveurs n’est pas un travail à plein temps
- Pas besoin d’une équipe de 5 devops
- Pas besoin non plus d’embaucher quelqu’un pour cela : vous pouvez le faire vous-même, et ce n’est pas si difficile
- Claude et ChatGPT comprennent bien les systèmes Linux et leur administration, et peuvent aider
- Après la publication du tweet, certains ont supposé qu’il s’agissait de sa première expérience d’administration serveur et qu’il était trop optimiste sur la réalité du sujet
- Il administre pourtant des serveurs depuis 2006
- Il a commencé par éditer des scripts PHP et les envoyer sur un serveur FTP
- Il a appris à installer WordPress, à modifier des templates WP, et tout le reste a suivi
- Cette expérience a été précieuse et lui a enseigné les bases
- Ce qu’est Linux et comment s’y déplacer
- En 2007, il a même demandé à Canonical de lui envoyer un CD-ROM Ubuntu par courrier pour l’installer sur une partition de l’ordinateur de ses parents et apprendre Linux
- Ces expériences précoces lui ont appris les fondations du développement web, sur lesquelles tout le reste s’est ensuite construit
Pourquoi apprendre Linux est important
- Les nouvelles générations de développeurs (Gen Z, Gen Alpha) sont totalement déconnectées du matériel qui exécute les logiciels
- Elles n’ont pas ce type d’expérience de base
- Elles sont nées à une époque où un inconnu sur YouTube explique comment lancer une commande spécifique pour promouvoir tel fournisseur et résoudre comme par magie tous les problèmes d’infrastructure
- Il est donc logique qu’elles aient une vision magique de ce qu’est un serveur et de son fonctionnement
- Elles prétendent pouvoir travailler en « serverless » sans réaliser qu’elles exécutent en réalité leur code sur plusieurs autres machines
- Bien sûr, beaucoup finissent par en apprendre plus sur Linux et les serveurs, mais le diplômé moyen d’un bootcamp a moins d’expérience pratique de Linux que les bidouilleurs FTP d’il y a 20 ans
- Il n’y a ici aucun jugement moral, ni bien ni mal : c’est simplement l’état actuel du développement web
- Résultat : des entreprises comme Vercel gagnent des millions de dollars en capitalisant sur une nouvelle génération de développeurs qui ne sait pas vraiment ce qu’elle fait et n’a jamais exploité de serveurs de sa vie
- L’ignorance coûte deux fois : le coût de l’ignorance elle-même et celui payé à ceux qui l’exploitent
- Ne pas comprendre comment les choses fonctionnent coûte réellement de l’argent
C’est le meilleur moment pour apprendre les serveurs
- Même si vous n’avez jamais géré vos propres serveurs et que tout ce qui sent un peu le back-end vous effraie, tout ira bien
- En réalité, il n’y a jamais eu de meilleur moment pour devenir à l’aise avec les serveurs
- Claude et ChatGPT connaissent très bien Linux et peuvent vous guider étape par étape d’une manière sans précédent dans l’histoire de la technique
- Non seulement pour comprendre comment configurer quelque chose et comment cela fonctionne, mais aussi pour demander quoi faire quand un changement est nécessaire, sans avoir à embaucher qui que ce soit
- Ce n’est pas si effrayant, et ce n’est pas quelque chose qu’il faut faire si souvent
- À l’ère de l’IA où la génération de code devient standard et où le code peut devenir une commodité, savoir déployer ce code sur des serveurs de production bon marché et le rendre réellement utile à des utilisateurs finaux pourrait devenir un facteur clé de différenciation pour un développeur
- Il faut effectivement se préoccuper de sujets comme la sécurité
- Ignorez l’argument selon lequel faire tourner ses propres serveurs serait moins sûr qu’utiliser des serveurs AWS, comme si les instances EC2 étaient magiquement protégées des hackers,
- En pratique, bien configurer les choses n’est pas si difficile ; il suffit de suivre des guides et des scripts de configuration
- Beaucoup de développeurs plus expérimentés font en production bien pire que vous avec l’aide de l’IA
- Demandez à ChatGPT comment durcir un serveur Linux et appliquez les bonnes pratiques de sécurité (pas d’authentification par mot de passe, uniquement des clés SSH robustes) : vous êtes à 90 % du chemin
- Cloudflare ajoute une couche de protection supplémentaire
- Une fois votre machine Linux verrouillée, faites tourner Cloudflare devant tout le reste
- Si vous proxifiez l’IP du serveur via le DNS pour ne pas l’exposer, c’est parfait
- Protection DDoS, edge caching et DNS haut de gamme, essentiellement gratuitement
24 commentaires
Si l’on pense au temps et aux efforts nécessaires pour construire soi-même l’infrastructure requise en on-premise, les services cloud ne paraissent pas si chers.
Et puis, on utilise les services cloud pour leur haute disponibilité, pas pour les coûts.
J’ai l’impression que c’est le même concept qu’IKEA ou Daiso.
Il doit exister des services cloud très rentables et raisonnables.
Mais quand on commence à les utiliser, on finit aussi par prendre ensemble des choses qui paraissent ensuite un peu chères.
(Exemple à la louche) si on utilise Lambda, on finit par utiliser API Gateway aussi, et ça c’est un peu cher et pas pratique -_-^
C’est ce genre de logique.
Cela dit, ce avec quoi je suis très d’accord, c’est :
La raison pour laquelle AWS leur paraît pratique
C’est que ça a l’air techniquement complexe, donc ça donne l’air intelligent devant les autres développeurs
C’est cette phrase-là.
Honnêtement, comme les services AWS existent depuis longtemps et ont évolué au fil du temps, il y a pas mal de fonctions qu’ils n’ont même pas réussi à déprécier ; bien les connaître donnait l’impression d’être classe, donc moi aussi j’ai passé la certif SA, haha.. totalement d’accord~~
Le cloud, l’on-premise et les IDC ont chacun leurs avantages et leurs inconvénients ; au final, l’essentiel est de choisir en fonction de l’usage prévu et de l’échelle des besoins.
Le plus gros postulat, c’est que « les pannes matérielles sont presque inexistantes »…
D’après mon expérience, quand l’entreprise louait un rack dans un IDC pour faire tourner ses serveurs, j’ai le souvenir qu’un disque mourait environ tous les trois jours,
et qu’il fallait aller remplacer le disque et relancer la reconstruction du RAID…
Du coup, en général, je dis simplement d’utiliser le cloud.
Quand le matériel tombe en panne, le fait de pouvoir tout relancer en un « clic » a une valeur énorme…
Qu’un disque tombe en panne tous les trois jours, c’est quand même un peu étrange...
Je ne pense pas que ce soit un cas courant.
Cela remonte à plus de 10 ans, et c’était probablement Seagate…
Backblaze a annoncé que 4 372 disques sont tombés en panne l’an dernier, donc à cette échelle, on finit bien par avoir en gros une panne de disque toutes les deux heures...
C’est une fréquence qui peut se produire à très grande échelle.
Hum, j’ai travaillé assez longtemps dans une salle informatique d’environ 100 racks 42U, avec un environnement comprenant du HPC, du HCI, un système de fichiers distribué construit sur les débuts de Hadoop, ainsi que toutes sortes de stockages, mais je n’ai jamais vu de disque tomber en panne une fois tous les trois jours.
Avis Hacker News
Cela fait des années que j’administre mes propres serveurs en gardant les choses simples, ce qui m’a fait économiser beaucoup de temps et d’argent
J’évite AWS et Azure parce que leur configuration est complexe et que leur interface n’est pas terrible
L’important, c’est de gérer ses serveurs de façon à pouvoir les recréer à tout moment à partir des seuls fichiers de configuration. C’est pourquoi des outils comme Ansible sont indispensables
Si vous devez absolument utiliser le cloud, je recommande DigitalOcean. C’est simple, intuitif et meilleur pour la santé mentale
Je n’utilise DO que pour le niveau 3 de reprise après sinistre, et j’automatise la configuration du cluster avec Terraform et Ansible
La plupart des communautés de développeurs ont tendance à suivre les modes, mais moi, même dans cette ambiance, je déploie mon monolithe Clojure sur JVM sur mon cluster de serveurs physiques et j’en tire des revenus stables
réglages
ulimit, problèmes de performance liés aux SYN cookies, mises à jour de sécurité, réponse aux attaques zero-day, envoi d’e-mails (warming d’IP, gestion des listes anti-spam), conformité au RGPD, etc.Tout cela devient ma responsabilité, et les gens qui utilisent le cloud ne sont pas simplement des « dupes »
Je n’aime pas les raisonnements binaires. La plupart des startups économiseraient beaucoup en passant d’EC2 à Hetzner, Linode ou DigitalOcean
Mais le cloud a aussi beaucoup d’avantages — des fonctions comme les sauvegardes, les bases de données managées ou le multi-AZ sont accessibles en quelques clics
Il n’y a pas de coût initial d’investissement matériel, et en cas de pics de charge importants, cela peut même revenir moins cher
Mais comme le temps d’ingénierie a beaucoup de valeur, le cloud peut être un choix rationnel pendant une phase de forte croissance
Au final, le cloud n’est pas cher parce qu’il est cher en soi, mais parce qu’on utilise des fonctions dont on n’a pas besoin
Il existe aussi de nombreux cas où une stratégie multi-cloud a permis d’éviter une catastrophe
Les VPS et les serveurs dédiés n’ont eux aussi quasiment pas de coût initial, et tant que les pics de charge ne sont pas vraiment extrêmes, le cloud n’est pas forcément moins cher
Les bases de données managées sont pratiques, mais il y a beaucoup de mises à niveau forcées et, hors très grande échelle, je pense qu’il vaut mieux les gérer soi-même
Autrefois, faire évoluer le matériel était difficile, mais aujourd’hui un seul serveur peut offrir les performances d’une baie entière d’autrefois
Les projets de taille intermédiaire peuvent désormais résoudre eux-mêmes des problèmes que le cloud prenait en charge
En revanche, pour obtenir du renfort externe, le cloud est bien plus simple, alors qu’il est difficile de trouver du personnel de support pour du self-hosting
Personnellement, je préfère le self-hosting, mais pour quelqu’un qui ne veut pas gérer l’infrastructure lui-même, le cloud est sans doute préférable
J’ai autrefois géré l’IT dans une startup de hedge fund
Nous faisions tourner un programme d’analyse en C++ sur un serveur double Xeon (512 Go de RAM), et le patron a commencé à paniquer après avoir entendu à déjeuner : « Pourquoi vous n’utilisez pas AWS ? »
J’y ai vu une réalité où la « conformité aux buzzwords » compte davantage que l’efficacité
Beaucoup de CTO dépensent ainsi des budgets inutilement élevés à cause de cette ambiance, dans un monde où une architecture efficace devient presque une faiblesse marketing
L’expression « économiser 10x » est logiquement incorrecte. 10x veut dire plus, pas moins
Le coût du travail de maintenance dépasse celui des serveurs
Même en exploitant 10 instances EC2, on peut automatiser les correctifs avec Systems Manager, sans avoir besoin de construire soi-même toute l’automatisation
Le débat sur le cloud n’est pas binaire
Pour les petites structures, Hetzner ou AWS reviennent à peu près au même, et pour les grandes entreprises, la vraie question est de savoir si elles peuvent construire leur propre outillage
La tranche des entreprises de taille intermédiaire (PME) est la plus ambiguë. Si chaque client a besoin d’un système complètement isolé, AWS est avantageux ; en revanche, avec une charge constante 24/7, des serveurs maison sont préférables
Utiliser le cloud uniquement comme hébergement de VM, c’est y perdre. Il arrive souvent qu’on paie le coût sans utiliser les fonctions cloud
Avec ses propres serveurs, on paie la capacité maximale tout le mois, tandis qu’avec le cloud, on ne paie que les quelques jours nécessaires
Le cloud est très utile pour construire un MVP et valider le marché
Grâce aux crédits startup et aux free tiers, on peut expérimenter rapidement, puis migrer plus tard si le coût devient un problème
En revanche, il faut concevoir dès le départ une architecture indépendante des serveurs, et il est difficile de dégager du temps pour une migration
Notre équipe utilise Google Cloud, mais comme nos dépenses sont faibles, notre commercial n’est pas ravi
La possibilité de passer d’un cloud à l’autre devient un levier de négociation
Le cloud facilite aussi la réponse aux SLA ou aux exigences de protection des données, ce qui aide à gagner la confiance des clients entreprises
Je me demande pourquoi AWS a connu une croissance explosive au départ
Au début des années 2010, louer une baie et monter des serveurs coûtait cher et prenait du temps, et les déploiements multi-région étaient quasiment impossibles
AWS a résolu ces problèmes, mais la situation a changé depuis
Il y a aussi eu l’anecdote de Squarespace sauvant ses serveurs pendant l’ouragan Sandy en apportant eux-mêmes du carburant
Chez Hetzner, on peut commander un serveur, installer Ubuntu et appliquer sa configuration Ansible en 10 minutes
Tarif fixe, bande passante illimitée, performances prévisibles — la simplicité de l’absence d’abstractions inutiles est séduisante
EC2 a supprimé cette contrainte, et Lambda a poussé encore plus loin. Aujourd’hui, la location bare metal est devenue bien moins chère
À l’époque, la politique de crédits gratuits d’AWS était en réalité une stratégie de lock-in
Héberger soi-même des serveurs dans un datacenter n’est pas aussi difficile qu’on l’imagine
J’avais besoin d’un CPU à haute fréquence pour un serveur de jeu, difficile à trouver dans le cloud, alors je l’ai monté moi-même
Cela me coûtait environ 15 £ par mois, installation comprise, et cela a très bien tourné pendant des années. Au final, les économies ont été importantes
On plaçait les équipements dans un datacenter de Seattle et on les administrait à distance via un KVM sur modem
Nous avons migré vers Hetzner il y a quelques années, et vu les économies réalisées, il y a peu de chances que nous revenions un jour au cloud
L’exception, ce sont les Cloudflare Workers, dont la qualité est bonne et le quota gratuit généreux
Grâce à l’IA, il est devenu bien plus facile d’écrire des scripts d’automatisation, de déploiement et de sauvegarde, ce qui rend l’administration plus simple qu’avant
À titre d’information, Claude Code d’Anthropic offre actuellement 250 $ de crédits gratuits aux utilisateurs Pro/Max jusqu’au 18 novembre
L’annonce associée est consultable dans ce tweet
Rien qu’en faisant l’expérience d’une restauration de sauvegarde, on en perçoit sans doute la valeur, non ? En on-premise, c’est surtout la restauration des sauvegardes qui est la plus pénible.
Eh bien... je suis cent fois d'accord avec les idées que « les coûts du cloud sont plus élevés que nécessaire » et que « dans la plupart des cas, on n’a pas besoin des fonctionnalités des grands fournisseurs de cloud », mais le ton donne presque l’impression que l’article affirme que tous les services cloud sont une arnaque, ce qui le rend assez désagréable à lire. Cela sonne comme si on disait : « tous les produits d’assurance sont des arnaques ».
Le cloud, c’est surtout pour éviter d’avoir à gérer des serveurs ou pour pouvoir monter rapidement en charge quand la demande est difficile à prévoir. En dehors de ces cas d’usage, je ne sais pas vraiment si cela a du sens.
Je suis d’accord avec tout, mais il est dommage qu’il n’y ait aucune mention des aspects de sécurité lorsqu’on exploite directement un serveur pendant des années.
Je partage aussi cet avis.
Exact.
Je suis d’accord à 100 % sur le fait que le cloud coûte cher.
Cela dit, quand on pense qu’il faut aujourd’hui faire tourner plus de 200 conteneurs sur du bare metal en configurant soi-même Kubernetes,
si l’on est un développeur backend solo, sans DevOps, et qu’on considère qu’on peut réduire la charge de gestion et d’exploitation des serveurs pour un coût équivalent à la moitié de la moitié du salaire d’une personne, ce n’est en réalité pas un si mauvais choix.
S’il y a une personne dédiée uniquement à la gestion de l’infrastructure serveur, sortir du cloud peut clairement devenir une bonne option.
Personnellement, quand j’ai essayé de construire un service en évitant au maximum le cloud, j’ai cru devenir fou.
J’avais besoin d’un registre d’images de conteneurs, mais en voulant le mettre en place, le stockage local était contraignant, alors je me suis renseigné sur une solution compatible S3 pour faciliter les sauvegardes, j’ai aussi déployé un service VPN pour bloquer l’accès externe, sans parler de la gestion des certificats HTTPS sur le reverse proxy et de tous les réglages de sécurité pour le CI/CD... de l’auto-hébergement, quoi...
Si l’on n’utilise que quelques services simples dans le cloud, alors oui, le bare metal est évidemment moins cher et c’est sans doute la bonne option. En revanche, s’il faut une intégration avec d’autres services et que l’on veut se débarrasser de diverses contraintes, alors même si le coût des serveurs est plus élevé à court terme, le fait de ne pas avoir à mettre en place un à un tous ces services peut faire pencher la balance, car on économise les coûts d’installation et d’administration.
Il existe de nombreux registres d’images open source.
Oui, il y en a beaucoup. Je parlais de la charge que représente le fait de devoir l’exploiter soi-même. J’utilise aussi Nexus et Harbor.
Personnellement, je n’ai pas constaté de charge ni de problème particulier.
Mais comme chacun a sa propre définition de ce qui constitue une charge, je peux comprendre qu’on le voie ainsi.
Pour quel type de service développez-vous quelque chose qui nécessite un registre d’images de conteneurs ?
C’est parce que, quel que soit le service développé, je préfère déployer des conteneurs. Et pour le déploiement aussi, je préfère autant que possible éviter les connexions directes en
ssh. Si on ne pense qu’au coût… il doit bien exister des méthodes permettant un déploiement direct sans registre, mais je donnais juste un exemple, et je voudrais plutôt mettre l’accent sur les aspects un peu contraignants qui apparaissent, comme les services d’e-mail.