Cloud is King, but at times the myths around the King are difficult to comprehend. The ‘Cloud’ is a completed OSI stack and platform and there are extraordinarily obvious differences in implementation between the 3 ‘Hyperscaler’ cloud platforms. Choosing your platform is going to ‘lock you in’, no matter what the marketing material from vendors state.
Myth 1: Multicloud solves lock-in problems.
In short, ‘multi-cloud’ will exacerbate, not mitigate the ‘lock in’ issue if and when you use the ‘native cloud services’ or their PaaS. Even if you do not, and go with an IaaS or Infrastructure platform as a deployment model, the differences between the platforms will require you to rewrite most of your scripts, configurations and connections.
The above is valid even if you already have another cloud provider’s services within your multicloud service catalog. This cloud-service integration does not eliminate the fact that you’ve leveraged services that are native to a specific cloud provider within an application, and thus you’re pretty much coupled to that cloud platform. The alternative is expensive and costly refactoring (meaning recoding) to move an application to another public cloud.
An example is Terraform IaC scripting. You will be rewriting over half your module when you move between cloud platforms.
Myth 2: Multi-cloud is cheaper than a single cloud deployment.
Never.
There may be value in a multi-cloud strategy (security, DR, backup, workload optimisation etc). But this does not mean that the value of using multi-cloud to justify the increase in cloud computing spending won’t be justified. In the large majority of multi-cloud deployments, the cost of deploying and operating more than a single public cloud is always going to be far more than a single public cloud deployment, most things being equal. This is common sense. Factor in training, skills development for that platform, life cycle management of the assets and security costs.
The complexity of heterogeneity
There is a cost for the heterogeneity and the complexity of multi-cloud, which is going to expand the talent and the types of operational tools that you need. Also, you’ll need to leverage cross-cloud security solutions and other things that make multi-cloud far more costly.
Although there are ways you may find some operational cost savings, they are nowhere near enough to counter the additional costs of heterogeneity and complexity. Instead, we move to multi-cloud for the value that it can generate, considering that you’re able to pick the best-of-breed cloud services among the different cloud providers, as well as mix and match more cloud services to support better innovation in the company. Multi-cloud should be about leveraging technology that’s strategic to your business, not just attempting to eliminate a few dollars for IT.
Myth 3: Multicloud provides more resiliency
No.
The core of this idea is that if we can use more than a single cloud brand and leverage active-active types of configurations for a single application and data set between the two cloud brands, we should never be taken down by a single public outage. Wrong.
Using the multi-cloud option for disaster recovery, in a ‘hot DR mode’, you simply end up paying the same standard operating costs twice for a single application. Also, you’ll pay to customize the application and data for a different cloud (say two clouds total), especially when you consider the need for special development, databases, and administrative skills for each. This pushes the value of moving to multiple cloud-based platforms for outage protection out the window. This could impact your product pricing, or your internal budgets, depending on what the application is doing.
Very few ‘fabric rips’ take down an entire cloud region. Each cloud region has 2-3 data centres. If you are using a multi-location or AZ approach, you have built in backup and DR. You can of course deploy a pilot light backup out of region with your AMI’s, data and code as a backup to the backup.
Although some large outages have occurred with the major cloud providers, most of these are localized to a single region and are corrected in a reasonable amount of time. Certainly, it’s a better uptime record than most enterprises have for their own internal systems.
Multi-cloud?
Maybe.
You can run heavy transactional workloads in AWS, your SQL based less intensive apps in Azure, and ‘Big Data’ analytics in Google. Nothing wrong with that. But all 3 platforms are remarkably dissimilar, using different designs, approaches, tooling and automation. You will need to have teams within the 3 platforms who really understand what they are doing. You don’t do this to ‘reduce cost’. You will enact a multi-cloud approach to provide value, benefits, revenues, new products, insights or tangible business and IT benefits. Reducing costs should not be the reason why you deploy across platforms.