When I’ve gone about building new SaaS offerings, I’ve always been amazed by the passionate arguments by developers and dev-ops professionals about which cloud to select. It is the same with any technology selection, with everyone keen to champion their ‘home team’ and cement their value (or bolster their CV) by selecting the ‘right’ thing.
The increasing abstraction driven by infrastructure as code practices has created the belief that the future is ‘multi-cloud’, i.e. products will be cheaper to run and more resilient if we distribute deployment of application resources across multiple cloud providers.
So why would you want to do that?
The Pros of Multi-Cloud Strategies for SaaS Application Hosting:
The Cons of Multi-Cloud Strategies for SaaS Application Hosting:
Is it a good idea or not?
Well, yea, but no. Of course, with anything, it depends.
Initially, I loved the leverage becoming cloud agnostic gave me in commercial negotiations with cloud providers. The power to move workloads simply with ‘just a few code changes’ would see me optimising my cost to serve, driving up margins and lowering supplier risk.
Yet the reality of implementation would suggest that the cost savings achieved in infrastructure quickly diminished as the technical and operational overhead increased.
For example, we had built our security strategy around Microsoft Sentinel and on the assumption that ‘production workloads’ would be in Azure. A costing exercise to tool the SOC to monitor a multi-cloud deployment resulted in eye-opening costs. Eventually, the savings started to slip away as the increased skills required within the dev-ops and security functions to develop and manage the controls became evident.
Yes, multi-cloud would have delivered increased resilience and made our CVs look amazing, but with the modest spend at the time, it did not add up.
So is multi-cloud still a good idea, yes? Will it work for you? It depends on your goals. If resilience and avoiding vendor lock-in are your goals, crack on. If it is to save money… perhaps not.