Half a Cloud is better than no Cloud
Every time a new technology or approach to computing enters our field of vision, it is immediately seized upon and defined as being “x”. Maybe it’s based on characteristics, like elasticity and a utility-based business model. Perhaps it’s accompanied by a mnemonic like CAMS to clearly identify just what components are required to be considered a “real X”.
And if you fail to adhere to the requirements as set by, well, someone else, the experts will dismiss your efforts as being “not X”. Because no true X would fail to include Y*.
I was reminded of this existential truth during a Twitter conversation, in which someone observed that “automated infra is not cloud.”
Now, based on some definitions of “cloud”, that’s true. In fact, some definitions of cloud make it impossible for an enterprise to implement a cloud computing model on-premises at all. Others make it possible, but improbable. And still others are so vague as to include SaaS as a valid example of “cloud.”
Yes, I went there. Years ago.
Here’s the thing: enterprises don’t care whether they get a “100% Cloud” sticker from someone on the Internet to validate their implementation. Arguments against private (on-premises) cloud have for years revolved around public cloud being faster, more efficient, and more agile than their data center-bound cousins. The reality is that every form of cloud includes as part of its implementation automation infrastructure. Without it, you don’t get the immediacy of provisioning, nor the flexibility of auto-scaling, nor the “on and off again” capabilities inherent in the cloud model.
Fully half the cloud is just technology. The other half is billing and services and process automation.
I’ve heard customers loudly (and somewhat contemptuously) dismiss “cloud” and part of that disdain arises from an all-too-often procrustean approach to technology and its adaption by the enterprise. Procrustes, as you might recall, is one of the numerous villains defeated by the Greek hero Theseus. In the tales, Procrustes invites passers-by to spend the night, and then spends the evening making them fit the bed using whatever technique was appropriate to their frame. (I’ll let you imagine how he might go about doing that, but in the end, no one lived through it). “Procrustean is thus used to describe situations where different lengths or sizes or properties are fitted to an arbitrary standard.” (Wikipedia)
If all enterprises do is automate infrastructure and call it cloud, so what? If it doesn’t fit in Procrustes definition but realizes the results they’re after, does it matter? They want apps delivered faster, smarter, and safer. They aren’t interested in whether they are implementing a whole cloud or just half. As long as they get the job done faster, more efficiently, and with greater agility than they did in the past, it’s a win for both IT and the business. Which is kind of the point to adopting any technology or methodology.
Because all these things are relative. Faster. More efficient. Greater agility. It’s not about achieving equivalency with public cloud providers, which they can’t do because they lack the volume (and the business motivation), it’s about delivering IT services at the speed of business. Enterprises aren’t interested in a merit badge declaring their “cloud purity” so their CIO can proudly declare “achievement unlocked”. They’re interested in improving the way IT delivers its services to the rest of the business.
So yes, it may be true that when enterprises claim to be doing “cloud” that they really aren’t by those with a procrustean perspective. Perhaps all they are doing is automating infrastructure and a few manual processes to improve speed, agility, and delivery of their services and subsequently, the apps the business needs. But at the end of the day, that’s half of cloud.
And half a cloud is better than no cloud at all.
* This is the technical equivalent of a No True Scotsman logical fallacy. Long time readers will note that logical fallacies make baby Lori cry.