Hosting part 3: virtual servers?

Virtualisation is the process of taking a physical computer and dividing it up so that it thinks it has lots of computers inside it, each doing different things completely unrelated to each other. Why is this useful? Because you could either take on a small bit of someone else's real computer without the cost of buying your own, and with the security that comes with having your own, or you could divide up a computer that you already have into smaller chunks to do different things with each chunk.

When it comes to hosting a website, a lot of the time, the server is sitting there doing very little, so it’s almost wasted space in a way. To get the computer working harder, you can make it do more things, but what then happens if those more things conflict with each other somehow? Or you’re using some common parts and someone changes the configuration for one site, and it then breaks all the others! It happens.

Virtualisation is the answer to this - each virtual machine (sometimes known as a virtual private server, or VPS) has its own memory, it’s own drive space, its own applications and even its own operating system. People who have access to one don’t necessarily have access to any others on the same machine

If you’re looking for a solution for a website that is going to have a super heavy load, virtualisation might not cut it for you, unless you decide to create a virtual server farm and dish out the work to different virtual machines. However, for the vast majority of websites, this isn’t the case, and virtualisation could suit the needs of protection of data, and separation that can cause so many problems in other cases.

With respect then to virtualisation, the options available are usually something along the lines of:

The latter of those two options can be further divided up, as big companies like SliceHost, Amazon, EngineYard and so on provide virtualisation in different ways. Amazon uses virtualisation to provide their EC2 cloud computing platform, where slice host and engine yard provide what they call “slices”; in reality just virtual machines on a larger real machine.

At Initforthe, we’ve been using virtual servers for some time to provide our clients with hosting and have built up our own centrally managed platform. Of course, our options aren’t the only solution, but they do offer our clients a way in which everything to do with a given web build can come from one place. Saying that though, we recently embarked on a project that was set to use the entire swathe of Amazon Web Services provided services: EC2 for computing, S3 for storage, and their newly released EBS to store the database on). What we found is that the reality of virtualisation doesn’t always pare up with what is sold in… OK, that’s not true in a lot of cases - SliceHost and EngineYard have impeccable records, and our servers have shown very little downtime themselves. Amazon was a slightly different story though.

Whilst developing the EC2 instances and installing the applications on them, we found that they were rebooting almost randomly, and the access to EBS (the database storage facility) was flaky. You can’t have a website which is up some of the time and not all of it, and you certainly can’t have it go down because your machines can’t access the database any more. To finish this off, we then discovered that actually EC2 had no SLA (Service Level Agreement) to maintain uptime, and so we went with a more familiar hosting method, though still virtualised. So far we’ve had no problems with this and for the time being, our recommendation is to steer clear of cloud computing services until such a time as they’ve been thoroughly matured.

Back to the usual methods of virtualisation. Why? Who do you use? Why not just use shared hosting? I think I’ve explained most of these, but in finishing this part of the article, I’ll summarise: