“Multi-cloud” is a tricky term. At its face value, it simply means that your organization is using cloud services from more than one provider, right? But if it’s that trivial, why are so many people talking about “multi-cloud strategies” and why do entire market segments exist only to make managing your multi-cloud deployments slightly less unbearable?
According to Flexera, over 90% of organizations have a multi-cloud strategy, and on average, a business is using the services of 2.6 public cloud providers. But of course, the number alone is not what matters. For example, here at KuppingerCole Analysts, our developers actively consume various cloud infrastructure and services from all the top cloud providers and several smaller ones as well. A more interesting question is why multi-cloud has become such an important strategic driver for so many organizations.
What is Multi-Cloud Anyway?
Back when the competition in the public cloud market was just getting started, the selection of services offered by CSPs was quite narrow and focused mainly on infrastructure, such as virtual machines or storage. Choosing a specific cloud was primarily a matter of cost and availability, and there were few reasons to use multiple clouds other than redundancy. In the later years, however, most cloud providers have realized that competing with the market leader on its own terms is not a feasible strategy, and offering unique services that nobody else has is how you attract new customers.
Nowadays, even though everyone agrees that cloud infrastructure has become a commodity, we do know that major cloud service providers are definitely not interchangeable. On the contrary, every cloud has its own set of unique services, which everyone would love to use, even if it means the additional effort of going properly multi-cloud.
Sure, AWS perhaps still has the most varieties of hardware, but Google Cloud might appeal to developers with its powerful app modernization capabilities, while Microsoft Azure has great analytics tools, and Oracle Cloud Infrastructure offers very popular database services. Your choices might vary, of course, but the point still stands — if you are designing a perfect cloud-native application, you would want to combine building blocks from different service providers.
However, even though in theory this has been possible for years, in many aspects, “proper multi-cloud” development is still in its infancy. There are so many challenges developers must solve to make it possible, and even after that, compromises must be made as well.
The Infantile Disorders of Modern Multi-Cloud
The most obvious problem is interoperability (or rather the lack thereof). Every cloud comes with its own technology stack — products, data structures, APIs, security, and even identity and access models. This means that to develop a multi-cloud application, you have to learn almost (but not quite) the same things many times over and then make sure they remain compatible with each other as clouds upgrade their services.
Another major challenge is cross-cloud connectivity. Even though it is usually expected that within a single cloud’s infrastructure the traffic is fast and secure, letting your data flow to a different cloud goes against the provider’s business interest. This is why in most multi-cloud deployments, organizations must deal not just with large data egress fees, but with high latencies and the necessity of moving sensitive data over the less than secure public internet.
You should not forget the operational effort, either. Each cloud has not just its own administrative UI, but a whole set of processes, tools, and workflows associated with it. This means that an organization essentially has to hire a separate team to operate each cloud and then somehow ensure that they can work together in a meaningful way. With the growing shortage of skilled IT professionals, you’re looking at the prospect of additional investments not just into your employees, but into third-party tools and services to enable efficient cross-team collaboration. Of course, you can always outsource the project to one of the well-known global consulting firms, but that also requires additional investments.
With limited visibility and disjointed security across different clouds, multi-cloud deployments might lead to misconfigurations, compatibility issues, increased attack surface, and in the end, serious compliance violations and even data breaches. We have extensively covered the risks of migrating sensitive data and business-critical workloads to the cloud in our research, but for multi-cloud deployments, these risks are multiplied, and the native security controls built into every cloud cannot help deal with them efficiently.
Multi-Cloud 2.0 – What Should We Look For
The most trivial way to avoid all these problems is by avoiding multi-cloud completely. For example, you can absolutely run SAP on AWS or Oracle on Azure. But this approach is not ideal because it won’t be a fully managed service.
Another very common way to deal with the lack of interoperability is to introduce an additional layer of abstraction, the multi-cloud lowest common denominator, if you will. The most successful example of this is the Kubernetes platform for orchestrating containerized applications. And while Kubernetes is perhaps one of the best things that has happened to the cloud lately, it has its limitations. Containerization does make your application cloud-agnostic to a large extent, but it cannot magically address connectivity and data egress issues.
Is there a way to solve all these issues and finally allow “multi-cloud” to fulfill its original promise? Well, first, this relies heavily on the cloud providers’ willingness to cooperate instead of competing. If you want your data to flow freely between clouds, their operators must agree to establish fast, low-latency interconnects between their data centers first. And, of course, to stop hoarding customers’ data using exorbitant egress charges. Without this necessary step, the rest is just fantasy…
Still, wouldn’t it be great if we could just mix and match native cloud services from different providers and design our applications from these building blocks without the need to resort to some additional layer of compatibility? Or even better, to make native cloud services aware of other clouds and their data models, identities, compliance controls, etc.? Or, if I may dare to dream big, even manage all those services from the same administrative console and enjoy consolidated support or even billing across clouds?
Oracle and Microsoft Announce New Multi-Cloud Capabilities
Well, we might not be quite there yet, but Oracle and Microsoft recently made a big first step toward this multi-cloud future. In fact, the companies have been collaborating on multi-cloud deployments for years already: for example, fast private interconnects between Azure and OCI were launched in 2019 and are now available in 11 regions around the world. With 1.5 ms latency and no ingress/egress charges between the two clouds, customers can achieve the performance and flexibility of their multi-cloud deployments that is comparable to “single cloud” architectures.
But now the companies have gone even further and announced the first fully integrated multi-cloud service: the Oracle Database Service for Microsoft Azure. Now it is possible to run an Oracle Database in the OCI cloud but utilize it directly from any application running on Azure without any connectivity issues. Oracle databases running in OCI now have a completely native look and feel for Azure customers. They can be provisioned and managed directly from Azure or using Azure native APIs. They are fully aware of Azure identities and integrated into Azure networking and monitoring. And at the same time, they offer the full range of Oracle Autonomous Database and Exadata platform capabilities that were previously only available to Oracle Cloud Infrastructure customers, but not on Azure.
The only step customers have to perform is to link their Azure and OCI accounts—the rest is fully transparent. A growing number of Azure’s native services (Power BI, Cognitive Services, Kubernetes, etc.) are already fully aware of and compatible with the new database service. This makes it much easier to develop true cross-cloud applications. Database observability data is also constantly fed into Azure, providing customers with visibility into their infrastructure across the two clouds. Finally, both companies offer a consolidated support model, where you only need to create a single ticket to resolve any issue related to the new services.
This is, of course, just the beginning. Additional Oracle services will be added later and more Azure services will be made “multi-cloud-aware”. Another thing I’d love to see implemented is the integration with Azure security analytics services… But the Oracle Database Service for Microsoft Azure is definitely a big step in the right direction.
When I heard the announcement, my first thought was that people will inevitably refer to the new service as “multi-cloud 2.0”, just as they did with Kubernetes years ago. However, it would be fair to say that this is actually how people have expected multi-cloud to work from the very beginning. So, if you will, multi-cloud is finally out of beta and ready to unlock its full potential.
Commissioned by Oracle