Looking beyond basic cloud economics: Part Two

In Part One of this series, we examined the idea that economics in relation to moving to cloud goes a lot further than savings on hardware costs. Here in Part Two, we’ll take a look at the advantages. According to NIST a key tenet of true cloud computing is elastic consumption. This not only provides the ability to burst beyond a baseline of computing power, but also offers the potential to reduce costs by reducing baseline spend.

Savings are most acutely realized where unit costs are highest, or something with a small unit cost is used extensively. It’s therefore arguable that databases, especially commercial closed source software such as Oracle, are a prime candidate when we look at cost optimization and I will use this as our illustration for this point.

The following illustrates how elastic consumption of a database in a license included model can help significantly reduce annual costs compared to a traditional license/BYOL model. For the avoidance of doubt, the models below do not only apply to Oracle’s Autonomous Database options but also the ‘traditional’ Oracle RDBMS that remains many customers’ preferred choice.

Traditional model

• Hardware and associated Oracle licenses are procured to cope with the projected peak workload, with associated Capex costs and budget for ongoing annual support costs.
• The compute ‘shape’ will then be fixed to the license allowance—there is little to no benefit in reducing compute sizing as you’ve already paid for the license for this shape, and the software cost is typically substantially higher.
• The annual Oracle support cost is fixed, and in many cases will increase based on inflation linking.
• If the encountered peak workload is greater than the capacity of either the compute provisioned or the license requirement, the system will encounter performance constraints.
• During normal non-peak operations, the base cost is still fixed for peak.

Elastic model

• Baseline database computing can be set to the ‘shape’ required for normal non-peak workloads, which in many cases will be substantially smaller than peak. Indeed for applications that are only required during business hours, the service can be scheduled to be shut down/quiesced outside those hours.
• The license cost, which includes additional options like encryption and diagnostics, is reduced to reflect this lower baseline.
• The system scales at peak times (automatically, on a scheduled basis, or manually) to meet the required capacity—providing a more dynamic compute threshold than the traditional model. This better allows the system to deal with both expected and unexpected surges.
• As cloud providers increase maximum compute sizes and integrate the latest CPUs and IO, the ability to consume additional resources, and hence cope with larger peaks, also becomes a reality.
• Once the peak passes, the system scales back down to free up resources and reduce the ongoing cost. Conversely, this also allows the cost model to change in the event of negative pressures on demand, such as the pandemic.

In the illustration below, we show how elastic capacity allows us to meet, and surpass, a typical static configuration sized for peak, as well as reducing spend over the course of the year. The peaks shown are purely illustrative as the dynamic capacity will be specific to your own workload. Throughout the period, the average utilization, and therefore cost, remains significantly below the static consumption sized for peak.

Disaster Recovery (DR) is often a significant beneficiary of elasticity

An often-overlooked area of cost reduction in Oracle Cloud vs other solutions is that of DR.

By using the elastic compute and licensing solution, you can maintain a pilot light DR model, where the DR site location is maintained at minimal CPU count with associated licenses as required.

In the event of DR ever being invoked, the system is then scaled up to provide full capacity. But during regular operations, you have eliminated all idle capacity and associated licenses.

Where a traditional co-location or cloud adjacent model is deployed, it is typical to pay for idle capacity that is hopefully never used. With ever increasing power costs, this also presents a benefit in the reduction of idle hardware capacity, which still consumes a significant amount of power and is therefore arguably a sustainability improvement.

In many cases, the overall footprint reduction gained by using an elastic PaaS database, coupled with a move to the latest CPUs, networking and IO provided in the cloud, gives organizations the chance to look again at their entire Oracle estate, which perhaps appeared to be static and fixed previously. This empowers them to renegotiate the terms of their agreement, and we have often seen this cost reduction entirely fund a cloud migration project.

In the next part of this series, we look at the various opportunities for operational efficiencies latent in a move to cloud infrastructure.