One of the topics most associated with cloud computing is its cost advantages, or lack thereof. One way the topic gets discussed is "capex vs. opex," a simple formulation, but one fraught with meaning.
At its simplest, capex vs. opex is how compute resource is paid for by the consumer of those resources. For example, if one uses Amazon Web Services, payment is made on a highly granular level for the use of the resources -- either time (so much per server-hour) or consumption (so much per gigabyte of storage per month). The consumer does not, however, own the assets that deliver those resources. Amazon owns the server and the storage machinery.
From an accounting perspective, owning an asset is commonly considered a capital expenditure (thus the sobriquet capex). It requires payment for the entire asset and the cost becomes an entry on the company's balance sheet, depreciated over some period of time.
By contrast, operating expenditure is a cost associated with operating the business over a short period, typically a year. All payments during this year count against the income statement and do not directly affect the balance sheet.
From an organizational perspective, the balance sheet is the bailiwick of the CFO, who typically screens all requests for asset expenditure very carefully, while operating expenditures are the province of business units, who are able to spend within their yearly budgets with greater freedom.
Summing this up, it means that running an application and paying for its compute resources on an "as-used" basis means the costs run through the operating budget (i.e., are operating expenditures -- opex), while running the same application and using resources that have been purchased as an asset means the cost of the resources is a capital expenditure (capex), while the yearly depreciation becomes an operating expenditure.
It might seem obvious that the opex approach is more preferable -- after all, just pay for what you use. By contrast, the capex approach means that a fixed depreciation fee is assigned no matter what use is made of the asset.
However, the comparison is made more complex by the fact that cloud service providers who charge on an as-used basis commonly add a profit to their costs. An internal IT group does not add a profit margin, so charges only what their costs add up to. Depending upon the use scenario of the individual application, paying a yearly depreciation fee may be more attractive than paying on a more granular basis. The logic of this can be seen in auto use -- it's commonly more economical to purchase a car for daily use in one's own city, but far cheaper to rent a car for a one or two day remote business trip.
There is an enormous amount of controversy about whether the capex or opex approach to cloud computing is less expensive. We've seen this in our own business -- at one meeting, when the topic of using AWS as a deployment platform was raised, an operations manager stated flatly "you don't want to do that, after two years you've bought a server." Notwithstanding his crude financial evaluation (clearly not accounting for other costs like power and labor), his perspective was opex vs. capex -- that the cost of paying for resources on a granular basis would be more expensive than making an asset purchase and depreciating it.
The move to private clouds added to the complixity of this. Heretofore, most organizations worked on the basis of one application, one server, so the entire depreciation for the server was assigned to one application, making the calculation of how much the capex approach would cost relatively straightforward.
This became further complicated with the shift to virtualization, in which multiple applications shared one server. Now yearly depreciation needed to be apportioned among multiple applications -- and this could be even more complex if one attempted to apportion the cost according to something other than assigning cost by dividing the cost by the number of VMs on the machine. Trying to assign cost on the percentage of total memory used by an application, or processor time requires instrumentation and more sophisticated accounting methods, so most organizations just work on a rough "X dollars, Y number of VMs, each one costs X divided by Y."
Today, though, organizations using compute resources don't want to pay a flat fee; after all, they may have transitory use, spinning up resources for a short-term test or a short-lived business initiative, why should they commit to a five-year depreciation schedule? Resource consumers expect to pay on an operating expenditure basis; after all, that's what's out there in the market. They want to pay only for what they use, no matter who the provider is.
IT organizations are intrepidly preparing for this world, implementing private clouds and moving toward granular pricing of resources, a task made difficult, it must be admitted, by the fact that most IT organizations do not have accounting systems designed to support detailed cost tracking.
So it will be the best of all worlds -- resource consumers getting granular, use-based costing, IT organizations providing private cloud capability with support for sophisticated cost assignment, and no provider profit motive imposing additional fees beyond base costs.
Or will it?
Here's the thing -- for every opex user there is a capex investor. For every user who delights in only paying for the resources used, there must be a provider who stands ready to provide resources and offer them on an as-needed basis -- someone must own assets.
For that asset holder, a key variable in offering prices is utilization -- what percentage of total capacity is being used. To go back to that crude pricing formula, an example of cloud utilization is what percentage of a servers total available processing hours are sold. The crucial factor is to sell sufficient hours -- i.e., generate sufficient utilization -- to pay for the asset.
This means that IT organizations need to become much more sophisticated about managing load and shaping use. This is typical of any capital- intensive industry -- think of airlines and the sophisticated yield management measures they implement.
I have heard some people assert that utilization won't be much of a problem because most applications are not very volatile; that is, their resource use doesn't vary much. Therefore, high utilization rates can be achieved in private clouds by building a cloud to support typical use plus some spare capacity to support occasional spikes in demand.
I think this misreads likely experience and extrapolates the past inappropriately. This belief underestimates outcomes as application groups absorb the capability of cloud computing. For one, now that highly variable loads can be supported, application groups will begin creating more of these type of applications; heretofore, because it was extremely difficult to get sufficient resources for these type of applications, people didnt even bother thinking about them. Now that a highly variable load application is possible, people will start developing them.
A second way this perspective underestimates future outcomes is that it fails to understand behavior changes as organizations learn that they can reduce costs by squeezing application capacity use during low-demand periods. James Staten of Forrester characterizes this as "down and off," meaning cloud computing cost is reduced as ways to scale applications down or turn resources off. This cost reduction benefits uses, but causes problems for providers.
Finally, the perspective that the cloud will be like past infrastructure use -- mostly stable and low growth -- fails to understand how price elasticity will affect demand. If cloud is cheaper, people will use more of it. This is why we at HyperStratus predict a coming explosion of applications. Again, this will affect utilization and capacity planning (I discussed the challenge of capacity planning in a cloud world here). Not everyone agrees with us -- just read the comments to the capacity planning post, but the evidence is right before us, and is the problem staring us in the face -- data centers bursting at the seams. No one would have predicted that when the first client-server applications were installed in a departmental computer sitting under someone's desk that we would live in a world with corporate data centers running out of capacity -- but we do. Cloud computing will result in the same explosion of demand. Count on it.
What are the outcomes of this shift to opex and utilization risk? Here are a few:
1. Yield management will become a core IT skill. If users no longer bear utilization risk, the organization that does will have to carefully manage use to ensure sufficient utilization and financial viability. Buying equipment on behalf of someone is vastly different than buying equipment and selling it to someone and carrying the risk that insufficient sales occur. By the way, the historical 5% - 15% utilization rate of IT is scandalous; in 2009 people were decrying the historic low manufacturing utilization rate as evidence of an economy in deep trouble? -- and manufacturing utilization was at 69%! IT must do much, much better.
2. We can expect some examples of high-profile IT disasters as cloud initiatives implemented on the basis of 70% utilization struggle to achieve 25%, with accompanying financial bloodbaths. Of course, high-profile IT disasters are nothing new in the industry (witness the debacle of New York's CityTime system), so perhaps this won't raise a ripple in an industry seemingly inured to failure. The important point is that pricing is directly related to utilization, so low utilization rates can pose one of two unpalatable outcomes: going back to users and asking for much higher rates, or absorbing a large writeoff for spare capacity.
3. IT financial talent will be crucial for organizations operating private clouds. Being able to track utilization, set prices, market to raise demand, and implement pricing (and collection!) are skills most IT organizations do not currently need. That will change in short order. One might say that with the oft-predicted move to IT operating like a business, it will need to put all of the elements associated with running a business into place.
4. Risk management will be in a category of its own. The risk exposure of operating a capital-intensive business with financial exposure based on utilization is high -- very high. Figuring out a way to manage that risk will be vital for IT organizations in the future. I recently ran across a startup called Strategic Blue that provides the equivalent of insurance swaps -- protection against utilization risk by paying a fee to an intermediary. Just the fact that an entrepreneur has focused on this area indicates that the issue is present, perhaps more so than most appreciate. It's too early to tell how the company will do, but it's safe to say that cloud computing presents more risk to IT than traditional one application, one server ever did.
As always, I continue to be fascinated by this development in technology, and convinced that more change -- and benefit -- lies ahead of us than we've seen over entire history of computing. In a sense, IT is moving to its next stage, where it operates as a core capability of companies, rather than a backoffice support function. That, however, will require it to operate with the same discipline and financial management of other core groups, so the issue of utilization risk is entirely appropriate for a more important IT role.
Bernard Golden is CEO of consulting firm HyperStratus, which specializes in virtualization, cloud computing and related issues. He is also the author of "Virtualization for Dummies," the best-selling book on virtualization to date.
Follow Bernard Golden on Twitter @bernardgolden. Follow everything from CIO.com on Twitter @CIOonline
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.