What is Cloud?
by
There are some interesting takes on cloud computing. With some vendors bringing the ‘cloud’ into your data center by streamlining provisioning of new servers. Other vendors are recasting existing services as ‘cloud’ or SaaS (Software as a Service). Github is a ‘cloud’ source code repository that is becoming the unofficial source code repository for the cloud. Companies like Heroku, Google and Salesforce.com, are calling application hosting ‘cloud.’ For some clouds are operating environments. Microsoft is offering a combination of hosted services and application hosting in their cloud offering. So the question is, what is cloud?
Let’s look at leased servers. Amazon’s EC2 is certainly ‘cloudy’ in feel, but why doesn’t a plain old virtual server sound cloudy? Maybe because the virtual server is fixed (although we’ve had clients with virtual servers that moved, were re-IP'edn and mayhem ensued). A leased server is fixed, tied to some physical box in a cabinet. A server on the cloud isn’t fixed, we can imagine it moving around in some sense. It’s elegant, beautiful, whispy and light compared to the boat anchor feel of a leased server with a 2 year contract. But actually, the big difference Amazon points out is financial flexibility. I’m using resources efficiently (from a financial perspective) because I can bring servers up and down based on need.
A few weeks ago Sun was set to make a cloud computing announcement. I thought they might be offering a cloud computing service, but instead they wanted to talk about how they’re an enabler. They enable the cloud. But using your data center as a cloud, as Sun or VMWare might suggest, doesn’t seem very cloudy. You still have to buy racks of servers and maintain some idle capacity. Idle servers sitting around and large fixed investments don’t feel cloudy. Maybe ‘Virtualization’ didn’t roll off the tongue as well as ‘cloud,’ and therefore ‘cloud’ is the new virtualization. Yet it is cloudy in some sense to be able to find a home for a new application without having to provision a fresh server or blade.
So maybe, when everything is said and done, cloud means ‘nimble’ or ‘flexible.’ What Amazon is offering is a leased server with a per hour contract. Most places offering leased servers want you to pre-pay one year, or monthly with a one year agreement. The same can be said of services like Heroku and Google. You can scale up and down your financial commitment on a short-term basis. Getting more capacity out of some hosts could result in an expensive change in service tiers, more long term contract, etc.
What it does not mean is a free lunch. If you look at the pricing for Amazon, for example, the basic server compute unit (equivalent to a 1.2 Ghz core) is $0.10 an hour or $72 per core per month (not including S3 storage). You can buy a fairly modern 8 core machine for about $3000 to $4000. Getting power and bandwidth to the machine might be in the $250 per month range. Amortizing the server over just one year, your cost would be $500-$600 a month for 8 cores (or $360 with a 3 year amortization), versus Amazon’s $576 per 8 compute units per month. And given that you might be looking at a newer 2.5-3.0 Ghz Xeon, around twice Amazon’s stated performance, it may perform more like 12 or 16 compute units. (That assumes you already have or are paying for the person to manage the server).
What buying a server doesn’t get you is the ability to not pay for cores you’re not using. Say, for example, your service is cyclical and peaks only on holidays. Amazon would let your run on 1 core (if that’s sufficient) but then scale up to 8 cores for those short periods. Once the load backs down you go back to $72 per month. You might still spend significant time and money tooling your application so it can scale up and down that way. For example, you might actually use 2 cores, with one core running the database and the other cores running the application so you can just add more cores. Now you’re at $144 per month or more if the database image requires more capacity to handle peak loads.
There are some unanswered questions. The burden to monitor the server is still on you. You need to decide to scale up or down as needed and you may not be able to respond to sudden, short changes in demand (slashdot). In some cases, as we’ve seen, the cloud provider can go down. There are legitimate questions regarding security and what kind of information you can put into cloud based storage. Maybe you have super secret sauce in your code that can’t be disclosed without loosing your competitive edge. What we haven’t seen is how well the cloud services vendors scale up (meet their performance SLA’s) if they get hit with a groundswell of demand. Somebody has to have idle capacity somewhere for users to have their capacity demands met.
But I think there’s a shared vision of the cloud in the current zeitgeist. We can envision on-demand server capacity powering applications hosted by sites like Facebook, so that we only have to build and deploy tiny pieces of simple functionality. In turn these combine into an over all service offering that provides value, and therefore can be monetized with a small initial investment. No big server build outs. No unused capacity. In other words, the service pays for itself, we avoid sunk costs, and we’re all self-funding.
Up Next: Developer as Typist by
Previously: The Tyranny of the Small by