The image below is one that I’ve seen shared a few times. It makes me laugh each time. Like all good jokes, it has a seed of truth, and layers of deeper meaning, whether or not you believe that private cloud is a dead horse that we should have long since stopped flogging. There are many more ideas to take away from this. The idea that public cloud is relatively easy to master, quicker, and more reliable than the alternatives is probably true. It is simplistic, and it ignores the huge amount of legacy material we all have to deal with. However, I think most agree that if we were staring from scratch, public cloud would be the basis of our systems.
Next up we have the difficulty of riding two horses at once. This is the image I find most interesting. The surface point is that managing two clouds is more complex than managing one. A precarious balancing act may be good for the circus, but it is not for your mission-critical systems. More than that, if one component fails, everything fails. In a lot of ways this is very true. If we look at how people actually use horses, though, having two horses has usually been a good thing. How about we ride one horse but have a second on a long lead? If the first fails or slows, we can swap while the first recovers. Traditionally, this was the way the fastest, most expensive messengers worked. It’s a lot like having a DR site with asynchronous updates. Or what if we set up the two horses to pull a cart? We are then reduced to the speed of the slowest horse (we lose some features), and if one fails, we cannot continue as well as when both were working, but we can continue. Async DR? More than this, we can swap or add in different horses easily with minor design changes to the cart. This could result in more power, or in the effort’s being spread among more horses.
Our cart, though, needs some thought and some design. It exists outside of the horses and constrains them. In my mind, our cart is Chef, or Puppet, or Ansible, or PowerShell DSC. With a good cart, we can hitch up any horse (with the right training). Of course, a cart is more complex—it’s more expensive and difficult to maintain—than a saddle. Here I also start to disagree with the idea that private cloud is a dead horse. I’d argue that it is a Shetland pony compared to a Shire horse—far less capable, and not the first choice by any means—but not dead, and it has its uses. Importantly, with the right tweaks to the cart, it can be hitched up to the pony. With the right configuration management, we can hook into private clouds from the same management plane as our public ones.
Electricity is a good analogy for this argument. Electricity has been industrialized for over a century. No one in the Western world builds a factory that isn’t on the national power grid. Then again, most also include an on-site generator just in case. It’s expensive to run, and it usually won’t power everything. However, it’s useful in a pinch. Many now are including solar and wind generation, or geothermal energy generation, in their building design. In some cases, data centers are selling on their thermal output. Assuming that a system that is moving towards a utility model will become 100% utility, or that it will always stay utility, is not always a good idea.
Now, if I were a decent artist, I’d tweak the Public + Public Cloud cell to show two horses with a cart. I’d tweak the two hybrid clouds to show a cart horse (public) and a Shetland pony (private) with its tiny legs dangling, not touching the floor. I’m anything but a good artist, though, so I’ll leave you to imagine that yourself.
What is my point? In the end, I think that the more we focus on the horses, the more we constrain ourselves and lock ourselves in. I think we should focus on how we manage the horses, and then we can take our pick from the market. Once we have our cart, why stop at two horses? Why not four, or six…