Table des matières de l'article :
Si vous aussi êtes ingénieur système depuis 2005, avec des milliers de serveurs à votre actif et des milliers de cas différents les uns des autres, vous conviendrez avec moi qu'aujourd'hui on n'en peut vraiment plus. Sinon, vous pourriez croire à de nombreuses légendes urbaines colportées par des vendeurs sans scrupules et sans aucune connaissance des faits autre que celle du simple profit. Travailler dans le secteur informatique est devenu démotivant et ingrat, étant donné que le marché est désormais contrôlé au sommet par le marketing et de véritables légendes urbaines, véhiculées par des individus sans qualification ni expérience dans le domaine des systèmes. Ces commerciaux vendent souvent des solutions miracles qui promettent des performances et une fiabilité inégalées, sans comprendre les réels besoins techniques et opérationnels.
Commençons par recenser les affirmations douteuses et les réfuter par un raisonnement logique, des documents justificatifs et des références. Notre objectif est d'apporter clarté et vérité face à la désinformation ambiante, en nous appuyant sur des années d'expérience pratique et une connaissance approfondie du secteur . Nous mettrons à jour cet article au fur et à mesure que de nouveaux mythes seront démystifiés. Ce faisant, nous espérons contribuer à une meilleure sensibilisation et à une expertise technique accrue, aidant ainsi les professionnels de l'informatique à prendre des décisions éclairées et à éviter les pièges du marketing trompeur.
Les hôtes partagés sont lents.
Avant toute chose, la taille du site hébergé, le nombre d'autres sites présents sur la même machine et les ressources accaparées par ces mêmes sites sont des facteurs déterminants. Il est clair que partager un hébergement avec d'autres sites ne garantit ni performance ni stabilité, car un autre site hébergé sur le même serveur peut monopoliser les ressources et impacter le nôtre. Cependant, un hébergement mutualisé optimisé avec Varnish Cache, des stratégies et politiques de cache adaptées, un bon TTFB et des protocoles rapides comme HTTP/3 ou QUIC peut s'avérer bien plus performant qu'un serveur dédié à 1 000 € par mois configuré avec Plesk ou cPanel sans aucune optimisation. La puissance sans maîtrise est vaine. Ainsi, avec les optimisations adéquates, un hébergement mutualisé peut offrir d'excellentes performances, tandis qu'un serveur dédié mal configuré peut se révéler inefficace et lent. La clé réside dans l'optimisation et la gestion des ressources.
Si un hébergement sur notre propre serveur est piraté, des attaquants peuvent attaquer notre site.
Si notre service d'hébergement était piraté, notre site web pourrait être attaqué. Ce scénario est cependant très improbable. De nos jours, à l'exception de quelques rares individus malchanceux et inexpérimentés, tous les fournisseurs d'hébergement ont compris l'importance de la séparation des privilèges au niveau des processus et du système de fichiers. Par exemple, l'utilisation de PHP-FPM (FastCGI Process Manager) permet une gestion séparée des processus PHP pour chaque site web, en attribuant à chaque pool de processus PHP son propre UID (identifiant utilisateur) et GID (identifiant de groupe) , garantissant ainsi que chaque site web fonctionne avec des privilèges distincts et isolés. Si un site web hébergé sur notre serveur virtuel était piraté aujourd'hui, l'attaquant ne disposerait pas des privilèges suffisants pour lire ou écrire dans nos fichiers ou notre base de données, car les processus PHP-FPM associés à notre site web s'exécutent avec des UID et GID distincts et ne peuvent pas interférer avec ceux d'autres sites web. La situation est différente si l'attaquant compromet un site hébergé à proximité du nôtre et utilise ensuite des failles de sécurité improbables pour obtenir les privilèges maximum (root). Cela pourrait alors compromettre tous les sites hébergés sur le même serveur. Toutefois, une configuration correcte et des mises à jour continues des systèmes et des applications réduisent considérablement la probabilité de réussite de telles attaques.
L'hébergement avec des ressources garanties est préférable à l'hébergement au mieux.
L'hébergement avec ressources garanties est préférable à l'hébergement au mieux. Tout dépend du contexte. Si vous devez choisir entre des ressources garanties (minimum et maximum) d'un cœur et de 1 Go de RAM, optez toujours pour l'hébergement au mieux. Même si les ressources minimales qui vous sont réservées ne sont pas garanties, il est clair que dans plus de 90 % des cas, une solution au mieux offrira de meilleurs résultats et des performances supérieures à une solution avec des ressources dédiées insuffisantes pour faire fonctionner correctement un site web. Avec l'hébergement au mieux, les ressources sont partagées dynamiquement entre tous les utilisateurs du serveur, ce qui permet souvent d'atteindre des pics de performance supérieurs à ceux garantis par un hébergement à ressources fixes. Cette flexibilité est particulièrement avantageuse pour les sites web dont la charge de travail est variable ou qui connaissent des pics de trafic ponctuels, car le système peut allouer temporairement des ressources supplémentaires pour maintenir des performances élevées. De plus, la gestion des ressources dans un environnement au mieux est optimisée pour maximiser l'efficacité globale du serveur, permettant aux sites web moins gourmands en ressources d'utiliser les ressources excédentaires laissées par d'autres, améliorant ainsi l'expérience utilisateur en termes de vitesse et de réactivité.
Avec le Cloud vous économisez car vous ne payez que ce que vous consommez.
Cette affirmation est manifestement fausse dans au moins 90 % des cas. Certes, le cloud computing fonctionne sur un modèle de paiement à l'usage plutôt que sur un forfait (les deux options existent), mais son coût est généralement au moins quatre fois supérieur à celui d'un serveur dédié. Par exemple, si vous achetez 2 vCPU et 4 Go de RAM sur Amazon LightSail (sans compter le coût du trafic sortant), vous pouvez, pour le même prix, acquérir un serveur dédié avec 12 cœurs (équivalent à 12 vCPU) et 64 Go de RAM, offrant ainsi des performances d'E/S et de bus système nettement supérieures. Le cloud offre flexibilité, évolutivité et facilité de gestion, mais ces avantages s'accompagnent souvent de coûts supplémentaires importants. De plus, les ressources cloud sont virtualisées et partagées, ce qui peut engendrer des surcharges et des limitations de performances par rapport à un serveur dédié doté de matériel physique propriétaire. Par conséquent, pour les applications exigeantes et les charges de travail élevées et constantes, les serveurs dédiés constituent une solution plus rentable et plus performante que les services cloud.
Avec le Cloud, je peux évoluer verticalement de 1 CPU à 128 CPU en un seul clic.
Cela dépend. Généralement, avec certains fournisseurs leaders du marché comme AWS, Google Cloud et Azure, cela peut s'avérer très coûteux. Le bon sens doit toujours prévaloir : acheter du cloud sans réel besoin de mise à l'échelle verticale (augmentation des ressources sur une seule instance) représente un investissement inutile pour un besoin qui ne se concrétisera jamais. Est-il judicieux d'investir des sommes importantes dans les performances de base simplement parce que nous pourrions avoir besoin de faire évoluer notre infrastructure à l'avenir ? La réponse est subjective et dépend de l'analyse d'événements spécifiques (pics de trafic, slashdotting, Black Friday, etc.). Il est essentiel d'évaluer soigneusement les besoins actuels et futurs de votre infrastructure et de déterminer si le surcoût du cloud, avec sa capacité d'adaptation rapide, justifie l'investissement par rapport à des solutions plus statiques et traditionnelles. De plus, la mise à l'échelle verticale n'est qu'une partie de l'équation ; il est souvent plus efficace et rentable d'envisager également la mise à l'échelle horizontale (ajout d'instances) pour gérer les augmentations de charge.
Le Cloud est plus fiable qu'un Hébergement Mutualisé ou qu'un Serveur Dédié.
Cela dépend. Quel cloud ? De quel fournisseur ? Quelles technologies de virtualisation ? Quel type et modèle de SAN ? Quelles sont les procédures de sauvegarde et de reprise après sinistre ? Proposent-ils une réplication géographique entre différentes régions ? Si ce n'est pas le cas par défaut, devez-vous, en tant qu'administrateur système, la mettre en place vous-même ? Le cloud peut être infiniment moins fiable qu'un hébergement mutualisé ou un serveur dédié. Certes, une voiture a quatre roues, mais quatre roues ne font pas une voiture. La fiabilité du cloud dépend de multiples facteurs, notamment la qualité de l'infrastructure du fournisseur, la configuration des ressources, la gestion du réseau et les mesures de sécurité mises en œuvre. Par exemple, les principaux fournisseurs du marché comme AWS, Google Cloud et Azure offrent des infrastructures robustes avec des niveaux élevés de redondance et de disponibilité, mais ces services peuvent être coûteux et nécessitent une configuration minutieuse pour en tirer pleinement parti. À l'inverse, un hébergement mutualisé ou un serveur dédié bien configuré et géré peut offrir un niveau de fiabilité comparable, voire supérieur, surtout s'il est pris en charge par une équipe d'administrateurs système expérimentés qui appliquent les meilleures pratiques en matière de sécurité, de sauvegarde et de reprise après sinistre.
L'accès SSH doit être refusé car il vous expose à des risques de sécurité.
Dépend. L'accès SSH avec les privilèges utilisateur et non root, accordé dans un environnement où la politique des utilisateurs et des groupes est correcte, ne vous expose à aucun problème de sécurité. Cependant, pour un utilisateur malveillant dans un système obsolète, il pourrait s'agir d'une voie prioritaire pour procéder à une élévation de privilèges et tenter de grimper à la racine et ainsi compromettre la sécurité de l'ensemble du serveur. Disons que pour pallier l'incompétence de nombreux experts en systèmes, nous préférons ne pas accorder ce qui devrait être un droit. La sécurité de l'accès SSH peut être considérablement améliorée en utilisant des clés SSH au lieu de mots de passe, en mettant en œuvre une authentification à deux facteurs et en limitant l'accès SSH à certaines adresses IP. De plus, maintenir votre système et vos packages à jour, surveiller les journaux d'accès et appliquer des règles de pare-feu appropriées sont des mesures qui peuvent réduire davantage les risques associés à l'accès SSH.
Les hébergements doivent toujours fournir un panneau de contrôle tel que Plesk / cPanel ou similaire.
En avez-vous réellement besoin ? Ou l’accès à vos fichiers et à votre base de données MySQL vous suffit-il ? Car cPanel et Plesk sont des solutions généralistes qui peuvent engendrer des problèmes de performance et, parfois, de sécurité. Par conséquent, pour les projets d’envergure, avec un trafic important, des millions de pages vues par mois ou des millions de revenus, on recherche toujours des performances maximales, ce qui est impossible avec des panneaux de contrôle comme Plesk ou cPanel. Si, en revanche, vous recherchez une indépendance maximale, par exemple pour installer des centaines de sites de démonstration, un panneau de contrôle comme Plesk ou cPanel peut répondre à vos besoins. L’utilisation de panneaux de contrôle simplifie la gestion pour les utilisateurs moins expérimentés, mais introduit une surcharge et des vulnérabilités potentielles qui peuvent compromettre les performances et la sécurité du système. Dans les environnements à hautes performances, une configuration plus rationalisée et personnalisée est préférable, gérée directement via un accès SSH et des outils spécifiques de gestion des ressources serveur, afin de garantir un contrôle et une efficacité optimaux.
Si j'ai un site pour l'Italie, il est préférable d'avoir une adresse IP italienne dans un centre de données italien à des fins de référencement
Absolument faux. Vous vivez en 1996 ? Cette règle était peut-être valable jusqu'en 2000, mais elle est depuis largement obsolète. La plupart des sites web italiens à succès sont aujourd'hui hébergés dans des datacenters en Allemagne ou en France. On ne raisonne plus en termes de pays, mais de continents. Il est donc logique qu'un site web italien dispose d'un datacenter avec un bon ping et une faible latence en Europe. Que ce soit en Italie, aux Pays-Bas ou en France, peu importe. Ce qui compte, c'est le TTFB (Time To First Byte). Certes, un TTFB en Italie ou en Allemagne peut représenter jusqu'à 30 ms de différence, mais on ne peut parler de millisecondes qu'une fois les principaux problèmes de vitesse résolus et le TTFB ramené à au moins 100 ms. Malheureusement, de nos jours, on a tendance à choisir des systèmes en Italie qui ne sont pas optimisés, qui restent lents et dont le TTFB dépasse les 200 ms maximum recommandés par Google. Il est donc essentiel de se concentrer sur la qualité globale de l'infrastructure et l'optimisation des performances plutôt que sur la simple localisation géographique du centre de données.
CloudFlare et les CDN accélèrent le site Web.
FAUX. Du moins dans l'idée collective qui se fait de l'utilisation de CloudFlare et des CDN. Si vous avez un site italien, avec une audience européenne (revenons à la question ci-dessus), CloudFlare n'améliorera rien, il pourrait même aggraver la livraison du contenu. Si toutefois nous sommes confrontés à un site international, également accessible au niveau intercontinental, CloudFlare peut certainement être une solution viable pour réduire la latence et accélérer la livraison du contenu. De plus, il est nécessaire de préciser comment CloudFlare est configuré et la version du plan acheté, en tenant compte de la fonctionnalité CDN et de la fonctionnalité Full Page Cache qui ne sont pas synonymes et ont des finalités complètement différentes. Une configuration correcte est essentielle pour obtenir les avantages souhaités ; par exemple, l'activation de fonctionnalités telles que la mise en cache dynamique, la minification des ressources et la compression peut faire une grande différence. Ainsi, si les CDN comme CloudFlare peuvent améliorer considérablement les performances d'un site avec un trafic global, leur efficacité dépend de la configuration spécifique et du contexte d'utilisation.
Cependant, nous avons beaucoup dit et écrit sur CloudFlare dans cet article.
