Utilisez un seul gros serveur (2022)

• L’essentiel du débat n’est pas monolithique vs microservices, mais de déterminer si un système distribué vaut sa valeur au regard de la surcharge de développement et d’exploitation
• Un serveur moderne unique dispose de dizaines à centaines de cœurs, de mémoire à l’échelle du To et d’E/S à plusieurs dizaines ou centaines de Gbit/s, avec une marge de performance suffisante pour la plupart des services web
• Des benchmarks réels montrent qu’un seul serveur peut assurer des traitements haute performance comme Nginx à 500 000 RPS, PostgreSQL à 70 000 IOPS, NoSQL à 1 million d’IOPS, encodage 4K à 75 FPS
• Le cloud améliore la commodité et la disponibilité, mais sa prime tarifaire est importante et doit être évaluée en termes de retour sur investissement
• Les architectures cloud native et serverless ne deviennent avantageuses en coût que lorsque les schémas d’usage sont extrêmement variables
• Mais la prime de coût du serverless et des micro-VM est élevée, et si la charge est continue et prévisible, la montée en charge verticale est plus économique
• La disponibilité peut être largement assurée avec une redondance primaire/secondaire (ou 2×2) et des combinaisons de matériel hétérogènes, tandis qu’une stratégie consistant à ne distribuer que le CDN et les sauvegardes est raisonnable

---

Vue d’ensemble : la valeur d’« un gros serveur » face aux systèmes distribués

• Le cœur du débat « monolithique vs microservices » réside dans l’évaluation de la valeur réelle, en temps développeur et en coûts, de l’adoption d’un système distribué
• Les logiciels modernes fonctionnent sur la virtualisation des serveurs et diverses couches d’abstraction, et même le « serverless » ou le « bare metal » reposent au final sur des ressources de serveurs physiques
• Les serveurs d’aujourd’hui offrent une excellente efficacité coût/performance, bien supérieure à ce qu’on imagine souvent
  • Par rapport au passé, les spécifications ont énormément progressé en nombre de cœurs, bande passante mémoire, lignes PCIe et stockage NVMe, et de nombreux services peuvent atteindre leur QPS cible sans distribution

La puissance du matériel serveur

• Le serveur d’exemple de Microsoft Azure embarque 2 CPU serveur AMD de 3e génération, pour un total de 128 cœurs et 256 threads
• Un seul serveur peut atteindre environ 4 TFLOPs de performance de calcul, soit davantage que des supercalculateurs du début des années 2000
• Avec 16 emplacements DDR4-3200 par socket, l’évolutivité mémoire monte jusqu’à 8 To, et même des circuits d’achat pratiques permettent 1 To de RAM
• Au total, 128 lignes PCIe Gen4 permettent d’ajouter 30 SSD NVMe et des cartes réseau à 50–100 Gbit/s pour du stockage et du réseau hautes performances

Ce qu’un tel serveur unique permet de faire (benchmarks à l’appui)

• Il est possible d’atteindre 400–800 Gbit/s de transmission vidéo, 1 million d’IOPS NoSQL, 70 000 IOPS PostgreSQL, 500 000 RPS avec Nginx
• On observe aussi un fort débit sur des tâches intensives en CPU, mémoire et E/S, comme la compilation du noyau Linux en 20 secondes ou l’encodage x264 4K à 75 FPS

Comparaison des coûts de location et d’achat des serveurs

• OVHCloud : un serveur 128 cœurs / 512 Go de RAM peut être loué pour environ 1 318 $ par mois
• Hetzner : un serveur 32 cœurs / 128 Go de RAM est proposé à 140 € par mois, avec des tarifs variables selon la taille
• AWS m6a.metal : un serveur 96 cœurs physiques / 768 Go de RAM coûte 8,29 $ de l’heure, soit environ 6 055 $ par mois, ce qui illustre une forte prime cloud
• En achetant directement chez Dell un serveur de spécifications comparables pour environ 40 000 $, l’investissement peut être amorti par rapport au cloud en environ 8 mois
• À débit identique en serverless, on estime une prime de coût de 5,5× par rapport aux instances et de 25× par rapport à un hébergement à bas coût

Pourquoi les systèmes distribués ont-ils autant séduit ?

