This blog post of mine is not going to be a rant against the shared hosting, but logically I am going to dissect why the shared hosting should be a NO go zone when you have or desire a serious online presence.

If you or your business or what you represent, is either an institution like a school, college or hospital or your website is an e-commerce website or your website or app handles essential functional aspects like CRM ( Customer Relation Management or billing ) or your website needs to have the least downtime, shared hosting will fail you one day or the other.

The shared hosting business model may be good for the shared hosting provider, it is the consumer like you who ultimately would get a raw deal. Ler me elaborate my views in points

1. Shared hosting is a numbers game and you are just one number.

Most shared hosting or cheap hosting buyers may not be aware how the shared hosting business model works. A typical provider will setup the infrastructure at a cost of $$$$$, and then give access to chunks of it at a fraction of the running cost. You might think that I have got unlimited storage or may be 100 GB storage or unlimited features etc., but then everybody using that infrastructure is getting the same unlimited items. A question must arise that when the infrastructure is running on the real hardware, then how the features such as unlimited storage work!!! The answer to it is that the word ‘unlimited’ is the so called ‘max-capacity’ but again it comes with its own caveats. Those caveats would very likely be elaborated in the provider’s TOS ( terms or service ) or SLA ( service level agreement ).

Now lets come to the numbers part. To recover the cost of infrastructure, a typical shared hosting provider may have to provision 500 to 1500 accounts on a single machine to earn some decent profit. These accounts may have multiple websites (addons and sub-domains), therefore the number of sites on that infrastructure will typically be 1.25x to 2x of that number. Now your dear website is just a part of that list of websites running on their infrastructure.

2. Resource utilization- the eternal struggle

All these websites do need physical resources to work and perform. And CPU process or tasks involve – RAM utilization, CPU time slice, disk I/O (input and output) operations. When you purchase a laptop, you are able to appreciate the importance of these aspects. But we forget that a website is again dependent on these same resources. Before CloudLinux arrived at the scene, it was very difficult for the service providers to control these limits on per user basis. The sysadmins had to come with innovative ways to deal with this scenario and many a times had to cancel/move the offending users whose processes were causing performance degradation. With the arrival of CloudLinux, the sysadmins were able to set specific maximum limits. But still it does not solve the whole issue. Now say there are 1000 users on a server, and even if 100 are currently active, their combined resource usage can easily overwhelm the server and thus leading to performance degradation.

Currently shared hosting providers have set low limits like 1 GB RAM, 20 EP (entry processes) in order to ensure that the whole setup works. But practically from my own experience I have seen that a website even with moderate traffic will soon breach these limits and a 503 error will be shown to the visitors.

In practice, the performance of the website is sacrificed to keep the whole setup properly running. We cannot fault the service providers for this situation. Ultimately a customer gets what he pays for. But some advanced readers may say that we can answer all these problems by caching. But it is not that simple as elaborated in the next point.

3. Caching and still the website is slow.

Most users who have run their websites for 2-3 years will come across or implement the advice of caching. There is no denying the fact that caching content on the server side does indeed help. Converting the content generated by a PHP or WordPress script to a plain HTML, can easily boost the performance to 10x to 20x. But still it does not always work and will fail totally fail in certain scenarios.

Implementation of cache requires some advanced knowledge and know how. I know several WordPress admins would disagree to it. but let me explain what I mean by it. Here we would take WordPress for the example implementation as it powers more than 40% of all the websites. Under WordPress you can find tons of caching and speed boost plugins. And also it is pretty easy to install and enable any one of those plugins. But now comes the part which does require some advance knowledge. It is how you tweak to setup the plugin for the best performance. For e.g. if you take W3 Total Cache, it has so many options that practically most WordPress admins are not able to get it to work optimally in their first attempt. You need to go through its documentation in order to extract best from it.

Ok now you have properly implemented the caching plugin. But still you find that some pages are never getting cached. The reason for that is that the caching mechanism bypasses cache if a cookie or session is set. This typically happens on e-commerce websites or on any website/page which involves visitor interaction whereby only the visitor specific content can be shown. But why is it happening? The answer for it is the database or MySQL. Elaborated further in the next point.

4. Database or MySQL – the achilles heel of performance.

Database engine, whether MySQL or MariaDB (an offshoot of MySQL) probably play the most important role in performance and may also be the most difficult to resolve in a shared hosting scenario.

The reason for the same is the hosting management control panel i.e. cPanel/WHM . Most providers are using cPanel/WHM as a servicing platform. This author has not been able to find the feature whereby a MySQL’s user limit can be set on per MySQL user basis. Though natively from within MySQL and MariaDB it is possible, but practically using cPanel/WHM it cannot be achieved.

