Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Currently I/we run a SaaS web application where each subscriber has their own physical instance of the application in addition to their own database. The setup has each web application instance deployed on two different IIS boxes both for load-balancing and redundancy (the machines have their Windows Update install times 12 hours apart, for example). Databases are mirrored on two different SQL Server 2012 machines with AlwaysOn for uptime. I don't make use of SQL Server clustering (as it doesn't provide storage-level failover: we don't have a shared storage box).

Because it's a Windows setup it means there are two Domain Controllers (we cheat: they're both Mac Minis, 17W each, which keeps our colo power costs low).

Finally there's also an Exchange server (Mailbox, Hub Transport and Client Access). One of the SQL Servers also doubles-up as an Exchange Hub Transport.

Running costs are about $700 a month for our quarter-rack colocation (which includes power and peering/transfer), then there's about $150 a month for SPLA licensing, so $850 a month in total. Then there's the hard-to-quantify cost of administration, but I reckon I spend a couple of hours a week checking-in on the servers: reviewing event logs, etc.

I keep getting bombarded by ads and manufactured news stories about how great "the cloud" is.

Back in 2008 when the cloud was taking off I was reading up about the proper "cloud" services like Google AppEngine, where you write in Python against Google's API and that's how they scale your application across servers and also use their database provider for scaling storage. Simple enough to understand.

Then came along Amazon, and I understand how Amazon Storage works, but I'm not sure how Amazon Compute works: web application pages don't take much CPU time to compute, how do you even quantify usage anyway?

Finally, RackSpace gets in the act and now I'm really confused.

RackSpace advertise "Cloud" SQL Server 2012 available for about "$0.70 per hour", going by how they advertise it I thought the "hour" meant the sum of CPU time, IO blocking time, maybe time spent transferring data, so for a low-intensity application that works out pretty cheap then?

Nope. I went on to a Sales Chat window and spoke to one of their advisors. They told me the $0.70/hour was actually for every hour the SQL Server is running... but who wants a SQL Server for only a few hours? You're going to need it available 24 hours a day for months on end. $0.70 * 24 * 31 works out at $520 a month, which is rediculously expensive for SQL Server. An SPLA license for SQL Server is only $50 a month or so. That $520 a month does not include "fanatical support", and you also need to stack on top the costs of the host Windows server instance too.

From what I can tell, Rackspace's "Cloud" products seem like like an cynical rebranding of an overpriced VPS service, but priced by the hour.

I have the same confusion about Windows Azure which uses similar terms to describe the products available, but I think that's because Azure offers both traditional shared webhosting in addition to their own APIs you can target for scalable applications.

share|improve this question

closed as not constructive by Sven, Steven Monday, Magellan, RobM, EEAA Oct 28 '12 at 2:46

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

up vote 8 down vote accepted

Cloud computing of the type popularized by Amazon and Rackspace is not a direct replacement to colocation, or even VPSs. A good breakdown can be found here:

Cloud systems help you if you're looking for an elastic infrastructure. If your infrastructure is static, you have X servers and that number doesn't change for months on end, it is less attractive. In fact, it can be significantly more expensive as you discovered.

The question:

Who would ever want to run a SQL server part time?

Is a valid one. However, if that SQL server is the backing server for anything from 5 to 500 web/application servers, all of whom are part-timers, the whole infrastructure is a savings. The cost of running that one SQL instance 24/7 is eaten by the savings of NOT having to run 500-servers worth of capacity 24/7 just in case. Some cloud providers do have special pricing plans for always-on systems, which helps further cut the costs.

Cloud is a code-phrase for scalable infrastructure that comes with an API or two. With this API you can customize the scaling for your particular use-case. The systems that get the best cost efficiencies are those that are highly variable in load, and the number of running instances can move with it.

VPS is in large part colocation-like, but without the physical infrastructure. Scaling can still happen, but you're going to be handling things like automated OS installs and the like yourself. If you have a static infrastructure and want to go 'cloud', VPS is probably a better choice for you.

Colocation is as you said, physical hardware in rented space. You're responsible for everything from network card replacements to scheduling server swap outs.

Another area where Cloud can be a savings is if you don't have people who are hardware-savvy and you want to run something highly-scalable. It allows you to scale an application to the point where, were it implemented in actual owned-by-the-company hardware, you'd need one to three sysadmin-types to keep running all without having to hire those sysadmins. That's a significant salary savings right there.

But if you already have that staff (you're here, so probably), that type of savings may not apply in your case.

share|improve this answer
Excellent answer. I just wanted to comment outright one thing you alluded to with your elasticity comment but didn't specifically state: consider the case where your application has a particularly high load window (say lunchtime for a popular news website) then a 'cloud' architecture allows you to fire up additional nodes for your high load periods and completely turn them off at other hours. – Josh Atkins Jun 24 '12 at 9:09

Not the answer you're looking for? Browse other questions tagged or ask your own question.