Hourly costs are easy to understand, but companies using cloud infrastructures have to look at making a decision on when to have an on-demand instance vs agreeing to a reserved instance and committing to a time period.

 The picture below shows the example of one such case illustrating the cost of a Database.
 
 <figure class="my-8">
 <img src="/blog/cloud-economics/fig-1-reserved-database-pricing.png" alt="Reserved database pricing over one- and three-year terms" class="w-full rounded-xl border border-border" />
 <figcaption class="text-sm text-muted-foreground mt-3 text-center">Figure 1. Reserved database pricing over one- and three-year terms, with effective hourly rates and the savings each commitment buys against on-demand.</figcaption>
 </figure>

 At a first glance it becomes obvious that a 3 year term has the least cost per hour with over 65% savings. However this is not as simple as that. Unlike on-demand instance pricing, reserved instance pricing is not an hourly price but more or less a yearly price or a three year price. The &ldquo;effective hourly&rdquo; price shown is assuming that the server runs the full 8760 hours in a year.

 Cloud instances however can be provisioned to switch on and switch off. In-fact for most infrastructure teams, it is an unstated assumption that databases are always up and running and only brought down for maintenance reasons in short windows. With hourly pricing there is a lot of incentives to shut down the server and increase the server downtime to minimize costs. The cloud infrastructure also makes it easy to manage the down time by automatically shutting down a server and then bring it back up based on a pre-determined schedule.

 We will examine how the annual database costs change for an on-demand server if the following downtime schedules are maintained.
 
 <figure class="my-8">
 <img src="/blog/cloud-economics/fig-2-cloud-server-downtime-schedule.png" alt="Cloud server downtime schedule options" class="w-full rounded-xl border border-border" />
 <figcaption class="text-sm text-muted-foreground mt-3 text-center">Figure 2. The downtime schedules modeled here, from a nightly shutdown to full weekend and holiday shutdowns.</figcaption>
 </figure>

 When we compare the database server on-demand costs for the different downtime schedules against a 1 year reserved instance cost we find that a downtime schedule D365_H12 or D261_H18 can reduce the cost below the 1 year reserved term.
 
 <figure class="my-8">
 <img src="/blog/cloud-economics/fig-3-on-demand-vs-1-year-reserved.png" alt="On-demand annual cost vs one-year reserved terms" class="w-full rounded-xl border border-border" />
 <figcaption class="text-sm text-muted-foreground mt-3 text-center">Figure 3. On-demand annual cost under each downtime schedule, set against the one-year reserved terms.</figcaption>
 </figure>

 We also find that tweaking the downtime schedule also compares very favorably to a three year term as well.
 
 <figure class="my-8">
 <img src="/blog/cloud-economics/fig-4-on-demand-vs-3-year-reserved.png" alt="On-demand annual cost vs three-year reserved terms" class="w-full rounded-xl border border-border" />
 <figcaption class="text-sm text-muted-foreground mt-3 text-center">Figure 4. The same on-demand schedules measured against the lower three-year reserved rates.</figcaption>
 </figure>

 Through creative use of downtime that meets the business needs can not only reduce the costs but businesses can add more flexibility by choosing on-demand instances for their infrastructure planning.
 
 <figure class="my-8">
 <img src="/blog/cloud-economics/fig-5-projected-annual-savings.png" alt="Projected annual savings by operating window" class="w-full rounded-xl border border-border" />
 <figcaption class="text-sm text-muted-foreground mt-3 text-center">Figure 5. Projected annual savings against a 24x7 baseline as the daily operating window tightens, for a $100K per month workload.</figcaption>
 </figure>

Optimizing Infrastructure Costs

IT is not always a cost center, especially when it is instrumental for revenue. Several companies today make money by providing digital goods and services all of which run on an IT infrastructure and Infrastructure costs are more similar to the Cost of Goods in companies that sell a physical product.

 In such companies understanding the costs per transaction may make more sense than just looking at the hourly costs of infrastructure. Scaling adjustments could be done to ensure that when there is less load reduce the number of active servers and possibly have an advertised downtime when the site is not available.
 
 <figure class="my-8">
 <img src="/blog/cloud-economics/fig-6-cogs-for-digital-goods.png" alt="COGs for digital goods infrastructure stack and transaction costs" class="w-full rounded-xl border border-border" />
 <figcaption class="text-sm text-muted-foreground mt-3 text-center">Figure 6. A simple digital-goods stack and its costs: a flat $395.04 per day that is cheap per transaction on weekdays and ruinous on a low-volume holiday.</figcaption>
 </figure>

 In the picture above we can see that the costs per day are a uniform $395.00 but when we look at the cost per transaction we see that it costs more on the weekends and is exorbitant on holidays. This begs the question, why do we need an application that is available 24 x 7 x 365.

