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 donc par énumérer celles qui sont des déclarations douteuses et réfutons la déclaration avec un raisonnement logique et la documentation et les références associées. Notre objectif est d'apporter clarté et vérité dans un océan de désinformation, en nous appuyant sur des années d'expérience pratique et une connaissance approfondie du secteur.. Comme nous avons de nouveaux mythes à ajouter et à démystifier, nous les publierons mis à jour dans cet article. Ce faisant, nous espérons contribuer à une plus grande sensibilisation et à une plus grande expertise technique, en aidant 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.
Principalement par la lourdeur du site à héberger, par le nombre d'autres sites présents sur la même machine et par les ressources thésaurisées par les autres sites en hébergement virtuel sur la même machine. Il est clair que le partage d'hébergement avec d'autres sites ne donne pas de garanties quant aux performances et à la cohérence des performances, étant donné qu'un autre site hébergé sur le même serveur que nous pourrait monopoliser les ressources et faire souffrir les nôtres également. Toutefois, un hébergement mutualisé optimisé avec Varnish Cache, des stratégies et politiques de mise en cache adaptées, un bon TTFB, des protocoles rapides comme HTTP/3 ou QUIC pourraient être bien plus rapides et efficaces qu'un serveur dédié à 1000 € par mois configuré avec Plesk ou cPanel ci-dessus sans aucun réglage ni optimisation. Le pouvoir n’est rien sans contrôle. Ainsi, avec les bonnes optimisations, l’hébergement mutualisé peut offrir d’excellentes performances, tandis qu’un serveur dédié mal configuré peut être 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 un hébergement sur notre propre serveur est piraté, des attaquants peuvent attaquer notre site. Ce scénario est hautement improbable. De nos jours, à l'exception de quelques malheureux et improvisés, tous les hébergeurs 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, en attribuant à chaque pool de processus PHP son propre UID (User ID) et GID (Group ID)., garantissant que chaque site Web fonctionne avec des privilèges distincts et isolés. S'il casse aujourd'hui le site hébergé en hébergement virtuel sur notre propre serveur, l'attaquant n'a pas les privilèges suffisants pour pouvoir écrire/lire nos fichiers ou notre base de données, puisque les processus PHP-FPM associés à notre site fonctionnent avec UID et GID distincts et ne peuvent interférer avec ceux des autres sites. La situation est différente dans laquelle l'attaquant perce le site hébergé près du nôtre et procède ensuite à des exploits improbables pour élever les privilèges maximum (root), auquel cas il peut compromettre tous les sites sur le même serveur. Cependant, une configuration appropriée et une mise à jour continue des systèmes et des applications réduisent considérablement les chances de réussite de tels exploits.
L'hébergement avec des ressources garanties est préférable à l'hébergement au mieux.
L’hébergement avec des ressources garanties est meilleur que l’hébergement au mieux. Dépend. Si vous devez choisir d'avoir des ressources garanties (minimum et maximum) de 1 cœur, 1 Go de RAM, préférez toujours un hébergement au mieux. Il est vrai que vous n'aurez aucune garantie sur les ressources minimales qui vous sont réservées, mais il est également vrai que pour plus de 90% la solution au meilleur effort produira de meilleures valeurs et de meilleures performances qu'une solution avec des ressources dédiées mais insuffisantes pour gérer correctement un site. Dans le cadre d'un hébergement au mieux, les ressources sont partagées dynamiquement entre tous les utilisateurs du serveur, permettant souvent de bénéficier de pics de performances supérieurs à ce qui est garanti par un hébergement à ressources fixes. Cette flexibilité est particulièrement bénéfique pour les sites présentant des charges de travail variables ou des pics de trafic occasionnels, où 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 de meilleur effort est optimisée pour maximiser l'efficacité globale du serveur, permettant aux sites Web moins intensifs 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.
Déclaration clairement fausse dans au moins 90 % des utilisations réelles. Il est vrai que le Cloud a un modèle de paiement à l'utilisation plutôt qu'un modèle Flat (aujourd'hui les deux options existent), mais le coût du Cloud est normalement quatre fois (minimum) par rapport à la même solution sur un serveur dédié. Pour être clair, où sur Amazon LightSail vous achetez 2vCPU et 4 Go de RAM (auxquels s'ajoutent les coûts du trafic sortant), avec le même coût vous pouvez acheter un serveur dédié avec 12 threads (équivalent à 12vCPU) et 64 Go de RAM, avec performances à un niveau évidemment plus élevé d’E/S et de bus système. Le cloud offre flexibilité, évolutivité et facilité de gestion, mais ces fonctionnalités entraînent souvent des coûts supplémentaires importants. De plus, les ressources cloud sont virtualisées et partagées, ce qui peut introduire des surcharges et des limitations de performances par rapport à un serveur dédié doté d'un matériel physique unique. Donc, pour les applications hautes performances et les charges de travail constamment élevées, je Serveurs Dédiés ils représentent une solution plus économique et plus performante par rapport aux services cloud.
Avec le Cloud, je peux évoluer verticalement de 1 CPU à 128 CPU en un seul clic.
Dépend. Normalement chez certains fournisseurs phares du marché comme AWS, Google Cloud et Azure, il est évidemment possible de le faire avec des coûts plutôt prohibitifs. Le bon sens devrait toujours régner en maître ; si nous achetons le Cloud sans réel besoin de mise à l'échelle verticale (augmentation des ressources sur une seule instance), nous faisons une dépense inutile pour un événement qui n'arrivera jamais. Est-il judicieux de dépenser de grosses sommes d’argent pour des performances de base, simplement parce que nous devrons peut-être évoluer à l’avenir ? La réponse est subjective et réside dans le bon sens de l’analyse d’événements particuliers (pics de trafic, effet slashdotting, black friday) etc. Il est important d’évaluer soigneusement les besoins actuels et futurs de votre infrastructure et de déterminer si le coût supplémentaire du cloud, avec sa capacité à évoluer rapidement, justifie l’investissement par rapport à des solutions traditionnelles plus statiques. De plus, l’évolutivité verticale n’est qu’une partie de l’équation ; il est souvent plus efficace et plus rentable d'envisager également l'évolutivité horizontale (ajout de plus 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é.
Dépend. Quel Cloud ? De quelle entreprise ? Quelles technologies de virtualisation ? Quel type et modèle de SAN ? Quelles procédures de sauvegarde et de reprise après sinistre ? Font-ils des répliques géographiques sur différentes régions ? S'ils ne les font pas par défaut, les faites-vous en tant qu'administrateur système ? Le Cloud pourrait être infiniment moins fiable qu’un hébergement mutualisé ou un serveur dédié. Il est vrai que les voitures ont 4 roues, mais il n’est pas vrai que 4 roues déterminent une voiture. La fiabilité du cloud dépend de multiples facteurs, parmi lesquels 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é tels qu'AWS, Google Cloud et Azure proposent des infrastructures robustes avec des normes élevées de redondance et de disponibilité, mais ces services peuvent avoir des coûts élevés et nécessiter une configuration minutieuse pour exploiter pleinement leurs avantages. Au contraire, un hébergement mutualisé ou un serveur dédié bien configuré et géré peut offrir un niveau de fiabilité comparable ou supérieur, surtout s'il est soutenu par une équipe d'ingénieurs systèmes experts qui mettent en œuvre les meilleures pratiques en termes 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 vraiment besoin? Ou avez-vous simplement besoin d’accéder à vos fichiers et à votre base de données MySQL ? Parce que cPanel et Plesk sont des solutions à usage général qui entraînent des problèmes de performances importants et parfois de sécurité. Donc, sur des projets sérieux, où il y a du trafic réel, des millions de pages vues par mois ou des millions de chiffre d'affaires, on essaie toujours d'obtenir un maximum de performances, et des performances maximales ne sont pas atteignables avec des panels comme Plesk ou cPanel. Cependant, si vous recherchez une indépendance maximale, peut-être pour installer des centaines de sites vitrines, un panneau de contrôle comme Plesk ou cPanel pourrait être la solution à vos problèmes d'indépendance. L'utilisation de panneaux de contrôle simplifie la gestion pour les utilisateurs moins expérimentés, mais introduit des frais généraux 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 l'accès SSH et des outils spécifiques de gestion des ressources du serveur, pour garantir un contrôle et une efficacité maximum.
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
Certainement faux. À quelle époque vivez-vous, à l’aube de 1996 ? Cette règle aurait pu être valable jusqu’en 2000, puis elle a été largement remplacée. Les sites italiens les plus performants aujourd'hui sont situés dans des centres de données en Allemagne ou en France. Aujourd’hui, nous ne pensons plus en termes de pays, mais plutôt en termes de continents. Il est donc correct qu'un site italien dispose d'un data center avec un bon ping et une faible latence en Europe. Que ce soit en Italie, aux Pays-Bas, en France, cela n'a pas d'importance. Ce qui compte c'est le TTFB (Time To First Byte) et, s'il est vrai qu'un TTFB en Italie ou en Allemagne peut faire une différence même de 30 ms, on ne peut commencer à parler de millisecondes que lorsque les gros problèmes de vitesse ont amené le TTFB à au moins en dessous de 100 ms. De nos jours, malheureusement, nous avons tendance à choisir en Italie des systèmes non optimisés qui sont encore lents et avec un TTFB supérieur aux 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 data center.
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.
