Topics


Blogs


Forums


Samples


Media


Labs


Resources

 




DevCentral > Weblogs > Lori MacVittie - Two Different Socks
 Cloud is the Gift That Keeps On Giving
posted on Thursday, December 03, 2009 4:03 AM

Ultimately the CAPEX vs OPEX arguments over public and private cloud computing are irrelevant. Business-value is the only metric that really counts.

B


renda Michelson, Principal of Elemental Links, writes “elemental cloud computing” recently tweeted: “100k buys way more public, than private, cloud computing power” which started a short but inspiring conversation on the subject centering around the observation that “cloud is the gift that keeps on giving.” That’s alluding to the fact that the compute power purchased in “the cloud” is an annual expense, unlike private, cloud computing power which requires renewal at longer intervals, usually in the 3-5 year range.

Still, Brenda is right at least in the short term. $100,000 purchases a lot more compute power in a public cloud computing environment than it will/would/does in a private cloud computing environment. The problem is that $100,000 in a private cloud computing environment is likely to provide more business value than would a comparable investment in a public cloud computing environment. And that’s really the metric we should be using instead of CAPEX versus OPEX.


THIS IS NOT ABOUT CAPEX vs OPEX

I have read, and re-read, and read some more on the whole “CAPEX vs OPEX” arguments both for and against public cloud computing. I started off by reading JP Morgenthal’sA Better Metric for Analyzing the Value of the Cloud”. But that led me to digging deeper as it became apparent that my decision to focus on computer science in graduate school rather than economics and accounting was getting the way of understanding the real debate regarding CAPEX vs OPEX. Bernard Golden, CEO of consulting firm HyperStratus, nearly convinced me that public cloud computing is the only financially responsible option in “Capex vs Opex: Most Miss Point About Cloud Economics”. Stratetect argued basically the opposite in “CAPEX vs OPEX. What is the difference?” and thus sent me into a rousing debate with myself (I’m still unsure who won that one). I finished up with a quick read of “CapEx, OpEx and Cloudy Accounting” over at Data Center Knowledge because, well, I’m masochistic, apparently.

I finally came to a few conclusions:

  • 1
  • I can explain to you why some CAPEX spending can actually lead to a decrease in overall CAPEX spending but not whether it’s desirable to do so. For example, an investment in an application delivery controller can result in higher VM density capabilities per physical server, the result of which is less CAPEX required to purchase physical servers to meet annual growth (and a reduction in the associated OPEX, I might add). Whether this reduction in CAPEX is good or bad seems to be somewhat of a subjective opinion and one I am apparently not well-versed enough in accounting to make.
  • 2
    Investing in public cloud computing increases OPEX (cost of services) while simultaneously decreasing OPEX (offloads maintenance/management of physical servers, decreases costs associated with datacenter space). Whether the increase is good/bad/desirable is also somewhat of a subjective opinion and open to interpretation. I guess the trick is to try to make sure the decrease in OPEX is greater than the increase, thus resulting in an overall decrease. Bernard Golden insists part of the appeal of public cloud computing is in the ability to just “stop using resources” because it isn’t a fixed cost. I disagree that it isn’t a fixed cost; it’s rare you’re suddenly going to not need compute resources, but his argument has merit as a reason why increases in OPEX are more easily dismissed as an argument against public cloud computing.  
  • 3
  • There’s no good answer to the CAPEX vs OPEX debate. CEOs, CIOs, CTOs, and financial folks all seem to disagree when it comes to cloud computing and costs. In fact I’m wondering at this point whether cloud computing and its impact on the balance sheet might force a change in the equations financial analysts use to value companies. If it’s not as simple as “high OPEX bad and more CAPEX good” then perhaps the “economics” of cloud computing will have broader implications than just for technology, IT, and organizations. But for IT and technology-focused individuals rather than focusing on whether one approach is desirable over another we should – or at least I should - probably just stick to explaining how a given solution decreases/increases CAPEX/OPEX and leave the analysis to someone better suited to the task.

Ultimately I think there’s no good answer that can come – at least authoritatively - from an outside source. The only person suited to answering the question of whether increasing OPEX by leveraging cloud computing or investing in the CAPEX necessary to leverage private cloud computing is the one sitting in the CTO/CIO chair. Then I reached another conclusion: we’re ignoring the very basic question of the business-value offered by each approach. Focusing in on CAPEX or OPEX or X-EX is not nearly as germane as asking “What’s the business value an organization is getting when they write that $100,000 check?”


A LINE in the CLOUD

