A Better Web Hosting Strategy For Digital Agencies

This article is aimed at digital agencies and teams that provide web hosting as a service to their clients.

The Olden Days; Shared Servers

Traditionally you would purchase or hire one big, ready-made server and pop all your client's websites upon it. You then charge all of your clients equally for the privilege, with some minor adjustments for the amount of hard drive space or data transfer their website consumed.

This was a nice, easy way to work. You would make your money off re-selling the resource. Relatively little technical expertise was required. These were simple times.

A significant advantage to this approach, being that if one website consumed more resources than another, it did not really matter. It could "borrow" the spare resources that other websites on the same server were not using.

However, the websites that we build are becoming ever more complicated, and as such, so is the complexity of hosting them. These traditional shared servers are, by their very nature, quite restrictive. This can present problems if your dev team wants to introduce more modern workflows and processes to their code and deployment processes. Things essential to any modern dev team, such as code pipelines, automated testing and deployments etc., are not possible in a shared server environment.

Then, there is data security to think about. As the shared server will be in your name, you will have some responsibility for the data held on the servers.

Say you are hosting an out of date WordPress installation, which the client is refusing to pay to update. Inevitably the website gets hacked and a bunch of personal identifying data is leaked. It may be the client's website, but if it is on servers contracted to you, you are likely to have some responsibility in the eyes of the law and the ICO.

But, on the up-side; at least shared hosting made for easy billing. Clients would get one consistent, reliable bill from you every month/year.

Enter Cloud Computing.

For most, shared servers are just not tenable anymore. At least not without hobbling your team's technical prowess and your businesses ability to compete.

With the advent of cheaper cloud computing, it has become possible to place websites upon their very own virtual server at a cost comparable to the old shared servers. So many agencies started hosting their client's websites in cloud environments and re-billing the costs to the client.

This overcomes the restrictive nature of shared servers. But it opens the door to other issues and introduces additional complexities in terms of architecting and managing the servers. Handled well, this is good, as it's another revenue stream. Handled poorly, it can cause big headaches.

The most common headache being one of consistency (or lack there of). There are many different cloud platforms and many different ways of hosting your websites in cloud environments. Unless you have a strategy in place, you can quickly find yourself in a situation where you have various projects, architected differently across multiple cloud providers.  This will eventually and inevitably suck dev team resource and make management of the projects a nightmare.

Fixed costs are, generally speaking, not something you find in cloud environments. Cloud computing is metered, so you only pay for what you use. This means variable price, so you need to either pass the costs directly or have a convoluted pricing strategy.

And if your cloud account is still contracted in your name, the aforementioned data ownership issues have not gone away either.

A Better Way

Avoiding these pitfalls does not have to be difficult with a little bit of planning.

First, choose a cloud hosting platform and stick with it. Most cloud platforms have a certification program; put your devs through it. Then, decide on a methodology for hosting your websites on the platform, and stick with it. By doing this, you are going some way to forcing consistency in the way your developers work. This is particularly valuable in teams where you have many different projects and make it easier to cycle developers in and out of the team. In addition, it upskills your staff, and encourages them to work in a way that promotes more modern development workflows.

Next, instead of hosting your client's infrastructure in your account, have your client set up their own account on the cloud hosting platform. They create the account; they pay the bill; they "own" the infrastructure.  They pay you for your expertise to architect their server setup. You are no longer re-selling a service, but you are selling your skillset. The costs become transparent to the client. They can see exactly what they are paying for. It is an honest and transparent way of working.

By making this switch from re-selling a resource to selling a skillset, you are creating another income stream for your company; cloud architecture as a service. A revenue stream worth indefinitely more than the pocket change you make off re-selling servers.

Clients don't always listen to advice. But by having them own the account, you are forcing responsibility. If they refuse to pay for a scaleable server setup and a website falls over under demand - there is no one to blame but themselves. Likewise, if they have a data leak, after failing to upgrade out of date dependencies if it's on servers, they contract, and you have warned them. It's far easier to lay responsibility at the client's feet.

Some will say that you are relinquishing some control of the client by working like this, and it would be easier for them to switch providers. And yes, to some extent, you are. But do you want to keep a client because they feel they have no other option? If the client trusts and respects you, why would they go anywhere else? Besides, this kind of portability is a two-way street, making it much easier to fire troublesome clients whilst retaining a clean conscious that you have not left them up the creak without a paddle.

This is now the approach I encourage my clients to take. Working like this ultimately reduces hassle without reducing profitability. In teams with many clients to service, if you are consistent with how you architect these platforms, it can massively reduce workload and stress on the dev team. And ultimately, help you maintain a happier, healthier dev team. All this while reducing your liabilities, opening new revenue streams and being more transparent and open with your clients.