Cost is an often-cited reason for adopting public cloud, but ask IT pros about their preferred cloud deployment...
model and most say hybrid. But splitting workloads between private and public clouds complicates both the design and cost analysis.
The 2016 RightScale State of the Cloud survey reported 71% of respondents use both public and private clouds. Up from 13 points from the past year, these organizations aren't necessarily hybrid cloud users, but multi-cloud. Cost isn't the only, or even primary element when allocating cloud resources among service providers, but it is an important one. The distinction between the private and public cloud is important as cost is a key factor in determining usage; emphasizing an understanding of cloud costs is critical when developing a hybrid cloud strategy.
Comparing public and private clouds can be trickier than discussing public cloud cost modeling and cloud application development costs. This is because the models have different variables. Private cloud is heavy on CapEx and personnel -- both of which are fixed costs, at least over the medium term -- and public cloud is primarily OpEx -- which conversely is primarily a variable cost, over either the short or medium-term depending on the cloud subscription model.
Another wrinkle in the cost model is the type of hybrid architecture, which is related to the type of workloads deployed and IT's overall goals. There are several ways to employ a hybrid design including:
- Backup and disaster recovery (DR), where the primary infrastructure for an application is generally on private, often on-premises infrastructure that is replicated to an infrastructure as a service backup in case the primary fails.
- Test/dev versus production, in which applications are developed and tested in one environment, typically public cloud, and deployed in another, usually private.
- Cloudbursting is a model closest to the hybrid car analogy, where the baseline workload is provided by one environment, often private cloud, with peak workloads handled by the other, public cloud in this case. A wrinkle on the cloudbursting model is the dynamism of the workload. Some change slowly and predictably, such as seasonal variations in e-commerce platforms and monthly or quarterly workload peaks on financial systems. Other applications can be much more volatile, changing based on unexpected social network activity, media mentions or software updates that attract new users. Workload predictability influences the infrastructure architecture and choice of cloud services and hence the cost.
Cost model basics: Parameters
Cost models comparing cloud deployments differ: private cloud focuses on amortized CapEx, like a TCO model, while public cloud emphasizes ongoing OpEx. The parameters are mostly the same regardless of the hybrid design, with the differences on the public cloud side of the equation where the various scenarios will drive choices on the services used and subscription model. We'll note these nuances below.
Analyzing private cloud costs means treating private infrastructure as a rentable service, even if IT hasn't adopted service-based billing. A fair comparison between private and public infrastructure requires reducing costs to a common metric, typically dollars per month per standardized unit of consumption. The actual units, however, are debatable. One can measure the total cost to run a particular application, which uses multiple servers, databases and storage, or more granular measures of units of consumption such as a standard virtual CPU or GB of block storage. Public clouds use the latter approach, but the former, calculating the cost per application, is easier.
Turning fixed capital and personnel costs into a measure that can be compared means calculating the cost for a known workload or capacity and normalizing to a rate per unit time, for example, the cost per high-performance CPU or core per month or the cost per gigabyte of block storage per month. Common cost parameters include:
- Capital cost per standard server of a given CPU and memory performance. This should subtract out server-side storage -- if applicable -- and treat it as a separate storage cost. These should be amortized over the equipment life.
- Capital cost per central storage system or the usable portion of storage on compute servers, per unit of capacity. Costs for storage with significantly different price per capacity measures, such as block, file or object, and flash, should be broken out individually and amortized over the equipment life.
- Personnel cost to manage each server or storage array, which is a function of the number of admins per system and fully loaded salary. Again, the cost should be normalized to a monthly, weekly or daily rate depending on how granular one wants to model.
- Management software licenses not included in the capital costs. If different tools are used for various types of equipment, these should be allocated separately and again normalized to a standard rate.
- Overhead costs, including facility construction and rent, utilities, power and network distribution equipment, and more, that are uniformly apportioned to all equipment. Useful allocation units include per square foot, rack unit (RU) and delivered watts.
With the rates at hand, calculating the monthly cost for a given application or IT service is relatively straightforward: inventory how much of each item is required, multiply by the rate and total it up. For example, say a SharePoint system requires three eight-core servers of a standard memory configuration, whatever is the norm in your organization; 200 GB of block flash storage; 1 TB of object or file storage; and 0.25 FTE for system admin, not including running SharePoint itself. Here's a sample cost calculation:
- Servers: 3 * $200 per month = $600
- Block Storage: 200 * $0.15 per GB per month = $30
- File and Object Storage: 1000 * $0.05 per GB per month = $50
- Admin: 0.25 * $5000 per month = $1250
- Facilities: 5 RU * $100 per RU per month = $500
- Total: $2430 per month
When analyzing public cloud spending, the problem isn't calculating the rates per unit of consumption, but estimating the consumption itself. That's because the virtual services needed to deploy an application on AWS or Azure are often different from the physical infrastructure used in a private data center. One must translate between the two by designing the equivalent cloud infrastructure for a given application. Furthermore, there usually isn't a one-to-one mapping between public cloud prices and the rates calculated for a private cloud, since cloud services use very granular pricing measures -- such as price per hour, unless one reserves a resource for a set time period.
Let's work through the SharePoint system on AWS as an example. We'll assume that our servers are roughly equivalent to an AWS medium instance meaning we need 24 -- three servers times eight cores -- instances. Since SharePoint is considered a critical IT service, and we don't want to deal with the added complexity of spinning instances up and down, we'll reserve AWS capacity for a three year term -- this also simplifies the comparison. Here's the cost breakdown:
- Servers (EC2, t2.medium, all upfront): 24 m3.medium * $607 per 36 months = $405
- Block Storage (EBS): 100 * $0.10 per GB per month = $10
- File and Object Storage: 1000 * $0.029 per GB per month = $29
- File transfers: 50GB * $0.088 per GB = $4
- Admin: 0.075 * $5000 per month = $375
- Facilities: $0
- Total: $825 for a three-year term
Although constructed from very rough estimates, this example shows that by eliminating the cost of facilities and slashing admin time, deploying on public cloud services can be much cheaper than on-premises. Shift the workload to something that consumes much more storage, moves a lot of data between on-premises systems and the cloud or needs much more compute power, and the cost balance easily tips the other way.
The example above compares an all-or-nothing move to the cloud, but it also illustrates how one would analyze cloudbursting. If the on-premises systems are already in place, but reaching capacity, the cost comparison would help determine whether it made sense to expand on-premises or burst to the cloud.
Estimating cloud DR costs depends on the deployment scenario. For active-active designs, the calculation is identical to that in our SharePoint example. For active-standby, it will be closer to the test/dev situation, since live server instances will seldom be needed. The key difference will be storage costs, since you will want current replicas of application images and data in the cloud. Thus, you'll need to estimate the size and type of each application data set and operating system image, which typically uses object storage.
Building a hybrid cloud cost model is similar to that of any make-versus-buy financial analysis. It requires itemizing all relevant resource requirements for both on-premises and cloud infrastructure, estimating the cost of each, normalizing them to standard units of consumption and totaling it up. Once deployed in the cloud, the estimates can be validated and tweaked using actual data and tools such as the AWS Cost Explorer.
It's not just about cost for a multi-cloud deployment
Tools to streamline multi-cloud management
Mitigating public cloud risks with multiple cloud service providers
Don't overlook these costs on your cloud bill