I do agree with Brenda that $100,000 will purchase a lot more compute power in a public cloud computing environment, it is important, I think, to consider the business value of those resources may be far less than if that $100,000 were invested in the servers and infrastructure necessary to implement a private cloud computing environment.

This is primarily because of the way in which those resources can be used.

  1. They are dedicated. I know this sounds contrary to the cloud computing model, but consider for a moment then when you deploy an application in a virtualized container in a cloud computing environment that the resources allocated for that application are dedicated to that application. You can’t share those resources with another application. Sure, you can spread that $100,000 around many applications, but then you’re limiting the amount of resources that each application can ultimately consume. If you’re investing in physical assets (servers) for a private cloud implementation the compute power you’ve essentially “purchased” can be shared across many applications, even after the application is retired.
  2. Infrastructure can’t be shared. If you’re provisioning infrastructure services in a cloud computing environment those resources can’t be shared with the applications residing in your local data center. That means they are essentially dedicated infrastructure for the purposes of serving only cloud computing deployed applications in a single location. Contrast this with infrastructure deployed in the data center, whose services can be shared across all applications – legacy, web, and even virtual private cloud hosted applications.
  3. Refresh rates mean longer relevancy. Technology refresh rates typically range from 3-5 years. If $100,000 will purchase 3-5 years worth of compute resources, then this is a moot point. If that $100,000 will only provision compute resources in a public cloud computing environment for less than three years and you can purchase enough compute resources with that same budget for a private cloud computing environment, you’ve got some decision making to do.
  4. Private cloud computing has benefits public implementations do not. One of the tasks that goes into implementing a private cloud computing model is the codification of IT and business processes via automation and orchestration. That process affords a unique opportunity to re-examine the efficiency of those processes and streamline them, improving the efficiency of IT and, one hopes, the business supported by those processes. This is not as intangible as it sounds and can be measured based on standard labor costs and time to manually perform certain tasks as well as any time savings that may directly impact costs to acquire/retain customers.

The business value of the compute power you’re purchasing in a public cloud computing environment may be vastly different than the business value acquired for the same budget and directed toward a private cloud computing environment.

An even better option may be a hybrid model that leverages a virtual private cloud computing deployment along with a private cloud computing implementation. By using public cloud computing resources to extend a private cloud computing implementation you can continue to leverage existing – or new – investments for the private cloud implementation, the virtual private cloud implementation, as well as legacy and more traditionally deployed applications. The business value of compute resources is much higher when it’s shared in way as to serve more business needs and its relative cost decreases according to how well it can be applied across a broad spectrum of applications.

This is not a new equation for most IT professionals. Justifying both CAPEX and OPEX is something IT has been asked to do for many years; “bring us a business case” is the typical response to any request for funds. Certainly we should not stop providing the base information: this reduces OPEX, this CAPEX can be used for X because this needs to be used by the people who ultimately make the decision regarding which type of spending is best for their organization, but that’s not our call. So instead of worrying about which column of the financial ledger it is best for compute and infrastructure resources to come out of we should focus more on the business value we’re offering instead.

Follow me on Twitter    View Lori's profile on SlideShare  friendfeed icon_facebook

AddThis Feed Button Bookmark and Share

Related blogs & articles:



 
      

Feedback


12/3/2009 7:31 AM
Gravatar This post was mentioned on Identica by lorimacvittie: Cloud is the Gift that Keeps on Giving http://tinyurl.com/yfftsgk
uberVU - social comments

12/3/2009 9:35 AM
Gravatar Hi Lori,

I think you are on the right lines here. However (you knew there was one of those coming), we also need to think about the other business values, outside the pure monetary value.

