How does open cloud stack up on price?

After Australia’s Melbourne IT unceremoniously dumped VMware vCloud Express, I wondered whether proprietary offerings like vCloud Express can provide the margin to compete with equivalent open source cloud offerings (e.g. based on Xen or KVM).

I am not alone either. Respected analyst Dale Vile (co-founder of Freeform Dynamics) posed similar questions on Twitter.

In response, one VMware employee posted a Virtacore vCloud Express price list and asserted that vCloud Express pricing is “very competitive with any cloud” and that the cost of proprietary cloud was a “non-issue”.

However, it turns out that the ‘non-issue’ status of vCloud Express pricing is far from universal, even within VMware. At the recent Cloud Expo event (my roundup and slides for my three sessions are here), another VMware employee seemed to think it an issue worth addressing, as he chose to highlight the same pricelist in his presentation as ‘proof’ that proprietary cloud was actually more cost effective than a public cloud offering.

Moreover, one pricelist in isolation says nothing about competitive pricing; rather it simply demands comparison.

So spurred on by this broad concern and spirited commentary, I decided to compare the published list prices of multiple proprietary offerings (including the now-defunct Melbourne IT vCloud Express price list) with roughly equivalent offerings (based on open source Xen) from Amazon and Rackspace.
This turned up some confusing results that, for the most part, do not seem to support the VMware position. For example:

• No proprietary offering comes close to matching the price of the cheapest open offering, AWS’s ‘Free Tier’
• Melbourne IT’s cheapest offering was over twice as expensive as the lowest paid-for offering from Amazon, which offers the same CPU, but four times the RAM
• Melbourne IT’s cheapest offering was almost five times the cost of the cheapest Rackspace service, which offers (up to) four times the CPU power, albeit only half the RAM
• Every one of Amazon’s offerings are cheaper than proprietary equivalents, except for the 4 CPU, 2 GB server service
• Every one of Rackspace’s offerings are cheaper than proprietary equivalents, except for the (up to) 4 CPU, 16 GB server service
• For a relatively standard server (1 CPU, 2Gb RAM), Amazon is half the cost of Melbourne IT, and two-thirds the cost of the other equivalent proprietary offerings
• For a high-powered server (4CPU, 8Gb), an open offering from Rackspace is around the same price as two of the three equivalent proprietary offerings
• At the most expensive price point ($0.96/hr), a proprietary offering beats Rackspace for the same memory while providing twice the CPU, but is still more expensive than an equivalent Amazon service ($0.68/hr)

Perhaps this helps to explain why the CTO of Melbourne IT, Glenn Gore, is reported as saying “the market for [SMB] customers was already dominated by large scale American offerings such as Amazon Web Services and Rackspace”.

Of course, list price should never be the sole factor in deciding the value of a cloud service. Many other factors should come into play, including reliability, security, manageability, uptime, integration, portability, support, and much more. Nor is this a clear apples-to-apples comparison. Each service has differences in specific offerings, few services compare equally head-to-head, and each provider has different cost structures for bandwidth and storage. Amazon and Rackspace in particular obfuscate the CPU basis for their offerings, making any comparison difficult at best, flawed at worst.

In the interest of open discussion then, I have included my full data set below, along with some additional explanatory pricing notes and links to the original sources. Maybe I have interpreted some of the sources incorrectly. Maybe there are additional values I have not accommodated. Most notably, my conversion of Amazon’s “Compute Units” or Rackspace’s variable CPU allocations may be flawed (they do not make it easy). While I think this data does enable a valid comparison, in the end it is just my interpretation of some very dissimilar price lists.

I would love to know what you think. Can a proprietary cloud offering compete on price with an offering based on open source? It appears to me that this is the exception, rather than the rule, but VMWare keep insisting that it is true.

So what am I missing?

Please post any comments and corrections below – I would love to figure this one out.

Pricing Notes

Melbourne IT

• As noted, Melbourne IT is no longer offering a vCloud Express service
• Storage is additional $0.327 Per GB per month
• Bandwidth is additional $1.047 per GB
• Prices are all in AUD. At current exchange rate these prices are slightly higher in USD

Source:

http://vcloudexpress.melbourneit.com.au/

Virtacore

• Unused instances are charged at full rate, even if unused, unless ‘destroyed’
• Bandwidth is free up to 3TB, although the time period for this limit is not clear
• All plans include 50 GB Disk
• Plans are actually listed as providing ‘VCPU’

Source:

http://www.virtacore.com/vcloud_pricing.cfm

Terremark

• System Storage $0.25/month per GB (billed with virtual machine)
• Internet Bandwidth $0.17 per transferred GB
• Public IP Addresses $0.01/hour per IP
• Internet Services $0.01/hour per service
• 8 VCPU also available

Source:

