SP: Let’s look at the considerations through a few different lenses:
Cloud skill development
While each cloud provider offers similar functionality, how you use and optimize that functionality differs widely. Each provider has unique nuances that rarely map over one-to-one, so your team will need to develop additional expertise.
Given the current shortage of candidates with requisite cloud skills, you complicate your recruiting and training efforts if you decide to use multiple public clouds. Plus, you prolong the march up the competency hill.
While structured, high-quality training reduces time to full productivity, skill mastery comes through hands-on practice. Having more than one public cloud provider means your engineers will need more practice and, unfortunately, you also increase the risk of mistakes and do-overs.
Multi-cloud architecture
Organizations have various options for how they migrate their workloads to the cloud. “Lift and shift” (moving VMs or containers into the public cloud) has been a popular starting point, but it only delivers temporary benefits.
The real benefits kick in when you’re able to harness cloud-native architectures, which leverage options like fully managed services and serverless. All the large providers have strong offerings to increase scale, greatly reduce cost, boost security and offload undifferentiated work from your staff. Cloud-native architectures typically take greater advantage of cloud provider economics and efficiencies.
If you use multiple public clouds and want cloud-agnostic architecture, you’ll likely be limited to the “lowest common denominator” architecture across the providers (most likely at the VM or container level). You won’t be able to take full advantage of any single provider’s efficiencies, and you risk reducing the potential ROI of your cloud investments.
Resilience
Any time public cloud providers experience a well-publicized outage, it’s only natural to reflect on your own level of exposure. Should you hedge your bets by adding another public cloud provider? My position is that one can architect a landscape that is as resilient or more resilient on any single major cloud provider than across multiple cloud providers. Ideally, if you’ve opted for a cloud-native architecture, resilience is baked in as part of the service.
If you’re not there yet, providers have multi-site and multi-region options with replication, auto-scaling and auto-failover that are either enabled by default or a mouse-click away. If you’re building these resilience features across multiple providers, you’ll have to use manual or third-party options to monitor systems, sync data and trigger failovers. Plus, if you’re not lucky enough to have a team of absolute unicorn cloud engineers who are expert-level fluent across multiple cloud providers, you’re going to have more handoffs and touches—not great in crisis situations.
Lydia Leong, Distinguished VP and Analyst at Gartner, penned a comprehensive opinion on multi-cloud failover not being the way to achieve resilience.
Cost
There’s a line in the movie Contact when John Hurt’s character says, “Why build one when you can have two at twice the cost?” Cloud providers have spending plans and tiered pricing, so consolidating your spend into one provider can drive lower invoice cost.
In the case of multiple cloud providers, the costs are not just those on the monthly invoice. There are other tangible and intangible costs that are part of the total cost of ownership, such as those related to recruiting and skill development.
