When is a Cloud Server better than a Dedicated Server?

When is a cloud server better than a dedicated server? The instinctive answer is "never!"

How could it be anything else? We are computer users, we are logical people and logically the answer is, "Never!"

Otherwise, why have dedicated servers the first place?

Well, after I published the article on the benefits of cloud servers I received an interesting email.

My article, basically, spoke of cloud servers as being a very cost-effective way of achieving much of the operational benefit of having your own dedicated server but without the attendant cost.

The implication was there that the cloud server, or VPS as it is also known as, is a compromise, albeit a very good one, between performance/features and monthly cost.

For the vast majority of server users that difference, that compromise, is almost unnoticeable, unlike the very big saving to their bank balance!

However, I was reminded by the email that there is a way in which a cloud server can be BETTER than a dedicated server!

Confused?

Well, the veracity of that statement, essentially, hangs upon how your hosting company sets up its Cloud Server/VDS/VPS.

At Intrahost, rather than individual physical servers hosting several virtual dedicated servers on their internal hard drives, the set-up is very different. Here, the physical servers are set-up in "clusters" and the data storage is not on individual hard drives in each server, but rather in a shared disk array (or storage area network - SAN).

Now, I don't want to become too technical here as the purpose of our blog is to help clients, newcomers and the just-plain-curious to better understand our hosting industry, not to blind them with science, technology or acronyms!

But essentially there is a double benefit to our "Intrahost method" here.

Firstly, as our physical servers are "clustered" it  means that if one physical server went down, other servers in the cluster would automatically begin acting as a physical host server for the virtual servers that were allocated to the, now, ex-server! But this resilience would be of no benefit if the data of the cloud servers was stored on the, now, inaccessible hard drives of the failed physical server.

This is where the second advantage of the Intrahost method kicks in. As the virtual servers themselves are stored on the SAN they are not affected by the loss of the defective physical server's hard drives and so the cloud servers and all their data will continue to be available to end users.

Furthermore, when it comes to replacing the faulty server it is a quicker and easier job as the hard drives don't have to be removed and so there is no interruption to the service received by the customers who were being served by the faulty server.

Now compare that to a dedicated server, with everything stored internally.

If the dedicated server goes down you are out of the game until engineers get it going again or, alternatively, allocate you another server, if the malfunction is catastrophic.

But if the dedicated server is down and, therefore, you cannot access your hard drive (and the data thereon) have you got a recent backup that you can install on a new dedicated server? Do you back up your dedicated server yourself or are you paying extra for a fully managed service?

So, basically, a cloud server can have a higher availability (aka uptime) than a dedicated server.

Therefore,  if your hosting company, like Intrahost,  is utilising clusters of hosts and a storage area network, a virtual server, far from being a compromise is, in fact, a superior, hardier beast in terms of availability than your stand-alone, expensive, thoroughbred dedicated server.

If your cloud server hosts your business website or data files do you really want to be gambling everything, literally, on the survival of just one server?

Consequently, if you have a cloud server with another hosting company maybe it is worth checking whether your server benefits from host clusters and a SAN or whether it is risking all on just one physical server. If not, you know who to call...