• Par le passé (autour de 2010), les limites des CPU, de la mémoire et du stockage imposaient à grande échelle de combiner plusieurs serveurs
• Mais avec les gros serveurs modernes, les SSD NVMe et une bande passante mémoire élevée, les limites de traitement sur nœud unique ont fortement progressé, alors que les VM et conteneurs restent conçus à l’échelle de petites ressources serveur

Quand un seul gros serveur suffit

• La plupart des services web sous 10k QPS tiennent sur une seule machine, et les services simples peuvent même monter jusqu’à un million de QPS
• Même pour le streaming vidéo, il est réaliste d’avoir le control plane sur un seul serveur, et des benchmarks ainsi que des tableaux de performance génériques permettent d’estimer la bonne taille de serveur
• Hors cas particuliers, une configuration avec serveur principal et serveur de secours suffit aussi pour garantir la disponibilité

« Plus haut » plutôt que « plus large » : préférer quelques gros serveurs à une grande flotte de petits

• Même lorsqu’un cluster est nécessaire, quelques gros serveurs impliquent une surcharge de coordination O(n) plus faible qu’une multitude de petits serveurs
  • En d’autres termes, à long terme, il est plus efficace de réduire le nombre de serveurs et d’en augmenter la capacité
• Dans les environnements serverless ou à base de conteneurs éphémères, cette surcharge relative devient particulièrement importante
• Le point faible est le point de défaillance unique, mais il peut être largement atténué avec une architecture primaire/secondaire (dans des DC différents)
• Pour plus de robustesse, une configuration 2×2 (2 serveurs dans le DC principal + 2 dans le DC secondaire) et des déploiements sur du matériel et des constructeurs différents permettent d’éviter les pannes corrélées
• En location, la diversification des modèles de serveurs peut réduire le risque de pannes en chaîne liées à des disques ou SSD issus du même lot

Les avantages et les limites du cloud

• Le cloud brille par sa disponibilité, sa rapidité de reprise et sa simplicité opérationnelle, et il peut être légitime de payer cette prime tarifaire
  • Il permet un redémarrage rapide dans la limite du budget, sans indisponibilités prolongées, et donne accès à de vastes pools de ressources gérés comme une grille
  • Les fournisseurs de serveurs loués sont moins chers, mais ont des limites en matière de qualité, de réseau ou de support premium
• En revanche, les offres cloud poussent souvent des architectures dépendantes du fournisseur comme les VM autoscalées, le serverless ou les bases HA managées ; il faut donc rester vigilant sur les coûts et la complexité
• La gestion d’un trafic massif n’est pas, en soi, la principale raison d’adopter du cloud native, et il existe de nombreux cas où un seul gros serveur permet de servir des millions d’utilisateurs simultanément

Coût des pointes de charge et critère des charges bursty

• Quelqu’un doit provisionner pour le pic, donc le coût du pic finit toujours par être facturé quelque part dans la chaîne d’approvisionnement
• Pour des charges bursty et temporaires (par exemple une grosse simulation ponctuelle), le serverless / l’autoscaling est économique, mais pour des charges continues et prévisibles, l’exploitation fixe d’un gros serveur est plus efficace en coût
• En tirant parti d’engagements d’un an, d’instances spot ou de négociations commerciales, le coût des instances peut encore baisser, ce qui creuse davantage l’écart de prime avec le serverless

Évaluation quantitative de la « prime cloud »

• Le serverless computing comme AWS Lambda peut entraîner une prime de coût de 5 à 30× par rapport à un serveur équivalent
• Hypothèse : si un serveur à 8,2944 $/heure fournit 1k QPS et 768 Go de RAM, le remplacer par Lambda à débit égal reviendrait à environ 46 $/heure, soit une prime de 5,5×
• On estime une prime de 25× par rapport à la location OVH, et avec seulement 5 % de taux d’utilisation, un hébergement à bas coût devient déjà plus économique que le serverless
  • Avec des contrats longue durée ou des instances spot, l’écart de prime peut encore augmenter
• Même si le QPS varie, la conversion en mémoire-temps donne des multiplicateurs de prime similaires, et l’essentiel est d’adapter l’échelle du serveur à la taille réelle de la charge

Objections et malentendus fréquents

• « Avec le cloud, plus besoin d’équipe d’exploitation » : seul l’intitulé change en Cloud Ops ; il faut toujours des compétences en documentation, traçabilité des changements et gestion des dépréciations, ce qui peut même augmenter les coûts humains
• « Avec le cloud, plus besoin d’appliquer les mises à jour de sécurité » : certaines tâches sont externalisées, mais seulement dans des domaines faciles à automatiser ; les audits de bibliothèques et la vérification des configurations restent nécessaires
• « Le cloud rassure grâce à sa haute disponibilité » : la complexité supplémentaire crée de nouvelles fragilités, et même une redondance entre régions ou fournisseurs n’élimine pas complètement les pannes corrélées
• « Le cloud accélère le développement » : l’agilité initiale est un vrai atout, mais il faut surveiller le point d’inflexion des coûts pour basculer au bon moment
• « Notre trafic est très bursty » : dans ce cas, le serverless et l’autoscaling sont adaptés
• « Et le CDN ? » : la réduction de latence et de bande passante fait partie des éléments qu’il est indispensable d’acheter en mode distribué, tout comme les sauvegardes

Monolithique vs microservices et structure serveur

• Le « gros serveur » est naturellement associé à une architecture monolithique, mais il est aussi possible d’exécuter des microservices sous forme de plusieurs conteneurs sur une seule machine
  • Toutefois, la surcharge de communication inter-processus, de déploiement et d’observabilité reste pénalisante même sur un hôte unique, ce qui réduit fortement le bénéfice réel au regard de la complexité
• Pour les phases initiales ou les structures de petite à moyenne taille, un monolithe ou un petit nombre de services est plus avantageux en termes de simplicité opérationnelle

Conclusion

• Dans la majorité des cas, choisir la montée en charge verticale (un seul gros serveur) est plus simple et plus économique qu’une mise à l’échelle horizontale ou une architecture centrée sur le cloud
• En combinant redondance primaire/secondaire, matériel hétérogène et externalisation du CDN/des sauvegardes, on peut obtenir une fiabilité pragmatique tout en gardant un avantage net en coût total de possession (TCO) dans les environnements à charge continue
• À condition de mettre en place une stratégie solide de redondance matérielle, l’approche du « gros serveur unique » constitue un choix très adapté à des services réels

[GN⁺]

Commentaires Hacker News