The biggest downside of it is that even when limits are imposed on user’s system processes, the way the same processes interact with MySQL cannot be controlled, leading to a situation where a website with low resource limits able to put more load on MySQL server than what is desired.

A database engine like MySQL works as a single process (with multiple threads), and it begins to consume the maximum CPU time and the RAM. In the process it negatively impacts other processes which are vying with MySQL for their share of CPU and RAM. In nutshell whole system becomes slow and leads to performance degradation.

For an e-commerce website or a billing system or a CRM, their performance falls below what is desired by the website owner.

5. Security – a complex issue

Most shared hosting setups today use cPanel/WHM with CloudLinux. Shared hosting customers would very likely be aware of the cPanel, but it is the CloudLinux, which needs to be additionally installed on a server, provides the base for a relatively secure setup. CloudLinux via CageFS provides user level isolation which prevents security vulnerabilities of one user account from impacting the other user accounts and/or the whole server. But it does not help prevent security issues of a sub-domain(s) or an addon website, within the same account from impacting the whole account.

So if a user wanted better security for his multiple websites or sub-domains, he would simply buy a reseller plan which were offered at attractive pricing. This was the ideal scenario till June, 2019 as thereafter cPanel implemented per account pricing. The per account cPanel pricing typically costs around USD 3.5 to USD 5 per account per year. Because of this customers have been disincentivized to go for separate accounts. Also many hosting companies started offering plans where multiple addons could be added in a single account. Now this is not good for security. If a single user account is running 4-5 websites under his/her account, and if those websites are not being updated or maintained, a security vulnerability even in a single website can totally compromise his user account.

Therefore the pricing dynamics of shared hosting setup does not lead to the best practices.

6. New technologies and shared hosting do not gel well.

Shared hosting setups have their origin in PERL/PHP era beginning in early 2000. Though both PERL and PHP still remain relevant even today, but with emerging technologies like NodeJS, new demands and expectations have been put on the current setups.

If we were to talk of NodeJS, though from within cPanel, NodeJS is supported natively and also via CloudLinux, still we have found developers struggling to implement the same the ideal way. The emergence of these technologies is one of the reasons why the demand for Cloud/VPS services has expanded.

Were we to put DevOps in this mix, Cloud/VPS services has even higher demand. It is no surprise that AWS ( Amazon Web Services ) revenue surpasses the revenue of the largest shared hosting provider.

7. Compliance and the single IP.

The very nature of shared hosting puts it on the verge of breaking point of compliances which are necessiated in todays complex digital landscape. A hosting provider has to deal with various level of abuse/complaints – phishing, spam, IP blacklisting, intellectual and copyright law, DMCA notices etc. Because everything is running on the same IP address, any violation invites a ticket or an explanation from the upstream provider. If there is no requisite action by the service provider or a delayed action, the upstream provider can put the IP or the infrastructure offline. Now just imagine how many websites can go offline if such a thing were to happen.

You or your website may be compliant, but in shared hosting it does not matter. What is required is the compliance of the whole setup.

Therefore the trend now is to have your website(s) on a separate Cloud/VPS, of-course with its own IP address.

8. Shared hosting provider support – mostly below average

For any account or a website provisioned online, you would sometime or the other would need to get in touch with a support personnel. Now when it comes to shared hosting, you would most likely get automated or canned responses. The specific response or resolution is not easy to come by in a shared hosting scenario. You may be paying $ a year for your shared hosting, but the support staff needs to be paid $$$ per month. Therefore a staff of few may very well be managing 1000s of clients and websites. This leads to delayed response and resolution.

If you go for a Cloud/VPS you can get much better service as you are paying $$ per month.

9. Disaster recovery management and timelines.

Here I would like to stress that most established shared hosting providers would very likely have a disaster recovery management plan. Let me define what I mean by disaster – hard-disk crash, hardware burnout, inadvertent or clerical mistakes by staff, a security issue impacting the whole infrastructure or a natural calamity

Here, even a well established provider with a good disaster recovery plan, can take a few days if not weeks to bring the things back to normal. The deluge of calls and support requests when recovering a shared hosting infrastructure can easily overwhelm a provider whereby they may seem unresponsive to you, but in reality maybe trying hard to bring things back to normal.

Whereas if you had a Cloud/VPS setup, it would definitely be a shorter timeline depending again upon how well disaster recovery is planned.

Conclusion : Here I would like to wrap this write-up. The trend is very clear. Most businesses and institutions have much higher expectations from their websites or their online assets. Shared hosting can never fulfill this requirement. The trend in recent years have been a shift over to the Cloud/VPS infrastructure. Even many shared hosting providers are slowly transitioning to Cloud/VPS providers and some have even stopped offering shared hosting services.

Shared hosting is only good if you are running your website in a casual way and where it does not matter whether its online or offline.