How to Track Cost Allocation for Cloud Apps

One of the most interesting aspects of cloud computing is the way it changes cost allocation over the lifetime of an application. Many people understand that pay-as-you go is an attractive cost model, but fail to understand the implications that the new cost allocation model imposes on IT organizations.

The pay-as-you-go model addresses several obvious and painful limitations of the previous model, which was based on asset purchase; in other words, prior to application deployment, a significant capital investment had to be made to purchase computing equipment (i.e., servers, switches, storage, and so on).

The Shortcomings of the Asset Purchase Approach

• It requires a large capital investment, which displaces other investment that the organization might make (that is, it forces a tradeoff between this application and other, potentially useful capital investments like new offices, factories, and so on).
• The capital investment must be made before it may be clear just how much computing resource will be needed when the application is operating; perhaps the application will experience much more use and there won’t be enough equipment, but perhaps the application won’t be used as forecast, and some or much of the investment will be wasted.
• Requiring a large investment upfront makes organizations more conservative, not wanting to invest in applications that may not be adopted; this has the inevitable effect of hindering innovation, as innovative applications are by definition difficult to forecast and therefore more likely to result in poor adoption.

However, there is one big advantage of this approach: once the investment is made, the financial decision is over. Assuming the application obtains the necessary capital, no further financial commitment will be needed. Of course, this has led to utilization issues, as applications commonly only used single-digit percentages of the computing resource assigned to them, but there were no ongoing bills or invoices for the application resources.

[Related: What the Cloud Really Costs: Do You Know?]

Many people are excited about cloud computing because it uses a different cost allocation model over the lifetime of an application. Instead of a large upfront payment, you pay throughout the lifetime of the application; moreover, you have to pay only for actual resource used, thereby avoiding the underutilized capital investment situation typical of the previous approach.

[Related: Calculating Virtualization and Cloud Costs: 4 Approaches]

The Advantages of the Cloud Computing Approach

• Little investment is required upfront. This means that cloud-based applications can be pursued without worrying about whether other, useful capital investment will be displaced by the decision.
• This approach fosters innovation. Because little investment is at risk, innovative applications can be rolled out with less concern about predicting outcomes. If the application is successful, more resources can be easily added without requiring more investment; if the application is poorly adopted, it can be terminated and the resources returned to the cloud provider, with no ongoing payment needed.
• It can enhance agility, because no lengthy capital investment decision processes are needed prior to beginning work. The cliche is that all that is necessary to get started is a credit card and within 10 minutes you’re up and running. Anyone who has suffered through a capital investment decision process knows how long and miserable an experience it can be. Certainly the 10 minute approach is extremely attractive.

The Challenges of the Pay-As-You-Go Approach

• The first one is obvious: instead of a one-time payment, users receive a monthly invoice or credit card charge. Every month there is reminder that there is a cost associated with running the application. The meter is always running.
• The costs are unpredictable. I was talking to the CIO of a large media company and he said that his organization loved the ease of access to resources that Amazon Web Services (AWS) makes possible, but one of his projects experienced this: the first month of working on the application was great — immediate access and only $400 of cost; the second month, however, the fee came to $10,000. He noted that his firm could afford the $10,000, but wanted to understand what caused such a dramatic change in cost.
• Low resource utilization imposes ongoing wasted costs. While poor utilization in the previous model evinced inefficiency, at least there was no ongoing wasted money. When cloud resources are not actually used, but continue running, every month a bill comes for little productive work. It’s like running your air conditioner with the front door wide open. And the poor habits of previous computing regimens continue in the new world of cloud computing. At the recent Cloud Connect conference, a new cost tracking service called Cloudyn noted that its research shows that AWS resources are commonly used at 17 percent utilization (conference presentation on slideshare here).

  That’s a lot of wasted money. Add in the likelihood that these resources are not being tracked and spun up instances are often started and then forgotten about, organizations could easily experience months or years of extra costs.

[Related: Cloud’s Commodity Pricing Squeezes Service Providers, Creates Opportunities]

What Is the Right Approach?

So what is the right approach for IT organizations to realize the benefits of cloud computing, but avoid the unfortunate cost effects outlined above? Here are five critical items to pay attention to:

1. Design: Your application must be designed so that the appropriate level of resources can be assigned and used. Think of this as a “just-in-time computing resource.” This implies that the application must be designed as a collection of small. finely grained resources that can be added or subtracted as application load dictates.

   Instead of one very large instance, the right design approach is to use multiple smaller instances that can grow or shrink in number as appropriate. Of course, this requires the application be facile with respect to adding or subtracting resources while in operation. There are implications in terms of state and session management, load balancing, and application monitoring and management and these must be taken into account to ensure the application can respond to changing workloads.

2. Operations: Monitor utilization and terminate unneeded resources. As previously mentioned, lots of bad habits from the previous, upfront investment approach remain in cloud computing users. Probably the worst one is the habit of starting resources and never shutting them off, or, indeed, never monitoring them to determine whether they’re being used or not.

   In the pay-as-you-go world, every unused or underused resource is a hole down which you’re pouring money. A service such as Cloudyn or one of its competitors can be enormously helpful here, but to my mind the financial tracking needs to be married to an operational tracking in which developers and system administrators are constantly monitoring resources to evaluate use, use levels, and potential design optimizations to reduce cost while still maintaining operational efficiency and required performance levels.

3. Finance: Evaluate total organizational spend. I’ve worked with a number of companies that have many, many AWS accounts and don’t realize that by centralizing the spend, they would achieve greater discounts. While within some companies that decentralized approach is deliberate (aka “shadow IT”), everyone will benefit from lower prices, so it makes sense to move to a collective bill.
4. Procurement: Negotiate pricing. While AWS posts its prices, if there is sufficient spend, it will demonstrate flexibility. Certainly every other cloud service provider (CSP) out there is very flexible on pricing, especially in a situation in which the account would be moving from AWS. Of course, it’s critical to ensure other critical elements of the application, like availability and security, can be achieved in another cloud environment.

   Also, the application design must be such that it can be transferred from one cloud environment to another. Even if one is “locked in” via application requirements or design, it’s amazing just what pricing flexibility can be generated by even the threat of potential provider switching.

5. Management: Recognize that cloud computing is a new operation mode and cost tracking and application utilization monitoring are critical IT skills. Set up a group that examines ongoing financial performance to ensure maximum cost/benefit outcomes.

   Don’t staff the group with only finance people either. Technical skills are required as well to enable a full 360 degree evaluation of application financial and technical performance. Above all, realize that IT is now in the service provider business, and service providers pay attention to operational costs all the time.

Bernard Golden is the vice president of Enterprise Solutions for enStratus Networks, a cloud management software company. He is the author of three books on virtualization and cloud computing, including Virtualization for Dummies. Follow Bernard Golden on Twitter @bernardgolden.

Follow everything from CIO.com on Twitter @CIOonline