Do You Need Capacity Planning for Cloud Computing?

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


and finally

  • you'll need to know the performance characteristic of the application

  • and from a test, how many transactions a cloud machine will provide you.

Conclusion

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.



You might also be interested in:

3 Comments

I am interested in the perspective of the Cloud Service Provider. With the right Capacity Planning technology and processes the provider can realize up-side to the Cloud business model via..

Analysis & Reporting to define, establish, report, enforce SLAs for clients.

Premium Revenue generation
1. Tiered SLAs(Platinum, Gold, Silver, etc.)

2. Historical performance data collection & storage

3. Predictive Modeling projections of future client Infrastructure-as-a-Service needs

4. Analytics-as-a-Service such as Performance Analysis & Capacity Planning (PACP)services

Chargeback data for usage reporting, usage billing, prove SLAs, etc.

1. Historical performance data collection, storage, reporting, feed billing engine

2. SOX Compliance, Auditing, Accounting, etc.

I think that this article exemplifies the diffference between theory and practice. In theory capacity planning is crucial, and the cloud makes it easier.

In practice neither are necessarily true.

Most startups fail. Capacity planning and application performance modeling are hard. Investing scarce resources is rarely pragmatic unless you have some evidence of business viability.

Certainly the cloud reduces the capital cost of scaling out compute resources and allows for a pay as you need model. What it does not
do is tell you that your DB schema that is attempting to meet both transactional and reporting needs will fail when you have 600k users.

In practice I doubt that the cloud will impact the value or cost of capacity planning for 80% of systems

I sure wouldn't want to try to put anything that needs
to thinks in terms of transactions into a cloud
or array. I have some customers who could use
more than 64 sockets for a large, database-centric
task! The worst possible cloud case.

News Topics

Recommended for You

Got a Question?