Controlling Costs in the Cloud for High-Availability Applications

Page 1 of 3 next >>

Bookmark and Share

Shortly after contracting with a cloud service provider, a bill arrives that causes sticker shock. There are unexpected and seemingly excessive charges, and those responsible seem unable to explain how this could have happened. The situation is urgent because the amount threatens to bust the IT budget unless cost-saving changes are made immediately.

This cloud services sticker shock is often caused by mission-critical database applications, as these tend to be the most costly for a variety of reasons. These applications need to run 24/7. They require redundancy, which involves replicating the data and provisioning standby server instances. Data replication requires data movement, including across the wide area network (WAN). And providing high availability can result in higher costs to license Windows to get Windows Server Failover Clustering (versus using free open source Linux), or to license the Enterprise Edition of SQL Server to get Always On Availability Groups.

Before offering suggestions for controlling costs in the cloud, it is important to note that the goal here is not to minimize those costs, but instead to optimize the price/performance for each application. In other words, it is appropriate to pay more when provisioning resources for those applications that require higher uptime and throughput performance. It is also important to note that a hybrid cloud infrastructure—with applications running in whole or in part in both the private and public cloud—will likely be the best way to achieve optimal price/performance.

Understanding Cloud Service Provider Business and Pricing Models

The sticker shock experience demonstrates the need to thoroughly understand how cloud services are priced. Only then can the available services be utilized in the most cost-effective manner.

All cloud service providers (CSPs) publish their pricing, and unless specified in the service agreement, that pricing is constantly changing. All hardware-based resources, including the physical and virtual compute, storage, and networking services, inevitably have at least some direct or indirect cost, which are all based to some extent on the space, power, and cooling these systems consume. For software, open source is generally free, but all commercial operating systems and/or application software will incur a licensing fee. And be forewarned that some software licensing and pricing models can be quite complicated, so be sure to study them carefully.

In addition to these basic charges for hardware and software, there are potential á la carte costs for various value-added services, including security, load-balancing, and data protection provisions. There may also be “hidden” costs for I/O to storage or among distributed microservices, or for peak utilization that occurs only rarely during “bursts.”

Because every CSP has its own unique business and pricing model, the discussion here must be generalized. And, in general, the most expensive resources involve compute, software licensing, and data movement, which can together account for 80% or more of the total costs. Data movement might also incur separate WAN charges that are not included in the bill from the CSP.

Storage and networking within the CSP’s infrastructure are usually the least costly resources. Solid state drives (SSDs)normally cost more than spinning media on a per-terabyte basis, but SSDs also deliver superior performance, so their price/performance may be comparable or even better. And while moving data back to the enterprise can be expensive, moving data from the enterprise to the public cloud can usually be done cost-free (notwithstanding the separate WAN charges).

Formulating Strategies for Optimizing Price/Performance

Here are some suggestions for managing resource utilization in the public cloud in ways that can lower costs while maintaining appropriate service levels for all applications, including those that require mission-critical, high uptime and throughput.

Page 1 of 3 next >>