How do You Know When Going into the Public Cloud Makes Financial Sense?

Much is being written about (public) cloud computing and its financial benefits. Typically, quantified benefits arise from more efficient server utilization and reduced power consumption, as well as from the ability to manage more server capacity with existing IT resources.

Other, commonly cited benefits – however, more difficult to quantify – arise from the ability of cloud computing infrastructure to flexibly serve as “surge protection”, as well as rapid prototyping / launch hosting infrastructure.

We find that many of these analyses, while correct, paint too narrowly focused a picture. For example, a justification for a cloud computing infrastructure only based on power and hardware savings, leaves out other significant cost savings.

Here are a few observations that should guide any attempt at quantifying the costs and benefits of a cloud computing infrastructure:

1) Calculating cloud computing financial benefits requires “ROI modeling” (vs. simpler TCO modeling) to model revenue impacts from time to market and customer satisfaction effects

    • Time to market acceleration and the ability to scale with relative ease are typically THE key advantages of cloud infrastructures, and thus should be modeled
    • Simpler TCO comparisons additionally struggle with other vital parameters and cost drivers, e.g. SLAs, security and regulatory requirements, or implementation costs

    2) Model ROI at the locus of a cloud adoption decision

      • I.e. model the financial benefits accruing to the purchase decision maker (who may be a mid-level manager, vs., say, a corporate officer) and who may not be interested in 40,000 ft, company-wide efficiencies

      3) A credible and accurate ROI model of any hosting infrastructure setup needs to start with a complete accounting of all types of costs

        • Hardware, software licenses, labor costs (external and internal), training, startup and ongoing costs, opportunity costs (e.g. security, brand damage, lost revenue), as well as hidden costs need to be modeled

        4) Separate “Hard ROI Savings” from “Soft ROI Savings”

          • “Hard ROI Savings” pertain to initial, direct cost savings only (i.e. “cash in or out”)
          • “Soft ROI Savings” include hard savings plus revenue (e.g. time to market) effects as well as opportunity costs

          Having thoroughly collected all costs as described above, the next step then is to capture the system architecture and associated cost parameters of a particular public cloud computing setup, and compare it to an on-premise / in-house setup that has similar performance and capabilities.

          Thus comparing revenue effects requires contrasting an on-demand setup’s variable (i.e. volume dependent) pricing to on-premise variable costs to quantify a cloud computing setup breakeven cost as a function of usage volume. Since the variable cost of an on-premise setup is typically lower than the variable pricing of a public cloud setup with variable pricing, this means that above some breakeven volume, public cloud setups will inevitably cost more than dedicated, cost-optimized, on-premise hosting setups.

          I.e. it is not always clear cut where the advantage my lie from going to a public cloud computing setup vs. staying with in-house or on-premise resources. A commonly applicable rule of thumb following from the above deliberations is that when computing demand is highly variable, when time to market is a premium, and/or when the service life of a to be hosted service in unknown, going onto a public cloud setup makes a lot of sense (assuming security and other “RAS” requirements can be met). Conversely, for cost-optimized, steady-state, large volume services, it usually makes sense to continue managing such services in-house if costs and continuous improvement can be optimized over time.

          Leave a Reply

           

           

           

          You can use these HTML tags

          <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>