From Silos to Services: Cloud Computing for the Enterprise

May 19 2014   12:51PM GMT

The Challenges of Calculating Cloud TCO

Brian Gracely Brian Gracely Profile: Brian Gracely

Cloud Computing
Hybrid cloud
Private Cloud
Public Cloud

The big trend with Cloud Computing providers these days is a focus on “Enterprise” customers and workloads. We see this from AWS, VMware, EMC, Cisco, Microsoft, IBM, HP and others. Regardless of how each of those companies define “Enterprise”, this means that they are now subject to the rigors of TCO calculations prior to major purchases being made. Welcome to the wonderful world of Enterprise IT.

Now for the fun part. Building a TCO model that properly explains how much the offering will cost over a standard period of time – typically 3-5 years.  Having built several of these models in the past, I know that they are always held up to huge amounts of scrutiny. Whether customers think you’re trying to hide or mislead them on costs, or whether customer believe you don’t understand realistic use-cases, no two TCO models are ever the same. They all make assumptions and they all have to make tradeoffs between completeness of information and usability (eg. too many inputs, too many calculations). With that in mind, let’s take a look at a recent attempt at a TCO calculator by AWS, comparing their server vs. traditional data centers.

Let’s begin by asking a few basic questions:

  1. What type of use-cases or applications does the TCO tool allow to be modeled? (eg. redundancy, security, availability, performance, etc.)
  2. What assumptions does the TCO tool make about how costs are calculated? (eg. cost of equipment; cost of IT resources; efficiency of IT resources – both people and equipment)
  3. Does the TCO tool make reasonable comparisons between each model? Too many tools compare one approach’s “best” vs. another approaches “worst” scenario.
  4. Does the TCO tool surface all the assumptions of both approaches, or just the approach of the tool originator?

Let’s take a look at some basic scenarios with the AWS TCO tool. Using the basic inputs (try 10VMs, 32Mb RAM, 10TB of SAN Storage), the tool shows a huge cost savings (over 3yrs) when using the AWS service vs. an on-premise approach. This is to be expected, it’s an AWS tool. All vendors include a certain amount of bias in their calculations. But let’s dig deeper and see what assumptions and potentially incorrect modeling was used.

  • Server pricing (Dell or HP) is based on 25% discount from public list pricing. Typically discounts for customer would be 40-60%.
  • AWS aligns requirements to the best matching EC2 instance type vs. only having 2 options for on-premise (2×6, 96Gb; or 4×6, 256Gb).  This means on-premise pricing is higher than normal.
  • Additional 5% added to server cost/capacity as hot-standby spares. Not necessary with VMware HA or DRS. Many companies get on-demand spares with 24-48hrs from vendors.
  • Only 75% rack capacity on-premise. Lots of empty space in on-premise racks.
  • Virtualization pricing (VMware) is only 25% off list, at the highest license level. Discounts on VMware ELAs will typically much higher.
  • EBS pricing is show at 50% of SAN pricing, over 3yrs, with only 5% used for snapshots and no expectations of IOPS. This is highly questionable
  • No bandwidth costs associated with AWS TCO.
  • No IT labor associated with AWS TCO (unless you move to the “advanced” version of the tool)
  • AWS assumes that EC2 server admins will manage 400 instances each – this is fairly high compared to normal IT (100-150 VMs under management per admin)
  • For on-premise storage, calculations assume RAID-0 for storage (50% useable) + 10% backup. Modern storage arrays are able to deliver much higher levels of usable storage
  • For AWS storage, assumes 100% capacity (no RAID?) and only 5% backup (using snapshots) – no mention of RTO/RPO, especially with “0” guarantees IOPS and no redundancy.
  • AWS assumes “tape” is used for backups?
  • AWS does make any mention of security for the environment.
  • AWS offers no ability to configure any redundancy for either environment. Maybe this is because they are assuming that all applications used on AWS are modern and will build redundancy into the application, but even if this is the case, then Availability-Zone redundancy should be considered in the model.
  • AWS makes no mention of depreciation costs or their impact on taxes and balance sheets for on-premise deployments.

As you can see, digging a little deeper into any TCO tool will uncover flaws or assumptions that can significantly change the results. This doesn’t necessarily mean that a customer wouldn’t choose AWS (or any public cloud provider), but it’s important to know what your true costs would be and how they compare to your actual internal costs. Instead of just spitting out a result and providing assumptions, these TCO tools would server customers better by allowing them to download (and manipulate) the actual models with their own costs.

All of that aside, maybe the biggest flaw in any of these TCO tools is the assumption that a customer will have an all-or-nothing approach to their business applications. All public cloud or all internal data center (maybe they call it “private cloud”). In reality, what I’m seeing more and more are customers that want to create hybrid architecture for their business applications. The good news is that tools like this can be helpful for them to better understand how to measure and compare their internal costs vs. external costs and make educated decisions about where to deploy and operate an application.  Sometimes cost is the deciding factor, in other cases it’s speed of deployment or security or geography or another factor that takes priority.

TCO tools have their place in Cloud Computing, just as they have within IT for decades. But now that we have both on-premise and off-premise offerings, as well as CAPEX vs. OPEX models, it’s important to truly understand the tool and the assumptions it makes. Being educated on the inner workings of any tool will lead to more educated decisions when deploying business applications to help drive business success.

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: