I keep bumping into discussions where people try to compare vCloud (Director) and OpenStack. The last one that caught my attention was an email from a colleague that went like:
“We are in a competitive situation with OpenStack. Customer is currently using Amazon EC2….. They are looking at moving from Amazon to VMware due to outages killing revenue for their customers. They are also looking at moving to OpenStack internally”.
I am not sure if this customer intends to deploy vCloud Director and OpenStack side by side. If that’s the case I think there may be (potentially) good reasons.
If this customer is trying to figure out whether to use one OR the other…I *think* chances are that either they misunderstood what vCloud Director does or they misunderstood what OpenStack does. May be I’m missing something but, to me, it’s like comparing apples to oranges. And note that, by that, I am not suggesting apples are better than oranges or viceversa. They are different fruits tools with different flavors.
I’ll try to be brief (yeah, sure).
OpenStack can be seen as an open source incarnation of the Amazon (AWS) cloud model. vCloud Director is a similar software (albeit not open source) that implements a different cloud model. Those software can be used to build either public or private clouds.
Tangentially, please make sure you understand that Having cloud-enabled technology != Having a cloud. It is indeed fairly important as Lydia points out.
The AWS / OpenStack model can be seen as a forward leaning model whereas vCloud Director can be seen as a backward leaning model. The former model aim at creating a brand new experience in how applications are engineered, developed and operated. The latter model aim at creating a cloud-like experience for workloads that have been engineered and developed in a more traditional “enterprise” way.
I discussed these different models in the past in a couple of blog posts. The first one is TCP-clouds, UDP-clouds, “design for fail” and AWS and the second one is The Cloud Magic Rectangle ™. It must also be said that forward and backward leaning are very subjective concepts as I have tried to argue in another blog post: Cloud and the Three IT Geographies (Silicon Valley, US and Rest of the World).
While I tried to keep those discussions at the very high level, those are still very IT oriented discussions, including the examples and the parallels I used to describe the different cloud models (e.g.. UDP Vs TCP).
That’s why I was floored when Gavin McCance from CERN turned this into something that is a lot easier to understand with an awesome non-IT parallel:
He nailed it. Before you evaluate whether you want to use vCloud Director or OpenStack (or any other tool), you first need to understand whether you are dealing with “pets” or “cattle”. Once the cloud provider understands what type of service must be made available to cloud consumers, the choice of the tool becomes natural. If you have to deal with pets then vCloud Director (or similar technologies) is the natural choice; if you have to deal with cattle then OpenStack (or similar technologies) is the natural choice.
That is why I smile when I incidentally bump into CSPs wannabe that are trying to implement OpenStack advertising that they don’t use a SAN (but rather local storage) “because that’s how you do things in the cloud“. Then they claim to be resilient because they have redundant power supplies, redundant network cards and disks configured in Raid5 on those standalone servers. This is, IMHO, a typical example of an organization that needed to implement a cloud model to look after “pets”…. and ended up to chose the wrong tool (in this particular case).
So how do you know if you are dealing with pets or cattle? The blog posts I linked above will give you a good idea of where to draw the line between one model and the other. If you don’t have time to read them (or if you just couldn’t bother) there is a shortcut, and it’s a fairly quick one. Question: can I come in into your datacenter and, in the middle of the very critical business hours, randomly kill 10 of your critical instances while you smoke a cigarette outside?
If the answer is yes, because what I want to do would go unnoticed, you are dealing with cattle.
If the answer is no, because what I want to do would create a major turbulence in your end-user experience, you are dealing with pets.
Assuming you now have clear the difference between the two models, you can choose the proper technology to build the cloud you need.
No-brainer, no overlap. Two tools for two models.
Massimo.
Twitter
LinkedIn
Great example how kitties are saving the day again
I might add that there is also a preferred CSP billing model for pets and cattle: fixed price per month/year for pets and pay as you go for the cattle herd. This is a requirement for CSP’s billing behind the cloud technology to be able to support the appropriate billing model or potentially both models.
> Great example how kitties are saving the day again
Ah! Nice one
Yes, while I think the cost model is orthogonal to the two compute models and can be applied to both, the cattle model seems to gravitate more around PAYG while the other seems to gravitate more around fixed costs.
We got the original concept Pets/Cattle from Cloudscaling (Randy Bias). It has been a very useful way of high level modelling of recovery actions and application vs infrastructure responsibilities that can be explained in 5 minutes.
Awesome, Randy closes the circle
This is excellent work all around. The slide introducing pets vs. cattle is funny; the addition of your the example of allowing someone to walk into your DC and kill a random bunch of machines brings it back to the realm of IT. Nicely done.
This is an excellent metaphor to use when comparing CSP specialties (something I feel is often overlooked). I do think more logic needs to be focused around the technology decision when differentiating between vCloud/OpenStack & Pets/Cattle though. In example, the case of a hybrid cloud for a large enterprise (cattle..) who is already using VMware it would seem preferable to use a vCloud Service Provider rather than creating their own integration, provisioning, & management.
Love it! Very timely blog post for some research I’m doing on impact of monitoring agents on large private cloud.
So how do you know when a cow is sick or dead? Do you provide pet-like monitoring agents on each and every cow, and start to erode the benefits of using cattle due to increased guest agent overhead? Or should we just monitor the herd and keep cows as lightweight as possible?
So i understand it correctly, openstack with its decoupled model, allows software components and hardware to be easily swapped, while vcloud is an iaas layer on top of existing apps that have been virtualized?
But doesn’t the fault tolerance (FT) , high availability (HA) and disaster recovery (DRS) features of vcloud allow similar resilience against Netflix’s ‘chaos monkey’ ?
Not sure if I follow you. vCD doesn’t layer on top of the apps. vCD layers on top of vSphere (which is the virtualization platform).
FT / HA are features built into the vSphere platform that can make traditional workloads more resilient (transparently). On Openstack that “resiliency” should ideally be built into the application. The Netflix chaosmonkey is just a tool that kills instances of a particular service to prove that the service is resilient.
crystal clear, thanks!
I sat through a RedHat OpenStack presentation today…after listening to them for 10 minutes try to describe when you would use OpenStack versus “traditional virtualization” I so wanted to just shout out “Pets vs. Cattle”… alas, I left them to just squirm and continue to try and describe it…
Great article!
Do you think AWS could evolve to accommodate the Pet lovers? Should it even? Listening to @warner tells you that he think every IT org out there should become a cattle consumer.
Given what I am hearing/seeing I don’t think AWS would want to evolve to accommodate Pets. But that’s just my gut feeling.
[...] vCloud to AWS or comparing vCloud to OpenStack is like comparing apples to oranges as it has been clearly [...]