Large enterprises and regulated global institutions are increasingly tackling the subject of utilizing multiple cloud providers - AWS, Microsoft Azure, Google Cloud Platform. This is a complex area with many competing positions and interpretations.
Why Multi-Cloud?
As investment into cloud-native implementations is ramping up, many large enterprises are resolving to tackle the question of multi-cloud adoption. Key concerns typically noted:
- Avoiding concentration risk - i.e. ability to redistribute workloads across providers, initially or rebalancing in the future, meeting prudential regulators’ concerns around the dependence of our systems on a single provider
- Retaining ability to utilize unique innovations from competing providers without migration that is too costly
- Retaining possibility of commercial leverage and arbitrage for commodity services
- Avoiding single vendor lock-in
Dimensions
The biggest challenge in multi-cloud is avoiding having to descend to the lowest common denominator (VMs or IaaS-only) and losing the benefits of higher-level PaaS services (cloud databases, object stores, functions, event queues, etc.)
Still, it's worth outlining different angles from which multi-cloud can be approached:
- Code-level portability - avoiding having to rewrite substantial amount of business logic or data transformation code in order to enable it to run in alternate cloud provider infrastructure
- IaaS portability - deployment and run concerns, from utilizing provider-independent images and container configurations to networking (e.g. BYOIP), load-balancing and block storage
- Control plane portability - the hardest of them all. Notably includes monitoring/APM, alerts and end-to-end tracing, security & access management
A Measured Approach
I believe that code-level portability is the sweet spot for multi-cloud approach for new services and applications.
IaaS-only portability, e.g. forklifting whole VMs into cloud and eschewing the use of native/PaaS services cloud providers offer is fine for moving legacy workloads off-premise without refactoring (if you must), or for packaged apps where one doesn’t maintain source code and therefore has no control over code portability. However, for custom-developed, new code applications this approach would significantly reduce the value of the cloud proposition.
Control plane portability is today still quite difficult. Some of it can certainly be accomplished by utilizing common toolsets - e.g. OpenAPM, ELK, etc. across providers, but truly seamless control plane across multiple cloud providers is still either too difficult or too costly to achieve. Security and access management models vary across providers with few exceptions, e.g. BYOK has potential to broker root keys across cloud providers.
Code-level portability should be achievable more readily: after all, most PaaS dependencies - object stores, DBaaS, event queues and even functions/FaaS are being increasingly commoditized. It's possible to focus on common API subsets that eschew individual vendor tie-ins yet retain most of the power those native PaaS services offer. After all, why should the business or data transformation logic know whether they're publishing an event to Kafka, AWS Kinesis, Azure Event Hubs or Google Pub/Sub?
Even if common API subsets prove elusive in some cases, it should be possible to isolate dependencies into vendor-specific libraries/adapters, which can be shared across engineering teams. Dependency-injection and vendor-specific configurations added within build pipelines are another viable approach.
Historical Parallels
This in some ways parallels the path our industry travelled with respect to databases - from fully embracing vendor-specific features by writing business logic in stored procedures (with many good arguments marshalled in its favour) to common SQL standard and DB abstractions such as ORM that made cross-DB migrations much more feasible.
I fully expect multi-cloud to be an increasingly active area in open-source and open-core world with focus on common API abstraction for commodity PaaS.
