Dissipons les mythes les plus populaires sur l'hébergement, le cloud et les serveurs dédiés - 🏆 Managed Server

BLOG

23 juin 2022

Dissipons les mythes les plus populaires sur l'hébergement, le cloud et les serveurs dédiés

Quels sont les mythes les plus populaires sur les solutions d'hébergement qui sont souvent racontés ? Découvrons ensemble.

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.

 

Vous avez des doutes ? Vous ne savez pas par où commencer ? Contactez-nous !

Nous avons toutes les réponses à vos questions pour vous aider à faire le bon choix.

Discute avec nous

Discutez directement avec notre support avant-vente.

0256569681

Contactez-nous par téléphone pendant les heures de bureau 9h30 - 19h30

Contactez-nous en ligne

Ouvrez une demande directement dans l'espace contact.

INFORMATIONS

Managed Server Srl est un acteur italien leader dans la fourniture de solutions système GNU/Linux avancées orientées vers la haute performance. Avec un modèle d'abonnement peu coûteux et prévisible, nous garantissons que nos clients ont accès à des technologies avancées en matière d'hébergement, de serveurs dédiés et de services cloud. En plus de cela, nous proposons des conseils système sur les systèmes Linux et une maintenance spécialisée en SGBD, sécurité informatique, Cloud et bien plus encore. Nous nous distinguons par notre expertise dans l'hébergement de CMS Open Source de premier plan tels que WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart et Magento, soutenus par un service d'assistance et de conseil de haut niveau adapté aux administrations publiques, aux PME et à toutes tailles.

Red Hat, Inc. détient les droits de Red Hat®, RHEL®, RedHat Linux® et CentOS® ; AlmaLinux™ est une marque commerciale d'AlmaLinux OS Foundation ; Rocky Linux® est une marque déposée de la Rocky Linux Foundation ; SUSE® est une marque déposée de SUSE LLC ; Canonical Ltd. détient les droits sur Ubuntu® ; Software in the Public Interest, Inc. détient les droits sur Debian® ; Linus Torvalds détient les droits sur Linux® ; FreeBSD® est une marque déposée de The FreeBSD Foundation ; NetBSD® est une marque déposée de la Fondation NetBSD ; OpenBSD® est une marque déposée de Theo de Raadt. Oracle Corporation détient les droits sur Oracle®, MySQL® et MyRocks® ; Percona® est une marque déposée de Percona LLC ; MariaDB® est une marque déposée de MariaDB Corporation Ab ; REDIS® est une marque déposée de Redis Labs Ltd. F5 Networks, Inc. détient les droits sur NGINX® et NGINX Plus® ; Varnish® est une marque déposée de Varnish Software AB. Adobe Inc. détient les droits sur Magento® ; PrestaShop® est une marque déposée de PrestaShop SA ; OpenCart® est une marque déposée d'OpenCart Limited. Automattic Inc. détient les droits sur WordPress®, WooCommerce® et JetPack® ; Open Source Matters, Inc. détient les droits sur Joomla® ; Dries Buytaert détient les droits sur Drupal®. Amazon Web Services, Inc. détient les droits sur AWS® ; Google LLC détient les droits sur Google Cloud™ et Chrome™ ; Microsoft Corporation détient les droits sur Microsoft®, Azure® et Internet Explorer® ; La Fondation Mozilla détient les droits sur Firefox®. Apache® est une marque déposée de The Apache Software Foundation ; PHP® est une marque déposée du groupe PHP. CloudFlare® est une marque déposée de Cloudflare, Inc. ; NETSCOUT® est une marque déposée de NETSCOUT Systems Inc. ; ElasticSearch®, LogStash® et Kibana® sont des marques déposées d'Elastic NV. Hetzner Online GmbH détient les droits sur Hetzner® ; OVHcloud est une marque déposée d'OVH Groupe SAS ; cPanel®, LLC détient les droits sur cPanel® ; Plesk® est une marque déposée de Plesk International GmbH ; Facebook, Inc. détient les droits sur Facebook®. Ce site n'est affilié, sponsorisé ou autrement associé à aucune des entités mentionnées ci-dessus et ne représente en aucune manière aucune de ces entités. Tous les droits sur les marques et noms de produits mentionnés sont la propriété de leurs titulaires respectifs des droits d'auteur. Toutes les autres marques mentionnées appartiennent à leurs titulaires. MANAGED SERVER® est une marque déposée au niveau européen par MANAGED SERVER SRL, Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italie.

JUSTE UN MOMENT !

Souhaitez-vous voir comment votre WooCommerce fonctionne sur nos systèmes sans avoir à migrer quoi que ce soit ? 

Entrez l'adresse de votre site WooCommerce et vous obtiendrez une démonstration navigable, sans avoir à faire absolument quoi que ce soit et entièrement gratuite.

Non merci, mes clients préfèrent le site lent.
Retour en haut de page