Hosting part 3: virtual servers?
Part 3 is here, and it takes a few forms that I’ll discuss.
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 elses real computer without the cost of buying your own, and with the security that comes with having your own, or you could divided 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 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:
- Get your own server and virtualise it, using it for many different applications
- Rent space on someone elses servers
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 slicehost and engineyard 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:
Virtual servers are much cheaper than buying lots of hardware, use the server to its capacity and therefore not waste additional expense that the machine is incurring in just being on, it’s stable (most methods anyway!) and keeps data far more secure than shared hosting. You have your virtual space, and no one can get in, as long as its managed properly.
Hosting part 2: Dedicate yourselves
It’s been a little while since our last post – we’ve been crazy busy, and we’ve got some more fuel for this series in the process too. In this part, we’re looking at Dedicated hosting, and what it means.
SImply put, dedicated hosting means having hardware dedicated to one website or one application. Nothing else sits on that server, such as other websites that can interfere, or use up precious resources. There are a number of scenarios that suit dedicated hosting and it is usually relevant for the larger scale websites rather than smaller ones. Lets say for example that you’re expecting your site to get hundreds and thousands of hits in the first few days. You might want to look at getting at least a dedicated server, if not a cluster of them to handle the load that the machine will experience.
But again, this depends on the site itself. If it’s just a single page site with nothing but static flash or HTML to load, you’ll manage a huge amount of throughput on a relatively low performance machine. It’s all the database calls and all the dynamic data and the lack of being able to cache it a lot of the time that makes a server seem slow or even make it give up!
Again, this is ultimately going to be a decision that needs to be made between the strategists for the project, the developers and the server admins. They’ll tell you if you need it or if you need something more or less than just a single dedicated machine. And it’ll cost money for a good service. You’ll normally want to get the server managed for you if you don’t have your own admins that can keep it up to date and patched regularly.
A single dedicated server will often cost more for the hardware than a similarly specified virtual machine, but with it comes the knowledge that you’re not sharing any resources with other virtual machines. There is nothing wrong with either approach. It just depends on the requirements of the application.
If you’ve got a site you’re expecting a lot of hits to, or you know it’s a big application and it needs something beefy to run it, your best bet is usually going to be dedicated. Just be prepared to stump up for it.
Hosting part 1: what are my options?
This article is a 4 part article that goes into the detail you need to make sure your website is hosted on hardware that makes sense.
I’d say it’s useful to have some idea of how you might host a website you’re building, and to do that you’d need some idea of how many people you’re expecting to visit, how many people you’re expecting to buy from it (if it’s a site that sells things) or interact with it. Usually, this should come from the business case for a particular project, which will either be decided by the client or by the strategist developing the campaign.
There are a number of options you can choose from when it comes to actually getting your site up on the web, and each has it’s advantages and pitfalls. How do you choose, and how do you make sure the people who are building the technical infrastructure of the site are providing the right solution for the specific requirements of the project?
For clarity, it is important to remember that there are a couple of main groups of people involved in building a website from a technical standpoint: Developers, who would be building the project, and System Administrators, who would administer the hardware platform on which the application or website sits. For the site to function adequately, the hardware specified has to be sufficient for any strategic goals devised by the account teams or the client to be met. That means two things are absolutely imperative in making sure any hardware platform is going to work for any given project: planning and consultation.
The ideal way of working is that the developers would plan their software stack, providing this to the system administrators who, in consultation with both the accounts team and the developers would come up with a hardware platform that suits both the requirements of the software and the ability to achieve the business goals set.
Once you’ve got the basic parts of this, you then have to make a choice: Dedicated hosting, virtual hosting, shared hosting, or cloud hosting? I’ll dismiss shared hosting for all but the smallest of sites with no security concerns. Every project should have its own hosting platform uncontaminated by other elements. This means the underlying software can’t change and break your application because someone else upgraded theirs, and other sites hosted on a non-shared platform can’t access each other’s data.
In the next article I’ll go into the pros and cons of dedicated hosting. Stay tuned.
Recent Comments