http://vcloudexpress.terremark.com/pricing.aspx

Hosting.com

• System Storage $0.50/month per GB (billed monthly)
• Bandwidth $0.17/GB (billed hourly)
• It is unclear if Hosting.com continues to offer vCloud Express. The vCloud Express web page does not appear to be accessible by navigating the menu system (only options are ‘Enterprise’, ‘Dedicated’, and ‘Private’), and the service is still classed only as ‘beta’, but the page can be found by searching the website.

Source:

http://www.hosting.com/services/platform-services/cloud/vcloud-express

Amazon Web Services (EC2)

• AWS actually leases by EC2 Compute Units (virtual cores with 1 or 2 ‘Compute Units’, each providing “equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor”). I have converted these at a 1:1 ratio, but this obfuscation does make it difficult to compare on even footing with other providers.
• All data transfer in – $0.100 per GB; Data Transfer out – First 1 GB / month free, and a reducing scale after that at an average of $1.07 per GB / month
• Offerings listed as 0.5 GB RAM actually provide 613MB, not 512MB; Offerings listed as 2GB RAM actually provide 1.7GB RAM; Offerings listed as 8GB RAM actually provide 7.5GB RAM; Offerings listed as 16GB RAM actually provide 15GB RAM. These have been rounded for ease of comparison.
• Free Tier is only available for 12 months for new customers

Sources:

http://aws.amazon.com/ec2/pricing/

http://aws.amazon.com/ec2/instance-types/

http://aws.amazon.com/free/

Rackspace

• Bandwidth costs: Out 18¢ / GB; In 8¢ / GB
• Rackspace’s CPU allocation methodology is not transparent, and may not be as interpreted. For Linux distributions, it appears to offer up to four virtual CPUs for every Rackspace Cloud Server. However, CPU measurement is based on a non-standard and dynamic weighting that is far from clear. This makes it difficult to compare 1:1 with other providers, even after consulting with Rackspace support.

Sources:

http://www.rackspace.com/cloud/cloud_hosting_products/servers/technology/

http://www.rackspace.com/cloud/cloud_hosting_products/servers/pricing/

The author, Andi Mann (left), speaking with Roger Green of CIOZone.com during VMworld 2010

At VMworld 2010, I had the great pleasure to record a video interview with Roger Green, Executive Editor at CIOZone.com. We chatted for about 20 minutes in total (in 2 parts) about virtualization, the issues of virtual stall (including both causes and solutions), how the antecedents of virtualization can inform our modern approaches, the importance of data center automation, the impending tsunami of cloud computing, and much more.

If you have not seen it, you can find Part 1 here, and Part 2 here.

(btw, if you have not seen the video archive on CIOZone.com, you really should – it includes some fantastic interviews with many virtualization and cloud experts and thought leaders including Microsoft Director David Greschler, Rackspace CTO John Engates, VMware GM Jim Morrisroe, VMware CIO Mark Egan, and my colleague and counterpart in our Virtualization Product Management team, CA Technologies VP Subo Guha – plus a host of other CIOs and IT experts. Definitely worth your time!)

I found a comment on the CIOZone.com discussion thread about the interview very interesting. It came from CIOZone member, Pete Simmeron (petesim), who posted:

Andi Mann, thanks for the great conversation, I learned a fair amount about some of the obstacles to implementing a virtualization solution. You mention issues like license control, deprovisioning excess virtualized servers, compliance, and how IT support staff do not necessarily scale to help bring an organization to the Utopian 100% virtualized environment. Well my question is then how do we move past these obstacles? Do we start slow and develop the necessary skills in house or do we hire from outside, and thinking ahead do you think this will become a highly sought after job skill in the next 10 years??

What a great question! It inspired me to a longer response than might be appropriate in a comment box, but here it is in full:

Pete, thanks for the comment.

Moving past the obstacles is certainly the goal, and it is not easy, but it is possible. I think automation tools are massively important, but people and process are key too.

For example, to manage licences properly, and to track which VMs are being used and which can be reclaimed, some type of asset and inventory registry is an excellent tool. However, to really make this valuable, instead of just adding work manually recording VM allocations and movements, it really has to be updated automatically when VMs are provisioned and deprovisioned. This will save resources (admins don’t have to manually assign and collect VMs and licenses), save costs (licences can be more easily reused instead of adding new license costs), and help expand virtualization deployment and maturity (admins can move onto virtualizing more complex systems, rather than just babysitting existing VMs).

However, it is also important to address the people & process issues, not just the technology issues. For example, you have to make sure that IT admins and even VM owners don’t deliberately find ‘workarounds’ for the asset registry that might make their job a little easier, and maybe even save their department some money, but which actually end up costing the wider company a lot more in terms of compliance breaches and increased license costs. It is also critical to make sure there is a clear, known, and easily accessed process in place (ideally one which is automatically enforced) to work with VM owners/requestors to identify and deprovision VMs that are no longer in use. This will make sure the technology benefits accrue as expected, but also will simplify some complex and problematic VM management activities.

As to where you start, a lot depends on existing process and technology maturity, organization size, the most pressing problems, and the overall goals. Most orgs will do best to solve one problem at a time with the people they have – perhaps managing VM performance, or controlling licenses, or automating provisioning. But very mature orgs will likely be able to do more up front, like implementing a service catalog and service desk approach to automated provisioning and deprovisioning, or even combining this with resource pools and self-service to start on the journey to cloud computing. Meanwhile, smaller orgs will probably need to bring in experts at least temporarily to help them get over the hump, as they are typically harder-pressed to skill up and resource in-house for such significant IT changes.

Finally, yes, I absolutely believe this will be an in-demand skill for years to come. The evidence is already there, in the higher average pay rates for administrators with virtualization certifications, and I think this will continue. Administrators and managers that can effectively harness tools, processes, and people to overcome virtual stall will end up driving advances in virtualization – not just increasing the number of VMs deployed, but improving their virtualization maturity. This in turn will drive not just the incremental (albeit short-lived) CapEx savings from server consolidation, but also to fundamental and long-term gains in OpEx reduction, business agility, service availability, continuity, and more that comes when virtualization (and cloud) transforms from a tactical IT project to a strategic business enabler.

Of course, I have an opinion (anyone who knows me will not be at all surprised by that!), but I am also very interested in what other people think is going to be the key to Pete’s questions. Please do go ahead and check out the video on CIOZone.com, and please add to the discussion either there or here. Or, like me, both!

There is a perennial debate in cloud computing about whether a failure of one cloud service provider can be more generalized to a ‘failure of cloud computing’. It is an important question because availability is a key decision factor in choosing between private and public cloud, and between public cloud providers.

The most recent example of such failures is the power outage at IaaS provider Rackspace’s London facility, but of course, we have seen this before from many public cloud providers – including Rackspace in particular, and not just once. SaaS provider Salesforce.com (and its PaaS arm, Force.com) has also had one outage already this year, an event that is far from unusual, and nothing new. Amazon, Yahoo, Microsoft, GoGrid, RIM, Twitter, Paypal and many others have also had substantial (and often repeated) outages.

There are some who dismiss these failures as one-offs, write off partial or short-term failures as too low-impact to matter, or just give poor DR a pass because it is the cloud, and we should not expect any better. Others reach to find semantic differences, calling it a service outage, an application failure, a facilities outage, a power outage, or a resource shortage. Some just redefine cloud to include only those services that did not go down this week (bonus points for adding a vainglorious reference to the ‘real cloud’ or ‘true cloud’).

YMMV, but I don’t see it that way at all. With so many repeated failures in so many cloud providers, these are not just one-off failures. They don’t just happen to isolated providers, they happen across the board. Regardless of the cause – the application, the facilities, the power supply, the lightning rod – an outage of a cloud service provider is still a cloud outage. And the definition of cloud I use is not dogmatic enough to exclude any of the providers that I have cited (and others), let alone define a ‘true cloud’.

So I see every reason to believe that downtime in the public cloud is not the exception, it is the rule; that outages in the public cloud are endemic, and they are systemic.

However, this judgement is absolute, not relative. Failure in one cloud provider may (and I believe does) implicate all cloud providers, but it does not imply downtime is more of a problem in the public cloud than in traditional enterprise IT. Indeed, there is a strong argument that enterprise IT has as many if not more outages, so uptime and availability is no worse in the public cloud than with traditional IT.

In fact, EMA research has shown average enterprise IT uptime is just ‘two nines’, at 99.5%. For a 24×7 system, that is over 50 minutes of downtime, each and every week. Contrast this with public cloud providers. Even with their problems, Amazon EC2 offers a “reasonable effort” to deliver an annual uptime of at least 99.95% – or about 5 minutes downtime per week – and offers a 10% credit for “eligible” breaches. Google guarantees ‘three nines’ (99.9%) uptime for its Premier Edition, or around 10 minutes downtime per week (although it promotes a study that claims an average downtime of 15 minutes a week). The Rackspace SLA promises network, HVAC, and power will be up 100%, though it does not guarantee server availability (beyond promising a 60 minute maximum repair window), and all promises exclude ‘scheduled maintenance’.

So for the average enterprise, ‘normal’ cloud computing outages, while endemic, can still be 5 to 10 times less frequent than in their own data centers.

However, it is not a black and white issue, not least because a focus on broad uptime percentages or on single instance failures ignores the huge nuance behind a single uptime number.

