Table of contents of the article:
If you too have been a systems engineer since 2005, with thousands of servers under your belt and thousands of cases different from each other, you will agree with me that nowadays we really can't stand it anymore. Otherwise you might believe many urban legends that are peddled by unscrupulous salesmen and without any knowledge of the facts other than that of mere profit. Working in the IT sector has become demotivating and unrewarding, given that the market is now controlled at the top by marketing and real urban legends, spread by individuals without qualifications or experience in the systems field. These salespeople often sell miracle solutions that promise unparalleled performance and reliability, without understanding the real technical and operational needs.
Let's begin by listing the questionable claims and debunking them with logical reasoning, supporting documentation, and references. Our goal is to provide clarity and truth amidst a sea of misinformation, drawing on years of practical experience and in-depth industry knowledge . As we have new myths to add and debunk, we'll update them in this post. In doing so, we hope to contribute to greater awareness and technical expertise, helping IT professionals make informed decisions and avoid the pitfalls of deceptive marketing.
Shared hosts are slow.
First and foremost, the size of the site being hosted, how many other sites are on the same machine, and the resources being hoarded by other sites in virtual hosting on the same machine. It's safe to say that sharing hosting with other sites offers no guarantee of performance or consistency, as another site hosted on the same server could monopolize resources and affect ours as well. However, shared hosting optimized with Varnish Cache, the right caching strategies and policies, a good TTFB, and fast protocols like HTTP/3 or QUIC could be much faster and more efficient than a €1000-per-month dedicated server configured with Plesk or cPanel without any tuning or optimization. Power is nothing without control. Therefore, with the right optimizations, shared hosting can offer excellent performance, while a poorly configured dedicated server can be inefficient and slow. The key is optimization and resource management.
If a hosting on our own server is hacked, attackers can attack our site.
If a hosting service on our own server is hacked, attackers can attack our website. This scenario is highly unlikely. Nowadays, except for a few unfortunate and inexperienced individuals, all hosting providers have understood the importance of privilege separation at the process and filesystem levels. For example, using PHP-FPM (FastCGI Process Manager) allows separate management of PHP processes for each website, assigning each PHP process pool its own UID (User ID) and GID (Group ID) , ensuring that each website operates with distinct and isolated privileges. If a website hosted on our own virtual server were to be hacked today, the attacker would not have sufficient privileges to write or read our files or database, since the PHP-FPM processes associated with our website run with separate UIDs and GIDs and cannot interfere with those of other websites. The situation is different if the attacker compromises a site hosted near ours and then uses unlikely exploits to elevate maximum privileges (root). This can then compromise all the sites on the same server. However, proper configuration and continuous updates of systems and applications significantly reduce the likelihood of such exploits being successful.
Hosting with guaranteed resources is better than hosting in best effort.
Hosting with guaranteed resources is better than best-effort hosting. It depends. If you have to choose guaranteed resources (minimum and maximum) of 1 core and 1GB of RAM, always choose best-effort hosting. While you won't be guaranteed the minimum resources reserved for you, it's also clear that over 90% of the time, a best-effort solution will yield better results and greater performance than a solution with dedicated resources that aren't sufficient to properly run a website. With best-effort hosting, resources are dynamically shared among all server users, often allowing for higher performance peaks than those guaranteed by fixed-resource hosting. This flexibility is particularly advantageous for websites with variable workloads or occasional traffic spikes, where the system can temporarily allocate additional resources to maintain high performance. Additionally, resource management in a best-effort environment is optimized to maximize overall server efficiency, allowing less intensive websites to utilize excess resources left by others, thus improving the user experience in terms of speed and responsiveness.
With the Cloud you save because you only pay for what you consume.
This statement is patently false in at least 90% of real-world applications. It's true that cloud computing has a pay-per-use model rather than a flat rate model (both options exist today), but the cost of cloud computing is typically at least four times that of a dedicated server. For example, if you buy 2vCPUs and 4GB of RAM on Amazon LightSail (plus the cost of egress traffic), for the same price you can purchase a dedicated server with 12 threads (equivalent to 12vCPUs) and 64GB of RAM, with obviously higher I/O and system bus performance. The cloud offers flexibility, scalability, and ease of management, but these features often come with significant additional costs. Furthermore, cloud resources are virtualized and shared, which can introduce overhead and performance limitations compared to a dedicated server with proprietary physical hardware. Therefore, for high-performance applications and consistently high workloads, dedicated servers represent a more cost-effective and high-performance solution than cloud services.
With the Cloud I can scale vertically from 1 CPU to 128 CPU with just one click.
It depends. Typically, with some top market providers like AWS, Google Cloud, and Azure, this can be done at rather prohibitive costs. Common sense should always reign supreme; if we buy the cloud without a real need for vertical scaling (increasing resources on a single instance), we're making a wasteful investment for something that will never happen. Does it make sense to spend significant amounts on basic performance just because we might need to scale in the future? The answer is subjective and depends on the common sense of analyzing specific events (traffic spikes, slashdotting, Black Friday), etc. It's important to carefully evaluate your infrastructure's current and future needs and consider whether the additional cost of the cloud, with its ability to scale rapidly, justifies the investment compared to more static and traditional solutions. Furthermore, vertical scaling is only part of the equation; it's often more efficient and cost-effective to also consider horizontal scaling (adding more instances) to handle increased loads.
The Cloud is more reliable than a Shared Hosting or a Dedicated Server.
It depends. Which cloud? From which company? What virtualization technologies? What type and model of SAN? What backup and disaster recovery procedures? Do they provide geographic replication across different regions? If they don't do it by default, do you, as a system administrator, do it yourself? The cloud could be infinitely less reliable than shared hosting or a dedicated server. It's true that cars have four wheels, but it's not true that four wheels make a car. The reliability of the cloud depends on multiple factors, including the quality of the provider's infrastructure, resource configuration, network management, and implemented security measures. For example, top market providers like AWS, Google Cloud, and Azure offer robust infrastructures with high standards of redundancy and availability, but these services can be expensive and require careful configuration to fully leverage their benefits. Conversely, shared hosting or a well-configured and managed dedicated server can offer a comparable or superior level of reliability, especially when supported by a team of experienced system administrators who implement best practices in terms of security, backup, and disaster recovery.
SSH access must be denied because it exposes you to security risks.
Depends. SSH access with user and non-root privileges, granted in an environment where user and group policy is correct, does not expose you to any security problems. However, for a malicious user in an outdated system, it could be a priority path to proceed with privilege escalation and attempt to climb to root and therefore compromise the security of the entire server. Let's say that to overcome the incompetence of many systems experts, we prefer not to grant what should be a right. SSH access security can be significantly improved by using SSH keys instead of passwords, implementing two-factor authentication, and limiting SSH access to certain IP addresses. Additionally, keeping your system and packages updated, monitoring access logs, and applying appropriate firewall rules are measures that can further reduce the risks associated with SSH access.
Hostings must always provide a control panel such as Plesk / cPanel or similar.
Do you really need it? Or is access to your files and MySQL database enough? Because cPanel and Plesk are general-purpose solutions that bring significant performance and, occasionally, security issues. Therefore, on serious projects, with significant traffic, millions of page views per month, or millions in revenue, you always strive for maximum performance, and maximum performance isn't achievable with panels like Plesk or cPanel. If, however, you're looking for maximum independence, perhaps to install hundreds of showcase sites, a control panel like Plesk or cPanel could be the solution to your independence issues. Using control panels simplifies management for less experienced users, but introduces overhead and potential vulnerabilities that can compromise system performance and security. In high-performance environments, a more streamlined and customized configuration is preferred, managed directly via SSH access and specific server resource management tools, to ensure maximum control and efficiency.
If I have a site for Italy it is better to have an Italian IP in an Italian datacenter for SEO purposes
Definitely false. What era are you living in, the dawn of 1996? This rule may have been valid until the year 2000, but has since been largely superseded. Most successful Italian websites today are located in datacenters in Germany or France. Today, we no longer think in terms of countries, but rather continents. It's therefore correct for an Italian website to have a datacenter with good ping and low latency in Europe. Whether in Italy, the Netherlands, or France, it doesn't matter. What matters is the TTFB (Time To First Byte), and while it's true that a TTFB in Italy or Germany can make a difference of up to 30 ms, we can only start talking about milliseconds once we've at least resolved the major speed issues and brought the TTFB down to at least 100 ms. Unfortunately, nowadays, we tend to choose systems in Italy that aren't optimized, which are still slow and with TTFBs higher than the maximum 200 ms recommended by Google. Therefore, it is essential to focus on the overall quality of the infrastructure and performance optimization rather than simply the geographical location of the datacenter.
CloudFlare and CDNs speed up the website.
False. At least in the collective idea that is made of the use of CloudFlare and CDNs. If you have an Italian site, with a European audience (let's go back to the question above), CloudFlare won't improve anything, in fact it could even worsen the delivery of content. If, however, we are faced with an international site, also accessed at an intercontinental level, CloudFlare can certainly be a viable solution in reducing latency and accelerating the delivery of content. Furthermore, it is necessary to specify how CloudFlare is configured and the version of the plan purchased, taking into account the CDN functionality and the Full Page Cache functionality which are not a synonym and have completely different purposes. Correct configuration is essential to obtain the desired benefits; for example, enabling features like dynamic caching, resource minification, and compression can make a big difference. So, while CDNs like CloudFlare can significantly improve the performance of a site with global traffic, their effectiveness depends on the specific configuration and context of use.
However, we have said and written a lot about CloudFlare in this article.