COGs for Digital Goods

Data is very important especially when designing software. We make several assumptions on the type of data the software will handle. When the data violates these assumptions not only can the software visibly fail, in other cases unexpected situations could arise which may be more severe. Yet creating data sets to adequately test software is usually the last thing on everyone&rsquo;s mind.

 With the cloud making the cost of infrastructure more transparent it will not be long when IT will be tasked not just to create applications that meet the business needs but also are transparent enough to monitor the cost per transaction. With transparency there will also be an added requirement to design applications that have low transactional costs.

 In such situations data becomes all the more important not just in the amount of data but how the data is distributed to test the functional requirements but also the temporal distribution. Let me explain with an example. For example if we are building an e-commerce application of some kind that sells a digital product that costs $x to make or buy. This digital product would have to be stored and then retrieved and fulfilled during the order transactions. If more customers order within a given time period then more computing power and bandwidth is required to service these customers and if less customers order within a given time period less computing power and bandwidth will be required.

 If we assume that the application is built on the cloud then it is assumed that the application architect has leveraged the elastic nature of the cloud to automatically scale computing capacity based on the number of customer requests in real time. If we assume that the operating margin is less than a dollar per transaction that is fulfilled, saving a few cents on the transactional costs can make a difference. It is therefore necessary to understand how the costs of the application changes as the time distribution of orders changes.
 
 <figure class="my-8">
 <img src="/blog/cloud-economics/fig-7-simulating-data.png" alt="Simulated cost per transaction across order volume and time" class="w-full rounded-xl border border-border" />
 <figcaption class="text-sm text-muted-foreground mt-3 text-center">Figure 7. Simulated cost per transaction across order volume and arrival timing, the surface a team needs in order to see where a transaction stops paying for itself.</figcaption>
 </figure>

 The graph above shows such an example where by simulating orders that hit the e-commerce application at different rates and how the costs differ with the volume of transactions as well as the rate of transactions. In other words not only do we have to simulate Order Data with different attributes like number of order lines but also has to be simulated across time.

 The graph in the picture above shows how a simulated test data that varies across time can help populate the transactional costs against three dimensions, Cost / transaction, Time and Order volume.

Data Simulation for Understanding Costs

We never know the future, and in a way for our decision making we have to deal with the uncertainty of the future. One way to deal with this uncertainty is by looking at the pay off matrix.

 The concept of pay off matrix is nothing new, we actually use it atleast when we do our financial planning or retirement planning. Individual Financial planning is one case where we do look at different eventualities where the financial planner uses a monte-carlo simulation to look at how a portfolio may perform over the long run under uncertain markets. Simply put the Monte-carlo simulation is creating around 1000 futures and then picking the best and the worst future to display.
 
 <figure class="my-8">
 <img src="/blog/cloud-economics/fig-8-planning-for-the-future.png" alt="Planning for the future as a fan of possible outcomes" class="w-full rounded-xl border border-border" />
 <figcaption class="text-sm text-muted-foreground mt-3 text-center">Figure 8. Planning as a fan of possible futures rather than a single forecast, the idea a Monte Carlo simulation puts to work.</figcaption>
 </figure>

 While a similar monte-carlo simulation is not possible in every situation, we definitely can create 1000 or more futures to evaluate how our decisions will play out.

 Business decision makers may find it helpful if they could understand the implications of their decisions under several 1000 future states and understand the impact of their decisions. Let us look at a few such decisions.

 A retail chain would like to evaluate two to three pricing and promotion plans that will be in effect for the next quarter. They would like to understand how the profit would be impacted based on the future described by # of customers who walk in to the store, the percentage who use store credit cards, the percentage who use other credit cards, amount of mail in rebates exercised etc.

 Sales Compensation plans would need to be tested with three different territory structures that are being evaluated. The cost of sales compensation as a percentage of revenue would need to be evaluated against a future that would be described by sales turnover, quota achievements, demand for the product etc.

 In both the above scenarios the future is described by more than one variable some of which may be correlated, but each of them have their own range, resulting in a future state that could be described as the combination of these variables.

 Let me explain with a more concrete illustration of the above two scenarios:

 For the retail scenario, we know that the number of customers who walk into the store are on the average 30 per day in the past year, but we have seen this varying between 25 to 38 in the past ten years. Similarly we know that store credit card usage is a function of the number of people who signed up in the past six months, but this function has a parameter that varies within a certain range. Similarly we also know the average proportion of other credit cards differentiating them solely by the cost per transaction of each credit card.

 For the sales compensation scenario, we know the sales achievement against quota lies between a certain percentage for each sales rep based on historical performance. However if the quota increases then this percentage

 By using simple stochastic models we could vary the future description automatically within that range with an option of varying each variable with a particular statistical distribution to make sure that the resulting data has the same randomness that could be seen in real life. This is the same idea as the Monte Carlo distribution used by Financial planners.