• L’un des plus gros problèmes de la « Cloud Tax », c’est qu’elle limite artificiellement l’éventail des solutions que les ingénieurs peuvent envisager. Par exemple, pour environ 200 $/mois chez AWS, on obtient un serveur avec 4 vCPU et 16 Go de RAM, soit à peu près les caractéristiques d’un laptop de développement d’il y a 5 ans. À l’inverse, chez Hetzner, on peut louer pour le même prix un serveur 48 cœurs avec 128 Go de RAM. L’écart de puissance de calcul est énorme. Des approches qui deviennent parfaitement efficaces avec 10 fois plus de capacité n’ont plus vraiment de sens sur un petit nœud. Dans certains cas, ces conditions permettent aussi d’économiser du temps d’ingénierie en évitant de construire des systèmes plus complexes. Bien sûr, il faut aussi prendre en compte d’autres aspects comme la durabilité, mais à l’inverse, un serveur dédié garantit des performances stables sans souci de noisy neighbor
  • En 2025, on peut utiliser pour des besoins généralistes des services comme fly.io, sans complexité ni procédures lourdes, et pour certains frameworks il existe des options comme Vercel, très bonnes si l’on est sur la stack visée. Et si l’on a besoin de plus, on peut louer à bas prix de vraies machines monstrueuses chez OVH/Hetzner/Latitude. Pour un simple blog, il existe déjà énormément de VPS. Le cloud traditionnel ne sert plus guère qu’aux contraintes réglementaires, aux processus internes ou à l’inefficacité. J’ai l’impression que la productivité de développement comme le coût machine y sont nuls. À moins d’avoir une équipe totalement libre de ses choix qui adore les systèmes d’autorisation façon DMV, les nœuds Intel bruyants, les marges élevées et le support médiocre, cela n’a plus beaucoup de sens dans la plupart des cas
  • C’est encore plus que ça — avec un serveur bare metal, pas besoin de se soucier de la latence réseau, de la latence/contension de bande passante mémoire des VM, ni de structures de cache séparées. On peut par exemple donner énormément de RAM à Postgres et se contenter du cache disque Linux. C’est bien plus simple et plus rapide
  • Je ne comprends pas pourquoi il faudrait systématiquement partir sur AWS même pour de petits services. Je n’ai pas fait quelque chose d’aussi complexe que toi, mais un client utilisait un petit combo appli web PHP + serveur AWS/SQS/S3 pour 100 $/mois. Je l’ai réimplémenté en Python/Django/PostgreSQL (SQLite au départ) et migré sur un VPS à 25 $/mois. L’OCR PDF, les mises à jour de prix, la détection de produits manquants, le site lui-même, tout tourne très bien sur 4 cœurs et 6 Go de RAM. C’est une appli interne qui n’aura probablement jamais beaucoup plus de 100 utilisateurs, donc même si elle grossissait un jour, la migration resterait très simple. À ce stade, il n’y a vraiment aucune raison de payer un serveur AWS à 100 $, tant qu’on n’a pas besoin d’une montée en charge massive
  • Entièrement d’accord. Avec une base embarquée comme sqlite et quelques optimisations sur les écritures par lots, on peut aller incroyablement loin même chez Hetzner. L’argument du « surprovisionnement coûteux » n’a plus de sens dès qu’on sort d’AWS, tant le rapport performance/prix est incomparable. Et paradoxalement, plus un système est complexe, plus il peut être moins fiable et moins résilient qu’un nœud unique. Il est rare qu’un seul composant tombe de manière isolée
  • Je pense plutôt l’inverse. J’adore Hetzner pour les petits sites, mais sur les gros projets, le cloud donne vraiment l’impression de lever presque toutes les contraintes. Si je travaille sur un projet où mon temps a de la valeur, alors que l’hébergement coûte 200 $ ou 2 000 $ ne change rien. Je ne vois pas vraiment de différence de temps de développement entre AWS CDK/Terraform + GitHub Actions et Docker/K8s/Ansible + pipeline CI. Je n’ai jamais eu l’impression que le bare metal me faisait gagner beaucoup plus de temps d’ingénierie. Une approche IaC avec Fargate + RDS est aussi très pratique. Si l’on a réellement besoin de séparer, faire évoluer et fiabiliser le stockage de fichiers, ou d’intégrer toute une série de services d’infrastructure dédiés comme la création dynamique de sous-domaines, alors le coût d’apprentissage et d’intégration de nouvelles briques est bien plus élevé. En réalité, je fais ce genre de choses depuis avant l’ère du cloud, et pour un projet rentable, je considère que le coût du cloud vaut l’investissement. Si son coût est vraiment trop lourd, c’est probablement plus un hobby qu’un business. Gérer du RAID ou plusieurs systèmes de fichiers en cluster, ce n’est pas quelque chose que j’ai envie de faire avec les ressources d’une startup/entreprise classique, ni avec mon temps. J’ai l’impression que c’est un peu comme préférer bricoler Arch + Emacs, versus être satisfait avec un MacBook. Si l’on veut changer l’ordonnanceur du noyau, alors oui, je recommanderais Arch ; sinon, je recommanderais le MacBook. Cela dit, si le budget est vraiment serré et que le raw throughput est critique, j’ai aussi vu des cas où un serveur dédié était exactement ce qu’il fallait, avec des économies de plusieurs milliers de dollars. Mais si le projet avait réussi, on aurait probablement ensuite fait de la montée en charge verticale, et c’est un cas plutôt rare
• HN exploite deux machines, une pour le service de production et une pour les sauvegardes. C’est un schéma utile, car en cas de souci matériel ou de besoin d’upgrade, on peut basculer immédiatement. Il faut simplement faire attention à ne pas avoir deux clones strictement identiques, car ils pourraient tomber en panne en même temps
  • Ce n’était pas aussi grave qu’un SSD, mais il y a aussi eu un bug amusant sur des CPU AMD. Après environ 1044 jours, un certain cœur pouvait complètement se figer cas de blocage des CPU AMD EPYC Rome
  • Je me demande s’il existe des statistiques sur le downtime de HN. Je me souviens d’une ou deux pannes en dix ans, donc à vue de nez, on dirait plus de 99,99 % d’uptime
• J’utilise depuis plus de 10 ans un hybride colo + cloud public, et à partir d’une certaine taille, cela a toujours été la meilleure option pour optimiser les coûts. L’efficacité du matériel continue aussi de progresser. Il faut des admins réseau/infra, mais honnêtement aujourd’hui c’est très facile à gérer, et de toute façon il faut aussi des admins « cloud », donc l’économie sur les salaires est quasiment nulle. Les options de colocation sont variées et les fournisseurs vendent du bandwidth agrégé. À une époque, je faisais tourner 8 clusters Dell VRTX, un SAN et plus de 500 VM, du gros msSQL jusqu’à kube. En cloud public, même avec des remises réservées, la facture serait montée à plus de six chiffres. En colo, cela me coûtait 2 400 $/mois, essentiellement pour l’électricité. Et la forte baisse de performance des nœuds de cloud public reste toujours surprenante, même à génération CPU/VCPU identique. Il faut bien comprendre les deals matériel, les mises à jour, les licences et les contrats de support, mais en pratique cela reste tout à fait gérable. Et aujourd’hui, il est en plus facile de raccorder le cloud et le réseau : on fait arriver une fibre et on la relie au VPC, et c’est réglé
  • Si je comprends bien, la colocation consiste à acheter son propre matériel puis à ne louer au datacenter que l’alimentation, le rack et la connectivité. Je me demande si c’est bien ça, et j’aimerais comprendre en quoi c’est préférable à une simple location de serveurs bare metal
• Cela fait des années que j’en discute avec des amis. Le plus gros défaut de l’infra locale, c’est qu’il faut des gens compétents pour l’exploiter correctement. L’article se concentre sur le haut de gamme, mais sur le bas du marché, dès qu’on a déjà un peu de matériel, un petit rack ou du réseau rentabilisent l’investissement en un an. Vu la prime cloud actuelle, même en embauchant un admin, l’infra locale semble rester plus économique
• Dans une entreprise à laquelle j’ai participé au lancement, nous développions un moteur d’automatisation pour l’entreprise, et l’équipe voulait absolument le déployer en SaaS pour maximiser les revenus. En réalité, un schéma de base multi-tenant + un VPS auraient largement suffi, mais l’équipe s’est focalisée sur l’apprentissage de kubernetes et d’une stack cloud native, en consacrant un an entier à l’environnement de développement et à l’automatisation de l’exploitation. Finalement, l’entreprise a fait faillite assez vite
  • Mais les ingénieurs ont au moins pu capitaliser sur cette expérience avec k8s pour retrouver un autre emploi
  • J’ai vécu quelque chose de similaire : j’ai perdu beaucoup trop de temps à résoudre en avance des problèmes dont j’aurais peut-être eu besoin dans cinq ans. Pour la plupart des projets et des startups en phase initiale, un simple PaaS ou nginx + conteneurs Docker suffit largement. On peut réfléchir au reste quand la vraie douleur apparaît
  • C’est pour ça que j’aime bien le PaaS tant que « la facture ne fait pas vraiment mal ». On paie heroku/render/fly et on se concentre sur le PMF (Product-Market Fit). Sinon, on peut aussi choisir de s’amuser avec K8s sur l’argent des VC, puis répéter le cycle au job suivant
• Beaucoup de business ne sont pas si critiques. Les gens stressent énormément à l’idée d’une interruption, mais en réalité les services qu’ils exploitent ne sont pas si importants. Même si la prod disparaît en pleine journée, ce sera gênant, mais le monde ne s’effondrera pas. Ce sont des entreprises qui faisaient très bien tourner 250 personnes sur un simple serveur de bureau, puis ont explosé leur budget en migrant de force vers le cloud. Le cloud est excellent pour certains usages précis, mais pour le reste, cela relève souvent davantage du marketing. Beaucoup d’ingénieurs ont aussi tendance à s’obséder avec la « scalabilité parfaite » et à chercher une architecture idéale plutôt qu’une solution simplement assez bonne
  • Un ancien collègue disait toujours : « Au moins, si on se trompe, personne ne mourra. » Il avait travaillé sur des sujets bien plus lourds en responsabilité, et cet état d’esprit a été très utile dans des situations difficiles
• À force de construire des architectures complexes pour viser 100 % de disponibilité, on finit souvent par commettre des erreurs qui réduisent en réalité la fiabilité. La plupart des business peuvent supporter de temps en temps 1 à 2 heures de panne, voire une perte de données limitée. Si l’on fixe clairement ces attentes dès le départ, on peut concevoir des systèmes bien plus simples et plus fiables
  • Et cela coûte aussi beaucoup moins cher. En revanche, ces attentes sont souvent difficiles à faire accepter par des dirigeants non techniques, surtout la perte de données. Les ingénieurs disent qu’ils ne gèrent que l’environnement, mais dans la réalité ce n’est pas si simple, et au moindre faux pas on peut vite avoir l’air incompétent
• C’est un très bon article. Si l’on veut scaler de cette manière, hors cloud, cela vaut aussi le coup de réfléchir à l’ajout d’un CDN. Un CDN apporte aussi un effet WAF et du basculement DNS. Le petit inconvénient du non-cloud, c’est qu’il faut exploiter soi-même la base de données. On peut donc envisager un fournisseur qui propose aussi une base cloud en option, ou, dans une architecture active/passive, faire tourner le nœud passif sur une VM cloud avec autoscaling pour réduire les coûts. Les prix de location de serveurs sont vraiment très bas aujourd’hui : un VPS 4 Go peut coûter autour de 6 $, et un bare metal quad-core avec 32 Go tourne autour de 90 $. Un comparateur comme serversearcher.com peut être utile
  • J’ai simplement déployé Postgres dans un conteneur Docker avec des sauvegardes régulières, et je n’ai jamais eu de vrai problème. C’est facile à exploiter, donc ce n’est pas particulièrement contraignant
  • Sur une seule machine, sqlite peut offrir des performances bien supérieures à Postgres/MySQL, tout en étant beaucoup plus simple à administrer
• Moi aussi, je fais tourner mes services sur des VPS. J’ai abandonné le cloud depuis longtemps. Si mes projets commencent à gagner de l’argent, je compte acheter du matériel et le mettre en colo. Le cloud me faisait penser à une appli de rencontres : c’était amusant un temps, mais maintenant c’est fini et j’ai envie de faire quelque chose de vraiment productif
  • La colo a aussi son lot de problèmes. Les pannes électriques en datacenter qui grillent du matériel sont très courantes. Paradoxalement, l’électricité chez moi est plus stable. À moins d’avoir une activité où quelques minutes d’indisponibilité font perdre des millions, la plupart des gens pourraient faire tourner leurs serveurs au sous-sol sans vrai problème. Beaucoup surestiment énormément leur besoin de 99,999 % d’uptime ou de bande passante. Et la colo n’est pas forcément aussi bon marché qu’on l’imagine. L’électricité d’un datacenter est souvent plus chère que l’électricité résidentielle ou classique pour entreprise. Ce qui est vraiment peu coûteux, c’est surtout Internet/la fibre, et dans beaucoup de pays on peut désormais avoir du 5 à 10 Gbit business pour 100 euros, alors qu’avant on demandait plus de 2 000 euros rien que pour 1 Gbit
• Même en mettant de côté l’analyse des coûts ou de la capacité, il n’est pas facile d’aller à contre-courant de la tendance du secteur. Le fait de « ne pas avoir à se soucier du matériel » est un avantage bien réel. Il existe aussi une forte aversion au capex (dépenses d’investissement), parce que le matériel serveur impose un coût initial important. Et puis, lorsqu’une région AWS tombe en panne, on a moins l’impression que c’est « notre faute », alors que si un serveur interne lâche, cela paraît tout de suite être « notre responsabilité »
  • Cette aversion extrême au capex vient en grande partie de la logique du financement VC : si les investisseurs exigent une croissance ultra-rapide, alors des investissements anticipés comme l’achat de serveurs deviennent difficiles à justifier. En revanche, un business stable peut absorber sans problème un petit capex annuel
  • Il n’est pas nécessaire d’acheter le matériel — on peut aussi très bien le louer chez Hetzner, par exemple. J’aimerais bien qu’on m’explique plus précisément ce que recouvre cet avantage de « ne pas avoir à se soucier du matériel »
  • Cette logique visant à éviter le capex existe réellement. Pourtant, quiconque sait utiliser une calculette voit bien qu’aujourd’hui le prix des serveurs représente peu de chose à l’échelle d’un business. Ce qui coûte cher, en réalité, c’est tout l’« espace » autour du serveur, donc le plus souvent on ne loue pas un serveur, on loue l’espace qu’il occupe : rack, alimentation, etc.
  • Au fond, ce que les entreprises paient vraiment, c’est une « abstraction de la responsabilité ». Les dirigeants de grands groupes sont rassurés quand ils choisissent une solution d’un grand nom comme Microsoft ou AWS
  • Avec la location de serveurs bare metal, on n’a à se soucier ni du capex ni de la maintenance