Traditionally, major IaaS providers haven’t pushed for interoperability standards to ease the movement of workloads between their platforms and other public clouds. However, given enterprises’ growing interest in the multi-cloud model, some of these vendors might reconsider their stance.
Despite some prominent differences, the leading public IaaS providers — AWS, Microsoft and Google — share a lot in common in terms of multi-cloud support. First, they are primarily service- and API-driven, which lets users mix and match AWS, Google and Microsoft cloud technologies to build and run their applications. In general, if a cloud provider exposes one of its services via APIs, users — and other vendors — can access it, even if their application is not hosted on that particular provider’s platform.
Second, all three of these IaaS providers offer marketplaces, where users can find third-party products that can integrate with that specific IaaS vendor’s offerings. Many of these products, such as management, monitoring and security tools, support more than one cloud provider.
Finally, for AWS, Microsoft and Google, data is a common denominator. Cloud-native databases, as well as third-party databases that run on public clouds, let any workload — regardless of platform — access the data they store. As long as you have appropriate network access and credentials in place, it’s possible to have an application use data from three different databases across three different public cloud platforms.
While these three features are systemic to all three major IaaS providers, each also has unique, native services that can help enable multi-cloud deployments. Here’s a closer look at each.
One of the core integration technologies that AWS provides is Simple Queue Service. This queuing service enables you to decouple and connect microservices, distributed systems — including other cloud platforms — and serverless apps. Organizations use the service to send and receive messages between both cloud-native and remotely hosted applications.
AWS Service Catalog, which helps admins build a catalog of services and resources — ranging from VMs to apps — that they approve for use on AWS, can also support multi-cloud deployments. One of the core advantages of AWS Service Catalog is its ability to connect to SaaS applications, such as ServiceNow. This enables IT teams to link ServiceNow to Service Catalog to request AWS resources, including those for storage and compute.
Azure Cost Management, a tool based on the technology Microsoft acquired through its Cloudyn buy, provides features to monitor, allocate and optimize your cloud computing costs. While this functionality is beneficial purely in Azure, enterprises can also use it to analyze and track their costs on AWS and Google Cloud Platform (GCP).
This is mostly an artifact of the fact that Cloudyn was built outside of the Azure cloud with support for multiple platforms. It’s likely that we’ll see more management and monitoring tools — even those that are native to a specific cloud — extend support to external vendors in the future.
When you need GCP to play well with other cloud platforms, focus on Google Cloud Endpoints. This service uses the OpenAPI Specification and provides frameworks and tools to develop and manage APIs. Moreover, it offers visibility into API performance with Stackdriver Monitoring, Trace and Logging.
The idea is simple: Since Google does not provide every piece of functionality you might need in the cloud, it offers a framework, through Endpoints, to build and deploy APIs that can work alongside other cloud services, such as AWS Lambda. However, no technology, including the Endpoints service, can provide you with instant integration; you have to build and deploy the API to enable connectivity with other services.
Ultimately, while all major IaaS providers offer API development and management capabilities, these products are not as “plug-and-play” as most users would like. If the cloud providers themselves don’t see this demand coming, other third-party vendors will.