Planning & Decision Making in Business

Note: A version of this post has been published under the title &ldquo;Pay-as-you-go IT: CFO&rsquo;s dream and a CIO&rsquo;s nightmare.&rdquo; This version has a few extra graphs that are not in the other article.

 <h2>Introduction</h2>
 As the nature of business becomes more &ldquo;digital&rdquo; a pay-as-you-go Consumption based IT cost model is likely to emerge as a major disrupter to the traditional view of IT as a Capital Expenditure. The authors investigate some of the drivers for this shift; how it is likely to play out in the board room and the approaches which can be used to make this disruption a positive one for the corporation.

 <h2>Synchronicity of IT Spend with Corporate Revenue</h2>
 As we look at the IT&ndash;Business interaction from a strategic perspective esp. as it relates to the cost/funding dimension (manifested in the annual and long term budgeting exercises and periodic cost-reduction initiatives) we see one of the basic issues as &ldquo;synchronicity&rdquo; &ndash; How can IT spend be more closely aligned with the ebbs and flows of the business revenue stream?

 In many large corporations this issue also impacts the IT long term vision of transitioning to a simplified, streamlined end-state architecture (vis-&agrave;-vis the convoluted mish-mash of legacy applications which generally exists) as the business becomes increasingly wary of making the large investments required to drive the necessary changes as their own revenue projections fluctuate. In fact in some cases the large IT investments seem to be paying off at least initially but as time progresses the IT cost increase is far more disproportionate to the revenue increase.
 
 <figure class="my-8">
 <img src="/blog/cloud-economics/fig-9-revenue-vs-it-spend.png" alt="Revenue vs IT spend over time under a pay-as-you-go usage model" class="w-full rounded-xl border border-border" />
 <figcaption class="text-sm text-muted-foreground mt-3 text-center">Figure 9. Under a fixed-investment model IT spend eventually outruns revenue; a usage model keeps the two in step.</figcaption>
 </figure>

 <h2>Pay-as-you-go (Usage Model)</h2>
 From a CFO perspective, then, a pay-as-you-go model seems very attractive. In the most simplistic configuration all applications will be hosted in the cloud with business users being charged based on the actual consumption of resources.

 Rather than implementing any major platform initiative in-house with its associated fixed costs (Capex), technology vendors will be required to provide the desired capabilities as a consumption based service (Opex). Technology products if built in-house can be done so using the pay-as-you-go resources from a cloud vendor. These capabilities can also be leveraged to evaluate the feasibility of the product from a business perspective and to pilot risky projects without significant budget commitment. This shifts the initial fixed investment outlay into smaller outlay paid every month based on the usage.

 Another key premise is that since the vendor will be leveraging economies of scale over a larger user base they will be able to drive the costs down significantly more than if the company would be able to do hosting applications in-house.

 <h2>IT Supply Chain &ndash; Digital Products</h2>
 The nature of the products and services offered by corporations are also dramatically changing with the &ldquo;digital&rdquo; component becoming a key part of the offering and value proposition for the customer. For example a traditional product may now be bundled with a digital service enabling customers to access and store content. IT processes and infrastructure will play a role in securing the digital files, storing them and enabling access to these files.

 As a result the IT infrastructure component of the cost of the offering needs to have a more direct alignment to the total cost rather than just be an allocation of a fixed charge. In essence since IT infrastructure is essentially becoming the digital supply chain for the offering and as for any conventional product, the supply chain costs have to be in alignment with the revenue for the product.

 <h2>The CEO&rsquo;s Viewpoint</h2>
 Couple this with the growing CEO perspective that most of IT spend is &ldquo;non-differentiating for the business.&rdquo; They also realize that as their business becomes more &ldquo;digital&rdquo; creating and securing their digital assets is critical to maintaining the corporate reputation. As IT spend is growing CEOs would like to demand more out of it. And they would definitely like more accountability and transparency about the burgeoning expenses. A granular Pay-as-you-go cost model creates more transparency in what the &ldquo;non-differentiating&rdquo; portions of IT are costing on a per transaction or a per user basis.

 <h2>The CIO&rsquo;s Dilemmas</h2>
 Not many CIOs have climbed this bandwagon though. Some of their wariness comes about because of the security implications of moving everything off-premises and also from the viewpoint of looking at the historical investments in-house IT infrastructure and data-centers as a sunk cost. Economists would argue that the sunk-cost dilemma is moot, per the &ldquo;bygones principal&rdquo; only the &quot;extra&quot; or &quot;marginal&quot; costs and benefits of every decision need to be evaluated. Ideally the past costs should be ignored and the future costs and benefits taken into consideration when making such a decision: A hard-headed calculation of the extra costs one will incur and weighing them against extra advantages. But this is most easier said than done. Also, what many times gets ignored is that while the one-time cost of implementing an application or building an infrastructure may have been &ldquo;sunk&rdquo;, there are associated recurring costs &ndash; licensing, electricity, manpower etc. which are very much real and need to be factored in.

 CIOs are also not yet fully sold on the idea of a pay-as-you-go or Consumption based IT cost model being as &ldquo;variable&rdquo; as it is touted to be. The likelihood of vendors introducing some &ldquo;fixedness&rdquo; (start-up charges, launching charges, termination fees etc.) to the mix looms large. In some cases vendors have begun allaying the fears by agreeing to abstain from any &ldquo;fixed&rdquo; components in their cloud offerings. They also fear that their organization may not have the clout to motivate vendors to move to such an opex model. But that is likely to change as increasingly larger number of companies demand something similar.

 CIOs have to worry about their in-house legacy applications too. The ones that cannot be hosted outside for a myriad of reasons. They can be though moved to private clouds &ndash; changing from &ldquo;fixed charge allocation to business&rdquo; cost model to consumption based usage charges. And then, what about the vendors who are not able to offer their capabilities as a cloud hosted subscription/usage based solution? Multiple vendors collaborating to resolve this is an option &ndash; one provides the application and other the cloud access.

 <h2>Driving the Costs Down</h2>
 This brings us to another very important point. While organizations may not be ready to move to a pay-to-go-model yet there is still a considerable opportunity to leverage the model to drive IT costs down. In the absence of a consumption based &ldquo;tariff&rdquo;, a &ldquo;Tragedy of the Commons&rdquo; kind of scenario plays out where a shared common resource is inefficiently or sub-optimally utilized, somewhat like the scenario where free electricity or water leads to more waste and a lesser incentive to conserve. Currently IT cost reduction initiatives are generally periodic percentage cost reduction targets emanating from Corporate Finance or Business Leadership. IT generally responds by chipping away at cost elements to the best it can.

 <h2>Transactional Cost Modeling for a Pay-as-you-go Approach</h2>
 If organizations choose to move to the cloud or embrace a public cloud vendor or have everything on an in-house cloud, it is essential that they embed transactional cost modeling into the design of the IT solution or product. In this approach the IT architecture is used as a basis to model all the cost elements associated with the application. Even legacy applications can be modeled as if the applications were hosted on a private cloud and then can be benchmarked against the rates quoted by cloud providers like Amazon Web Services or Microsoft Azure for the same capabilities. Business users can be exposed to this cost comparison as an element of a &ldquo;Go Out vs. Stay In&rdquo; decision making.

 The rigors of such a cost modeling exercise will also expose the business to discrete elements of IT costs which have hitherto remained hidden in larger silos. For example the cost associated with an IT solution or an application is not just the cost associated with the Production infrastructure. Even the Development and Test infrastructure that is used needs to be counted towards the operational cost of the application. If the company doesn&rsquo;t have an offshore team or only works in two shifts then the development instances can be operational only during the actual hours of working reducing the number of hours in a year from 8760 to 2008 hours a reduction of over 75%.

 Even production applications do not have to necessarily operate outside a time window and by building a flexible downtime capability within the application, one can schedule downtimes to minimize the costs outside the window of operations.

 <h2>Conclusion</h2>
 Failure to recognize the pay-as-you-go IT model as a platform disrupter can be very detrimental for organizations. The successful ones will leverage the trend to drive down costs and will reap the benefits. Adoption of the model does not need to be a revolutionary change as organizations can follow a more evolutionary approach by first focusing on it as a mechanism to get a better understanding of their own IT costs and endeavor to make them more &ldquo;variable&rdquo;, truly reflecting the demand patterns.

COGs for Digital Goods

Ready to Transform Your Business?