For example, many environments report ‘five nines’ (99.999%) or even 100% uptime – less than one second of unplanned downtime each day – for their critical systems by using processes and tools for high availability, fault tolerance, asset maintenance, live migration, etc. EMA has also found that best performers in Virtual Systems Management – 15% of enterprises – report an average of five nines uptime.

If they need to, enterprise CIOs can invest in technology to provide two, three, four or five nines uptime within their own data center. They can implement redundant hardware, HA and FT, multi-site replication, and more – if they want to pay for it. They can monitor for outages, know exactly when they happen, and react automatically to fix them immediately (or even use predictive analytics and automation tools to avoid them entirely). They can provide this as required, as a value-add to their business unit customers, or as an additional charge (or at least an exposed cost)  to the business to let them choose how critical their applications really are.

However, with the public cloud, neither the business nor the CIO has any real choice. With few or no management or automation tools, public cloud providers simply do not currently offer the same flexibility and accountability as internal IT. Without good management tools, no public cloud provider currently matches enterprise IT at the higher mission-critical reaches of availability.

So, this fight does not end in a knock-out for either side. As is common in the real world, nothing is black and white, but rather many shades of grey.

In the end, the solid achievements of public cloud providers, despite the bad press, does not absolve them of any blame or negate generalizations of downtime being endemic in the public cloud. However, the relatively poor performance of enterprise IT on average still does not ensure public cloud will be any better in any specific cases.

What this does show, however, is that CIOs who are planning to build their own private cloud have a surprisingly high bar to reach. They should not dismiss public cloud options out of hand, but rather should strongly consider whether they can realistically and cost-effectively meet the three, four, and even five nines that public cloud providers guarantee.

I am getting so sick of the continual bickering over definitions of cloud computing. Even more frustrating is the hype from all the vested interests – vendors and analysts, mostly – trying to define cloud computing in ways that they imagine will best contribute to their own commercial success. And I know that I am not alone.

What is wrong with the definition that the US National Institute of Standards and Technology (NIST) – a division of the US Department of Commerce – uses?

You can read the entire definition online [link updated 8/12/11]. It is only 2 pages. Here, for the unaware, is the meat of it:

“Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.”

Does this suck so badly that every [insert your preferred expletive epithet here] needs a new definition?

It goes on to include:

• Five essential characteristics: On-demand self-service; Broad network access; Resource pooling; Rapid elasticity; and Measured Service.

• Three service models: Software as a Service (SaaS); Platform as a Service (PaaS); and Infrastructure as a Service (IaaS).

• Four deployment models: Private cloud; Community cloud; Public cloud; and Hybrid cloud.

So what exactly is wrong with that?! Why does every man and his dog feel the need to throw their own definition of could computing into the ring?

Don’t get me wrong. Definitions are important. Definitions enable a common understanding of terminology, essential when talking about complex technologies. And I have pushed my own definitions before (like my definition for virtualization, widely adopted after Wikipedia picked it up in 2006).

But why fight city hall (in this case, almost literally)? NIST has a very elegant definition that is:

• Intelligent – it has been through (to date) 15 iterations, and has accepted input from many of the brightest minds in cloud computing (while presumably ignoring some dimmer bulbs)
• Independent – it is from a mature, well-established, and exceptionally talented US government agency, which is both apolitical, and science-based
• Commercially agnostic – it does not specify that anyone needs to be making money, nor does it preclude it, allowing cloud to be B2B, B2C, B2G, G2C, or any other model
• Accommodating – all established cloud vendors (like Amazon, Google, Rackspace, Salesforce, and others) fit into this definition, as well as private and government models.
• Clear – it is not full of jargon or ‘cloudwash’, but rather has easily understood, plain English concepts that are not only unambiguous but also usefully prescriptive
• Comprehensive – it includes all the important core concepts such as self-service, resource pooling, rapid elasticity, accessibility, usage costing, multiple use cases, and more
• SMART – it does not try to create anything exceptional or outrageous, but does define a set of Specific, Measurable, Achievable, Relevant, and Timely objectives

We trust NIST to define the official time for all of the United States. We trust it to calibrate instruments for NASA. We trust it to supply “industry, academia, government, and other users with over 1100 reference materials”.

Moreover, this is what the US government is using to define cloud computing, as noted by Vivek Kundra (the US Federal CIO). Indeed, Kundra has strongly indicated that the US government will be one of the strongest, largest, and most important proponents, providers, and consumers of cloud computing (cf. sites like apps.gov and data. gov). Other levels of government – and even other nations – will almost certainly follow their lead, and the NIST definition of cloud computing.

So why can’t people trust NIST with the definition of cloud computing, and just get on with the job of solving real problems for their customers? Bickering and chest-beating over self-enriching definitions is not needed, it is not useful, and it is not helpful.