Table des matières de l'article :
Si vous aussi vous avez été ingénieur système dans votre vie depuis 2005, avec des milliers de serveurs et des milliers de boitiers 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 servies par des commerciaux peu scrupuleux et sans aucune connaissance de la cause si ce n'est celle du simple profit.
Travailler dans le secteur informatique est devenu démotivant et peu gratifiant étant donné que le marché est désormais dominé par le marketing et par de véritables légendes urbaines, divulguées par des individus sans qualification ni expérience dans le domaine des systèmes.
Commençons donc par énumérer les affirmations douteuses et rejetons l'affirmation avec un raisonnement logique et la documentation et les références connexes.
Comme nous avons de nouveaux mythes à ajouter et à réfuter, nous les publierons mis à jour dans cet article.
Les hôtes partagés sont lents.
Ça dépend. Tout d'abord par la lourdeur du site à héberger, par le nombre d'autres sites sur la même machine, et par les ressources accaparées par les autres sites en hébergement virtuel sur la même machine. Il est incontestable que le partage d'un hébergement avec d'autres sites ne donne aucune garantie quant aux performances et à la constance des performances, étant donné qu'un autre site hébergé sur notre même serveur pourrait accaparer les ressources et faire également souffrir les nôtres.
Si un hébergement sur notre propre serveur est piraté, des attaquants peuvent attaquer notre site.
Peu probable. De nos jours, hormis 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 des systèmes de fichiers. Si aujourd'hui ils percent le site hébergé en hébergement virtuel sur notre propre serveur, l'attaquant n'a pas le privilège suffisant pour pouvoir écrire/lire nos fichiers ou notre base de données.
La situation est différente dans laquelle l'attaquant troue le site hébergé près du nôtre et procède ensuite à des exploits improbables jusqu'à l'élévation des privilèges maximum (root), auquel cas il peut compromettre tous les sites sur le même serveur.
L'hébergement avec des ressources garanties est préférable à l'hébergement au mieux.
Ça dépend. Si vous devez choisir d'avoir des ressources garanties (minimum et maximum) de 1 cœur, 1 Go de RAM, privilégiez toujours l'hébergement au mieux. Il est vrai que vous n'aurez pas de garanties sur les ressources minimales qui vous sont réservées, mais il est aussi paisiblement vrai que pour plus de 90% la solution best effort produira de meilleures valeurs et des performances plus élevées qu'une solution avec des ressources dédiées mais insuffisantes pour exécuter un site correctement.
Avec le Cloud vous économisez car vous ne payez que ce que vous consommez.
Évidemment fausse déclaration 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 réellement), 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, là où sur Amazon LightSails vous achetez 2vCPU et 4Go de RAM (auxquels vous ajoutez les frais de trafic sortant), vous achetez 1 Serveur Dédié avec 12 threads (équivalent à 12vCPU) et 64Go de RAM avec le même coût, avec niveau performances évidemment supérieures I/O et bus système.
Avec le Cloud, je peux évoluer verticalement de 1 CPU à 128 CPU en un seul clic.
Ça dépend. Normalement avec certains top fournisseurs du marché AWS, Google Cloud, Azure, il est évidemment possible de faire cela avec des coûts plutôt prohibitifs. Le bon sens doit toujours régner en maître, si on achète le Cloud sans réel besoin de scaling vertical (augmenter les ressources sur une seule instance) on fait une dépense inutile pour un événement qui n'arrivera jamais.
Est-il logique de dépenser de grosses sommes pour des performances de base, simplement parce que peut-être qu'à l'avenir nous aurions besoin de grimper ? La réponse est subjective et réside dans le bon sens d'analyser des événements particuliers (pics de trafic, effet slashdotting, black friday) etc.
Le Cloud est plus fiable qu'un Hébergement Mutualisé ou qu'un Serveur Dédié.
Ça dépend. Quel Nuage ? Quelle compagnie? Quelles technologies de virtualisation ? Quel type et modèle de SAN ? Quelles procédures de sauvegarde et de reprise après sinistre ? Est-ce que les répliques géographiques sur différentes régions y parviennent ? 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.
L'accès SSH doit être refusé car il vous expose à des risques de sécurité.
Ça dépend. L'accès SSH avec des privilèges utilisateur et non root, accordé dans un environnement où la politique sur les utilisateurs et les groupes est correcte, ne pose aucun problème de sécurité. Cependant, pour un utilisateur malveillant dans un système obsolète, il pourrait être prioritaire de procéder à une élévation des privilèges et de tenter de monter à la racine et donc de compromettre la sécurité de l'ensemble du serveur. Disons que pour remédier à l'incompétence de nombreux ingénieurs systèmes, nous préférons ne pas accorder ce qui devrait être un droit.
Les hébergements doivent toujours fournir un panneau de contrôle tel que Plesk / cPanel ou similaire.
Ça dépend. En avez-vous vraiment besoin? Ou simplement accéder à vos fichiers et 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 très importants et parfois même de sécurité. Par conséquent, sur des projets sérieux, où circulent du trafic réel, des millions de pages vues par mois ou des millions de chiffre d'affaires, nous essayons toujours d'obtenir le rendement maximal, et le rendement maximal n'est pas obtenable avec des panneaux comme Plesk ou cPanel. Si au contraire 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.
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
Faux. Assurément faux. A quelle époque vivez-vous, à l'aube de 1996 ? Cette règle était valable jusqu'en l'an 2000, puis elle a été largement supplantée. La plupart des sites italiens qui réussissent 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 de continents. Il est donc correct pour un site italien d'avoir un datacenter avec un bon ping et une faible latence en Europe. Que ce soit en Italie, en Hollande, en France, peu importe.
CloudFlare et les CDN accélèrent le site Web.
Faux. Du moins dans l'idée collective d'utiliser CloudFlare et les CDN. Si vous avez un site italien, avec une audience européenne (revenons à la question ci-dessus), CloudFlare n'améliorera rien, en effet cela pourrait même aggraver la livraison de contenu. Si, en revanche, nous sommes confrontés à un site international, également accessible au niveau intercontinental, CloudFlare peut certainement être une solution appropriée pour réduire la latence et accélérer la livraison de contenu.
Cependant, nous avons beaucoup dit et écrit sur CloudFlare dans cet article.
