Get realistic about your multi-cloud strategy aspirations
Multi-cloud is attractive to software teams that want to expand their development toolboxes, but be careful about the complexity it can add to your overall development lifecycle.
There's a lot of buzz around multi-cloud architectures and the benefit gained when applications can quickly switch between multiple cloud platforms. However, multi-cloud isn't for everybody. So, developers must know when a multi-cloud strategy will help and when it will cause unnecessary complexity.
Using a microservices approach, developers can choose to run a specific part of an application where it performs best. For example, an application could run a recommendation engine using Google Cloud Functions to access Google Cloud's machine learning and AI services, as well as a social media analysis microservice on Microsoft Azure Functions, all while routing all of those functions through Amazon API Gateway on AWS.
Multi-cloud as an antidote to lock-in
When you commit to a single cloud provider, there's a possibility you could lock the application -- or the entire software development team -- into a platform that doesn't provide the full range of cloud services and limits the functionality projects can perform.
Developers instead want to build loosely coupled microservices that can integrate tightly into multiple cloud provider platforms and access the tools unique to each provider. This capability is essentially the goal of a multi-cloud architecture: to allow developers to switch an entire application or its components to a different cloud provider when necessary to find the best tool for the job.
For example, Microsoft, AWS and Google all provide relatively similar platforms, but the best tool for the job is sometimes only available from one particular cloud platform. Or, perhaps a particular search service is handled better by a SaaS provider than a PaaS provider. Rather than rely on an abstraction layer to run on top of these different platforms, developers might want to actually build applications to run on all three platforms to have easy access to each tool set.
Multi-cloud opens up many toolboxes
It's best to evaluate all of the relevant major cloud platforms when you're starting out on a software project to ensure developers actually get familiar with the process of building at least one microservice that can run on multiple platforms.
In some cases, one platform clearly outperforms another. In other cases, the code runs perfectly fine on any selected platforms, and the software product can actually execute in any of them. You can think of this as A/B testing. But once the code works in all the potential hosting locations, it means developers can switch that particular microservice to any place it needs to go.
For instance, if Azure introduces a feature the team wants to try out, they can route the traffic to those functions. Or, if AWS decreases the cost of Lambda by a large margin, they can switch at least a large portion of the application over to Lambda, if not all of it. But most applications don't need a multi-cloud architecture.
When less is more in cloud deployment
Multi-cloud architectures are harmless to experiment with, but when in production, remember to ask yourself if this strategy is vital to the business.
If you decide to stick with one cloud vendor, chances are the vendor's minor changes in pricing or functionality are negligible to your company's bottom line. But what about reliability? It's incredibly unlikely that a major, multinational cloud provider will completely go down in every region.
Despite the advantages of a multi-cloud strategy, many teams won't gain much from running their code on multiple clouds at the same time. The average development team finds microservices running in different cloud platforms face a lot of complexity when it comes to routing traffic between providers.
Multi-cloud introduces communication complexity
When connecting traffic within AWS, it's simple to grant access so communication can occur within a single data center or an isolated AWS network in a fast and secure way. This is not so simple when you try to connect, for example, between AWS and Azure. This doesn't mean it's not worth testing out different cloud vendors, but you probably won't need to run in multiple clouds at the same time once your application is in production.
So, remember, for the average software product a single cloud provider is just fine. However, you may want to experiment with other features available on different platforms to find the best fit. Just be prepared for the potential strain this might impose on your application architecture when you run it across multiple cloud providers, as communication over the internet is much slower than communication within a specific network.
Because identity and access management isn't an option to connect from AWS to Google Cloud, a team must store credentials to grant access from one cloud provider to another, which adds a level of complexity to security.
Multi-cloud architectures are harmless to experiment with, but when in production, remember to ask yourself if this strategy is vital to the business.
