On first glance, a properly-done cloud computing agreement sounds like it should save a customer company the work of doing any capacity planning at all. You can let the cloud supplier do all the work. However, even the best cloud service is more expensive than running your own small data center, so it doesn't make sense to have everything in the cloud, always.
What cloud or utility computing does allow is for you, the customer, to radically simplify capacity and financial planning, and only provide enough resources for the load that you're sure to get, letting the cloud carry all the spikes and year-end rushes.
Using the Cloud Well
The value of a cloud is its ability to make your computing budget into a fixed cost per transaction. If you put together a cloud service which costs you 12¢ per transaction, then it will cost you the same amount for one transaction as a million. The more business your company does, the more it makes, and a fixed proportion for each transaction goes to the cloud supplier. You just need to ensure that every transaction brings in more than twelve cents.
Building a configuration that works, and that has a fixed cost per profit-making transaction is the key to making the Cloud work for you.
Selling Blue Jays™ Caps
Imagine you're a small business manufacturing sports-team memorabilia, and you have a program that lets individuals buy your products over the web. You've a small development machine, which you also use for quality control, and a somewhat larger production machine in rented space in a data center.
You also have huge, uncontrolled bursts of sales when one of your teams has a run of wins. For a few days, everyone in Toronto wants a genuine, authorized Blue Jays cap. Or a Argos™ jacket.
Every time that happens, your production server goes toes-up from the load. You sell a few hundred, but you guesstimate you'd sell far more if you didn't turn an unknown number of customers away.
This is where a computing utility, a "cloud" shines.
You take a copy of your sales program and package it so it will run in a virtual machine in the cloud. Let's assume it's in Java, so all you need is a cloud supplier to provide you with JVMs in the cloud, and have each one run a copy of the sales program and its connection to the credit-card processing service.
You need a good idea of how much of each resource the program uses, both on your own machine and on a "standard" virtual machine, as defined by your cloud supplier. And you'll need to know that your program runs well in multiple copies: the cloud assumes you're running parallelizable programs, just like the array and utility computing system which were its forbears.
Finally, you need a load balancer or "application distributor" in the cloud you're renting that can be tuned to allocate no more than N transactions per cloud server, where N is the number of instance of your program that can run on each cloud server.
Now you can run your program for a while, collect statistics and cloud billings and wait for a sales peak to see just how much benefit you're getting from not turning away paying customers. Once you've done that, you'll be able to figure out your cost per transaction, and compare that to the average profit you got for the same set of transactions.
Don't Give Up Your Production Machine
If you do the same calculation using your existing production machine, though, you'll find that the per-transaction cost is lower. And you already have the machine. Let's say it will handle 40 TPS, at 9.7¢ per transaction.
So change the load balancing so that the first 35 transactions go to your machine, and the rest go to the Cloud data center. Now you're ready for the peaks, but much of your day-today transaction load goes to the cheaper non-cloud machines.
Maximizing your profit now turns into a classic business problem, akin to allocating work to machines on an assembly line. You want enough resources in your data center to handle the steady, everyday load at a low price. You want enough extra cloud capacity to handle everything else, albeit for 2.3 cents more per transaction.
The cloud is also two other things for you: disaster recovery and a site to fail over to when doing scheduled maintenance. It steps in during any emergencies, and also whenever you need to do an upgrade of the program on your production machine. This completely eliminates the "do maintenance at 3 AM on Sunday" task that your system administrators hate. They can do the work during day shift at straight time by shoving the load into the cloud.
What Can Go Wrong
This assumes that your cloud vendor can guarantee you a certain number of machines, no matter how busy all his other customers are. That's not guaranteed: some cloud vendors are just trying to use up the wasted time on their machines, and reserve the right to cut you off when they're busy. If you want a guarantee, you'll need to negotiate a service level agreement (SLA) with the cloud vendor, and pay extra for it.
If you can't get an agreement, or if it's too expensive, you'll need to provide enough capacity in your own machine room to be able to handle a significant number of the peaks you expect, and hope that they don't happen at the same time as someone else's peak. If your business has a Christmas rush, you'd better plan to handle much of it locally!
What This All Assumes
To make this all work, you need
- a cloud vendor that will provide you with Java or LAMP virtual machines
- if not, and they use a framework like Hadoop, then you'll need a private part of the cloud on your server
- predictable prices for virtual machines, that averages into cents per transaction
- a load balancer ("application director") that can do that across two sites, vendor and yours
a process for phasing in a new VM contents, so you can update your program occasionally
- you'll need to know the performance characteristic of the application
- and from a test, how many transactions a cloud machine will provide you.
So in the end, you do capacity planning for the cloud, to size the program to your cloud supplier's standard machines. You also do capacity planning to find the most efficient size of machine for your own data center. And you plan for times when the cloud is too busy to do your work.
So you actually do more capacity planning for Cloud computing, it's just particularly easy planning.