Be cloud ambidextrous not cloud agnostic
I am lucky enough to own a PlayStation 4 and an Xbox One.
(It’s okay in 2018 for a senior technology professional in his fifties to admit that he still plays video games, isn’t it? No, not Red Dead Redemption 2 yet, although the original is one of my all time favourites. I’ve still got God of War to finish. And if you don’t think it’s okay for adults to play video games, go play both of those and then come back and tell me again.)
I don’t own both consoles because of any technical differences between them: I’m not really into comparing frame rates and textures, and will buy a game on whichever console is cheapest. But there are console exclusives which I don’t want to miss out on.
I think that this is a good way for enterprises to think about Cloud.
The first question any enterprise must answer when defining its Cloud strategy, even before picking a Cloud provider, is whether they will work with a single partner or with multiple partners. Increasingly, large enterprises are concluding that they should have at least two partners (there are good reasons and bad reasons for reaching this conclusion - more on this in a later post).
If an enterprise concludes that it should have multiple partners, it then has to answer the question of whether to be Cloud agnostic. Choosing to be Cloud agnostic means choosing to use only those services which are common across Cloud providers. Reasons to do this include resilience (the ability to failover between Cloud providers) and competitive leverage (the ability to get a better price on another Cloud provider).
I think that true Cloud agnosticism is a mistake: it’s like buying a PlayStation and an Xbox, but only playing games which are released for both. You have all the upfront expense of buying both, and none of the distinct advantages that come with either.
I think that a better strategy is to be Cloud ambidextrous. Being Cloud ambidextrous means using common and open standards across Cloud providers, while making the most of the distinctive features of each Cloud provider.
To make this real, if I am a true Cloud agnostic, then I might limit my usage of Cloud to Infrastructure as a Service, and build an abstraction layer to make all the Cloud providers look the same.
By contrast, if I am Cloud ambidextrous, then I will make use of a range of managed services, including database, container management, identity, logging, analytics, machine learning and more. I will live with the fact that different Clouds have different consoles, SDKs and APIs, and embrace the face that my teams enjoy learning all these differences.
It is true that my Cloud agnostic systems could be switched more easily from one Cloud provider to another. However, that’s not something I want to do very often, if at all. My Cloud ambidextrous design would take more work to switch, but is also much easier to deploy, to manage and to change. And those are things I do every day. I would rather optimise for the things I do frequently than for the things that I never do or only do rarely.
There are quite a few differences between my PlayStation and my Xbox: they manage have different interfaces, their stores work differently and their online accounts work differently. But, over time, they have settled on almost identical controller layouts. Without this convergence, it would be very difficult to switch between systems: muscle memory would keep tripping me up. Similar convergence is happening between Cloud: managed container services based on Kubernetes are becoming ubiquitous, while common standards such as SQL have been around for decades.
Given this convergence, it is easier to be Cloud ambidextrous than to be Cloud agnostic: I don’t have to worry about managing abstraction layers or enforcing standards which don’t help anybody, and I don’t have to manage the components which managed services take care of for me. Which leaves more time to play video games.
