The debate about the economic benefits of cloud computing is intense, and is commonly boiled down to a talking point labelled OpEx vs. CapEx. Very often, like many talking points, the headline conflict is really a stalking horse that conceals the true source of conflict.
In the case of OpEx vs. CapEx, what often underlies the discussion is really an indirect, coded debate about the future of IT infrastructure and operations groups: Will they be operators of assets owned by the larger organization, or will they be operators of assets owned by an external provider?
It doesn't take a genius to understand why being responsible for operating hundreds of millions of dollars of owned assets, along with all of the people associated with ownership (technical evaluation, vendor relationships, capacity planning, etc.), is typically seen as more prestigious and important than managing assets from an external provider who takes responsibility for all of those areas. An even more nightmarish vision is that infrastructure and operations groups will be cut out of the equation entirely, with application groups taking responsibility for dealing with external providers, leaving I&O with a dwindling responsibility set, managing an ever-eroding installed asset base.
Consequently, it makes sense that there is plenty of emotional energy around the issue of the cost of cloud computing, with the OpEx vs. CapEx topic commonly designated as the battleground. However, much of the discussion on these topics fails to comprehend the profound implications of different funding models, and how they map against the future of IT applications.
And let me say, up front, that in my view, all of this discussion is really about identifying the best possible method of running applications, because applications are where all the value of IT is created.
Here are some thoughts about nuances (and implications) of funding models that the current debate of OpEx vs. CapEx fails to capture:
All Things Being Equal, OpEx Should Be More Expensive Than CapEx
One of the benefits of the OpEx model is that there is no long-term commitment. When a user is finished with the resource, it is turned back to the provider, who holds utilization responsibility -- that is, the provider has to figure out how to obtain sufficient usage of the resource to make it economically workable.
The lack of commitment is financially valuable, in that it frees the user from having to make a significant, long-term investment. In the financial markets, options have value and are assigned a price. It makes sense that, per unit of measurement, OpEx resources would be more expensive than CapEx resources. One only has to look at rental car pricing to recognize that we pay a premium for short-term commitment. We save money by paying that higher rate for a shorter period of time, which ultimately is less expensive than purchasing a car only to use it for a short while.
Choosing One Option Over Another Is a Trade-off
The true question, therefore, is not which option costs more per measurement unit, but rather which option is least expensive over the total usage of the resource (or, more typically, over the total usage of all the resources used to operate the application). This calculation is much trickier than a unit-to-unit comparison. First, it requires forecasting total use over some period of time, typically a month. In other words, how many hours will this application be running per month? How much storage will it use? How much network traffic will be associated with it?
Second, it may have to take into account changing rental rates based on usage tiers. A gigabyte of storage that costs a certain rate if total storage used is 10 gigabytes may be less expensive if total storage used is 10 terabytes.
Third, it has to account for variable usage patterns -- low use for some periods and very high use for others. For instance, a financial services company's applications are likely to have monthly peaks, quarterly peaks and annual peaks, not to mention unexpected peaks driven by non-cyclical events like, say, modified laws that change the consumer attractiveness of certain kinds of financial instruments.
Making this tricky evaluation requires a comparison of TCO, where the "O" stands for operation, not ownership. For many usage patterns, it is likely that the rental model will be more attractive in aggregate use, even if it is more expensive per unit of measurement. Returning to the rental car example, even if a rental car costs more per day than purchasing a vehicle, if one uses a car for only five days a month, renting could end up being less expensive overall.
One can say, then, that the economic evaluation has to be more sophisticated to account for variable use, and therefore variable costs that are associated with the asset rental model. Naturally, the asset ownership model costs the same irrespective of the use pattern -- whether full-time or no more than one hour per month.
Friction Affects the OpEx vs CapEx Evaluation
Of course, there are other factors that affect this calculus. Renting a car extracts a toll in time -- walking through the rental process, listening to the extra insurance spiel, inspecting the rental car and so on. If one needs a car eight separate days a month, it might be less expensive to rent. Then again, one might be tempted to purchase to avoid the Groundhog Day-like repetitiveness of, "How are you going to handle insurance for this vehicle? Our liability top-up service releases you from having to pay a deductible fee."
In other words, the friction of the experience is likely to sway the decision to pursue one option or the other. Ronald Coase, the Nobel Prize-winning economist, characterized the overhead represented by the rental car rigamarole as "transaction costs": costs associated with an economic transaction that add additional burden to the choice.
With respect to IT applications, there has traditionally been extremely high friction associated with bringing them up and down -- so much so that it's usually easier to get them up and running and then avoid touching them as much as possible. For a rental model, that "set and forget" approach is a poor approach from a financial perspective.
When one really evaluates using assets in a rental model, it's obvious that one should seek to reduce usage as much as is practical. James Staten, the well-known Forrester cloud analyst, characterizes this approach as "down and off," arguing that one should always seek to reduce an application's resources as much as possible so long as its functional and performance requirements are met. If there is no usage demand, the application should be shut down, only to be restarted when usage demand begins anew.
However, the organizational friction involved with resource management is so high that most IT groups, when performing an OpEx vs. CapEx analysis, assume full-time operation of the highest amount of resource required at application peak load, and then use that basis to evaluate the asset rental against and the asset ownership models. It simply doesn't make sense to perform the evaluation in any other way. In fact, most organizations typically fail to even consider other options because it's inconceivable that the friction could abate enough to make a different operational model possible.
The Future of OpEx vs. CapEx
This friction is vastly reduced, though, in a properly managed cloud environment. Tools can be used to automate resource instantiation and termination, even to the point where the application itself autonomously manages this process and no manual intervention is required. In this kind of environment, the "transaction cost" is so much smaller that "down and off" is much more viable.
Overall, the reduced operational transaction cost means that application operational models are going to change dramatically over time. In turn, this means that input assumptions to financial analyses will change as IT organizations begin to re-evaluate application resource consumption models. Many application designs will move toward a continuous operation of a certain base level of resource, with additional resources added and subtracted in response to changing usage. The end result will be that the tipping point calculation is likely to shift toward an asset operation model rather than an asset ownership one.
At the very least, it will reduce the presumption that the only financially viable approach is to assume full-time peak load resource operation, and therefore predetermine an asset ownership model by default.
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