Why use one cloud, when you can use any cloud? No, seriously, why would we just use one cloud? Let’s stop for a moment and think about what has happened over the course of the last few years in public cloud computing and the hypervisor wars on-premises. VMware has largely dominated the data center, but we are seeing a strong push from Microsoft on the hypervisor front. KVM and Xen continue to grow in popularity for certain sectors, and all across the spectrum we see lots of folks running more than one hypervisor.
The cloud is no different. The reason that we are all seeking the “AWS killer” just like the elusive “iPhone killer” is that there is some bizarre need to locate a winner of the platform war. Like my favorite show, The Wire, quoted, “You can’t even call this s$%t a war. Wars end.”
This isn’t a zero-sum game. The real shift in our industry is the broad acceptance of multiple platforms inside every IT portfolio. We jumped right past the cloud to the multi-cloud.
Why Run More Than One Cloud?
Technology is not the problem, it’s the solution. Business challenges are being answered by technology which is what really matters. So, why would we run more than one cloud? The reason is a technological one usually. Certain features, APIs, and architectures may be supported on one more than another. There are raw economics involved as well. There are overall availability concerns which drive businesses to disperse their IT across multiple data centres, so why not do the same in the cloud?
The reason that AWS and OpenStack are often pitted against each other is that there are capabilities to enable AWS API access within the OpenStack platform. This is something that Randy Bias and many in the community fought for over the last few years. The reason that it becomes important is that we see the huge adoption of AWS, and being able to take the same workloads and move them to OpenStack using the same API calls and interactions would be a massive win for OpenStack as a platform.
If we stick to strictly public cloud providers, we can start with what we would call the Big 3: AWS, Microsoft Azure, Google Cloud Platform. Among those three, we see a lot of parrying as we see features and pricing updates happening regularly. Features more so than pricing lately. That results in an ever-growing set of services that can be easily consumed. As we see common orchestration and operational platforms like Mesos, Kubernetes, and the like gaining in popularity, it gives even more credence to the commoditization of cloud. (Author’s opinion note: The supposed “race to zero” for cloud costs is over. They have all agreed that pricing isn’t where they win the customers anymore)
Reducing the Complexity of Multi-Cloud
Complexity is the one thing that will slow the multi-cloud adoption a bit longer. There are clearly different ways to consume resources, and to programmatically create and destroy resources in the public cloud platforms. Especially when you go outside of the Big 3. That means consumers of the public cloud will have to start with one target and generally work up to a deep comfort there before moving to embrace a multi-cloud strategy.
Once we remove or reduce complexity from the list of barriers, that opens up the door for embracing the economic value of a multi-cloud strategy. This is where we can embrace spot pricing and on-demand growth to tackle scaling needs, while making the workload truly portable and making sure that price becomes the real win. Networking stacks across the clouds are rather different for a reason. If every car manufacturer used the same exact parts, they would lower the chances of you coming back to them for up-sell opportunities. The same goes for the cloud. Networking and security (they should always be paired) will most likely be the greatest challenge that technologists face in architecting their single multi-cloud solutions.
Next-Generation applications are being built as cloud-native where possible. This opens up the door for what has been talked about for years. Supposed freedom from vendor lock-in. I’m always rather skeptical when a representative from one cloud company says “come to us and avoid vendor lock-in” because every vendor, even public cloud ones, have lock-in. What we do gain by embracing the cloud-native approach to application development and deployment is that we reduce the risk of lock-in.
The more we learn from the forward-leaning development teams, the more we are able to give ourselves agility in a multi-cloud architecture. As all of the public cloud pundits who represent one faction or another are arguing over who will be the last one to be all-in on the public cloud running cloud-native applications, they forgot about one thing: They opened the door for their competition, too.