Things such as flexibility, reduced knowledge requirements (you don't need to understand a virtualisation product, or know how to maintain specific hardware), and risk reduction are surely important business values?

The problem is how do we put all these values in a bucket, apply some metrics to it, then shake it up and come up with a measure of what is the solution that best suits organisation X?

Nick
FrintonBoy

12/3/2009 10:58 AM
Gravatar @Nick,

Of course there was a "however" coming. Always is...

"You don't need to understand a virtualization product." Wow. That really depends on the environment. If you are building/packaging your own virtual images, then you had better understand the product you're using. If you're acquiring a solution that is already virtualized in a package it had better be manageable via existing management systems. And flexible? Yes. But in what way? Flexibility is a broad term and while I know exactly what you're getting at I'd like to see it better spelled out because I think you're denying/attributing flexibility without really considering what that means to a real network and its components.

I think *we* don't. I think the customer does. I think we provide the base information and let them decide. That's one of the reasons we used to provide customizable, weighted "report cards" on products at Network Computing when we did reviews: so readers could change the weights to reflect what was important to them and figure out the best solution for their particular needs.

Lori
macvittie

12/4/2009 2:18 AM
Gravatar I always thought those "report cards" were brilliant. A much better way of getting the answer specific to your needs.

Most Cloud vendors have a very simple self-service front end. Which for the majority of customers will get the job done, pick a Jumpbox or similar Virtual Appliance and away you go. From that point on it's just like your traditionally built app servers.

Flexibility, ok, the ability to totally change your mind about what you are going to do and how you are going to do it, without incurring losses. That is pretty flexible. Yes the small scale moving things around on the fly etc are also good (but as you suggest have some management costs). Being able to tear it all up and start over in a totally different way in a totally different place is something only the Cloud can give you.

Don't get me wrong though, I am not saying one way of doing things is inherently better than the other. I just thought you had missed out a few things that may swing the decision in Cloud's direction. In the end though, we have to go back to that bucket of metrics and give them a shake...
FrintonBoy

12/7/2009 5:02 PM
Gravatar I partially agree with both of you. $100k a year is cheap if your business can handle it and ROI is there. Private cloud requires steep initial investment and if you hang with legacy hardware you have to retain bunch of engineers that can manage it. An engineer that can manage legacy hardware ADCs doesn't come cheap nowadays. I would venture it is in the range of $100k. On the other hand if you give some more power to developers that develop application to also develop logic on ADCs might be another story. Giving every developer its own playground where they have total control over their environment so they can try and test everything from their code to how it integrates and works with and behind ADC can be a task on its own. So you have three choices. Either use shared environment (still substantial cost involved to purchase and maintain development environment that includes ADC developers can play with), use cloud options with either limited options (not really an option if one wants to develop network side logic) or cloud compatible software ADCs at cost per hour or whatnot that cloud provider charges. Last option is to just run everything on developers workstation/laptop with free fully featured ADC.

Flexibility is there, it is for the user to fill in those report cards and put some weighting in it and shake it up and see what it comes out.

BTW: Word on the street is that software ADC is coming from F5 someday. Wonder if this will change the game and tune.
Izzy

12/8/2009 2:33 AM
Gravatar @Izzy

There's more to an infrastructure than just ADCs. There's also switches and routers and security devices and WOCs and bandwidth management and a variety of other "legacy" hardware devices, many of which will never be provided in virtual form for any number of reasons.

I agree with your commentary re: developers and application logic. For testing/development, putting an ADC on their desktop is yes, a great idea, and I am all for that. But a 1:1 ratio between apps:adcs in a production environment would be both expensive and inefficient.

Word on the street is correct; someday being "the near future". It won't change my tune; I've said many times - developers and evaluators need the ability to play/test/evaluate more easily and a SoftADC addresses that need quite nicely.

Lori

macvittie

12/8/2009 3:24 AM
Gravatar Also, Izzy - I am truly offended by the implication that what I write is purely marketing driven and that my opinions, which is what this blog represents, will be somehow magically changed by the existence of a SoftADC. This is not the first time you've left a comment on a post containing such an implication.

What I write and when I write it is driven by one person: me. The only time there is external input is during a launch, and that goes only as far as incorporating new features/products/etc... and understanding what the corporate goals are for that launch as far as what the benefits/capabilities of new products/features may be. See "The Application Delivery Spell Book: Contingency" as an example of what I mean. This was driven by new iRules capabilities in our web application firewall, ASM, but it says absolutely nothing I haven't said before - nor anything with which I do not earnestly believe.

While this is no doubt a natural assumption given this is an F5 property and I am an employee - especially by someone who is part of a competitor's marketing engine - it is still incorrect and because this is the second time you've made such a comment I am responding to it. One of the reasons I truly enjoy working for F5 is I am never asked to compromise my opinion/thoughts on technology for the sake of "marketing". If my opinion would somehow damage or negatively influence a SoftADC offering - or any other product offering for that matter - I will simply not write on the subject.

Am I biased toward F5's solutions? You bet. Am I blindly supportive of every technology/decision made? Of course not. And I will not pen a single word that implies I agree with something when I do not or that isn't accurate to the best of my knowledge/ability. I have never done so in any role/position in the past and I am not about to start now.

Lori
macvittie
 Leave Feedback
Title  
Name  
Email
Url
Comments   
Please add 1 and 7 and type the answer here: