Multi-Clouds have been a widely discussed topic among CIOs and IT managers of large corporations in the past years. The "State of the Cloud 2018" report states that 81% of companies follow a Multi-Cloud strategy. A couple of months later, the "State of DevOps 2018" report finds that 54% of companies already use multiple cloud providers today.

But first things first. Let's discuss, what a Multi-Cloud is, how a Multi-Cloud strategy is different from a Multi-Platform strategy and why companies even bother to implement Multi-Cloud in the first place.

What is Multi-Cloud?

A Multi-Cloud describes a cloud architecture where companies use multiple cloud computing services.

What is Multi-Cloud

We like to compare Multi-Clouds to a flock of sheep. These sheep peacefully co-exist in freedom.
In contrast to an isolated sheep, locked in a cage, which is where companies may find themselves, if they choose to rely on a single cloud provider to take the responsibility for the entire IT infrastructure.

Dimensions Of Cloud Computing Offers

To understand the full extent of this concept, we'll explain how basic cloud infrastructure services can differ. There are different dimensions, based on which companies develop their Multi-Cloud strategies. Two of the main reasons to go for Multi-Cloud are 1) the fear of vendor lock-in to a single provider and 2) a best-of-breed approach that leverages the strengths of each cloud platform platform.

Different Cloud Vendors

Cloud services are offered by different providers. The most popular cloud providers are the so-called "hyperscalers" with Amazon's AWS leading the race, followed by Microsoft Azure and the Google Cloud Platform. These 3 have in common that they are public cloud providers offering a big variety of cloud services from multiple datacenters across the world to companies all over the globe. But there are private cloud vendors as well, like RedHat that provide open-source private cloud platforms such as OpenStack or OpenShift and has recently been acquired by IBM.

Different Cloud Operating Models

Depending on a company's resources and the amount of infrastructure control the company aims for, cloud computing services can be provided in different operating models. There are private or public clouds, depending on whether the datacenter is the company's property or a public datacenter used by multiple companies. There may be shared or dedicated environments within these clouds. For example a company can have a dedicated environment within a publicly available datacenter. Environments can be managed by a managed service provider or unmanaged, meaning that cloud operations are run by internal employees. This is not a full list of possbilities, there are further combinations and variations, which we will discuss in a future blog post.

Different Cloud Service Models

Within offers of different vendors and various operating models, there are different service models in which cloud computing resources are provided to their users. The most common one is "Infrastructure as a Service", defined as follows in O'REILLY's Security Handbook: "Infrastructure as a Service (IaaS) is a cloud computing service model where a provider delivers virtualized IT infrastructure resources over the internet". Another, very powerful service model is "Platform as a Service" (PaaS). Instead of provisioning individual infrastructure components like virtual machines, routers, storage, as done in IaaS, developers can directly deploy, manage and scale cloud-native applications to the cloud while the platform takes care of the underlying infrastructure. "Container as a Service" (CaaS) has gained in importance with the rise of Kubernetes. It allows users to orchestrate container clusters.

Different Cloud Platforms

Cloud platforms are specific implementations of cloud service models. OpenStack for example, is an open-source IaaS platform. There are managed OpenStack providers, but as it is open-source, OpenStack can be downloaded and run by the company in the company's datacenters with no external provider involved. At meshcloud, we call a specific OpenStack installation a platform instance. A company could run multiple OpenStack installations in different datacenters. EC2 is the OpenStack equivalent for virtual machines, provided by AWS. However, as EC2 is a proprietary technology it is only available in the AWS public cloud. Cloud Foundry is an open-source PaaS technology, Heroku the proprietary analog.

To avoid confusion:

Multi-Cloud vs. Multi-Platform

If you do Multi-Cloud, you also do Multi-Platform. However, there may be cases in which you do Multi-Platform within a single cloud environment. Let's take Google Cloud as an example. You can only use Google Cloud, which is considered Single-Cloud, but use multiple platforms within that environment, e.g. GKE, the Google Kubernetes Engine together with the Google Compute Engine. The terms are often used synonymously. The mixture of different platforms (provided by different vendors, run in different operating models) is what we mostly experience, when talking to our customers. A research report, published by the Cloud Foundry Foundation supports this observation.

Why You Should Care About Multi-Cloud

Once you work in a company of a certain size, you will eventually end up doing Multi-Cloud. Why? As soon as you ask yourself the question "Which Cloud Platform is the right choice for my company?" you will realize that there is no single platform that can solve all your needs. Different development teams have different service needs and preferences, different kinds of data underly different legal regulations, different clouds have different prices – there is a list of reasons why companies end up using Multi-Clouds.
So why not embrace Multi-Cloud right away, choose the best tools for each job, satisfy developers by providing their preferred services and preserve independence by freedom of choice a.k.a keep sheep happy.

The Upside of Multi-Cloud: A Flourishing Cloud-Native Ecosystem

With the world turning to Multi-Cloud or Multi-Platform approaches, there is another observation worth to discuss: There is an amazing innovative ecosystem evolving related to the Multi-Cloud world. It is marked by cooperation and openness, aiming for great technical solutions to challenges that enterprises face when running cloud-native applications at scale. Last year I took part in the Cloud Foundry Summit in Basel. And while I go to a lot of tech conferences throughout the year, this really was an impressive experience. Nowhere else, have I experienced such a spirit and ambition to develop innovative cloud products in collaboration of (often competing) enterprises, vendors or individual developers.

The Challenge of Multi-Cloud: Increasing Complexity and the Lack of Process Adoption

Of course, not everything about Multi-Clouds is great. Especially large enterprises, whose processes and capacity of change often reminds us of large tankers rather than the speedboat needed to keep up with the dynamics of the market, often face major challenges when moving to the cloud. In the worst case the result is a large investment to new technologies with no notable improvements, when it comes to software delivery performance or generally speaking, the development of innovative digital products. This happens if administrative processes are not adopted to the cloud-native world. If a developer has to wait for 2 weeks to provision a cloud account, because the process leads through multiple manual approval steps with different departments involved, the company does not leverage the benefits that cloud technologies are supposed to bring in the first place.

… but there where is a will there's a way

Thankfully, this doesn't mean that large enterprises, with complex processes and potentially strong regulations or compliance requirements cannot benefit from Multi-Clouds or cloud in general. Multi-Cloud-Management systems help companies to handle complexity, fulfill regulatory requirements and leverage the cloud to the fullest. Back to our sheep analogy, they are the shepherds taking care of the sheep. meshcloud integrates multiple cloud platforms to a self-service user interface and streamlines administrative workflows. Developers benefit from easy access to their prefered cloud-native technologies, while transparency is provided, in terms of access control, permissions or cost, to ensure the necessary amount of control.
Click here to learn more about meshcloud's Multi-Cloud Portal.

Platform services play an increasingly important role in cloud infrastructures. They enable application operators to quickly stick together the dependencies they need to run their applications. For example, when deploying your application and you need a database, you just request a service instance for the database of your choice and connect it to your application. Done.

Specifications like the Open Service Broker API provide a standard interface to provide backing services such as databases or analytics to applications. However, the nature of a service offered by someone else to your application is not always that clearly defined and therefore you should pay attention to the exact contract the service offers.

At meshcloud we work with customers to integrate Open Service Broker API compatible services into a private multi-cloud marketplace. Based on that experience, we provide a compact check matrix for clear communication and understanding what type of service you receive when requesting a service instance. The following abstract scheme might not necessarily be complete (please comment if you have anything to add), but it gives a first idea which questions to ask and to ensure there is no misunderstanding between service owner and service consumer.

Service Model classification matrix

Unmanaged Operated Managed
Whitebox The service provides an instance in your space. You have full access to its internal wiring and start from there customizing for your purposes. Example: IaC-Template for MySQL Galera Cluster. This is a tricky model, as the service vendor offers operation support, but service consumers are also able to access the service interna, e.g. the service vendor offers a joint internal monitoring and provides an automatic recovery, but if you break anything, you need to recreate the service instance on your own. Example: AWS RDS (Managed Whitebox would not work because the service vendor is responsible for smooth operations, therefore the interna will be protected from outside access. Exception would be supported operations where you have service operators support you in running your systems.) Examples: Monitoring & Incident Response Whitebox means you see details of the service deployment, e.g. the service instance will be deployed into an IaaS space you have access to.
Blackbox (Unmanaged Blackbox would not work as no one would control the service instance) Example: Appliance as a Service without SLA The service vendor has automatic tooling in place to check service health and recover the instance. Service consumers can not access interna, so the vendor has exclusive control and hence should be able to provide a consistent service experience. Example: DBaaS, MLaaS This is the most usual and common perception of a platform service. You request a service instance and use it for your application without any further effort. Examples: AWS DynamoDB Blackbox means you only have a defined interface to control your service instance (e.g. the Open Service Broker API), but no insight where or how this service is deployed or operated.
Unmanaged: The service vendor does not undertake any measures to ensure the service is running smoothly. You get a service instance provisioned and from there, you're on your own with operations, but you don't need to start from scratch. You usually only pay for the bare resources consumed by the service. Operated: The service vendor monitors execution of the service itself and recovers the service when it fails. However, how this affects your application or your data is out of scope for the service vendor, but as a service consumer you need to add your own routines on top of the service instance. Managed: The service vendor takes over responsibility for availability and, often, data backup and recovery. Further, service updates will be conducted by the service owner without your involvement as a service consumer. This is the most comfortable, but also most expensive way of consuming a service.


The gold standard and typical understanding of a platform service is certainly: Managed Blackbox. However, there are cases when the other service models make sense, e.g. for highly customizable systems – let's say a Kubernetes cluster. Providing a K8s cluster as unmanaged whitebox service would mean you get a fully provisioned K8s cluster and take over from there in further configuration and maintenance. You still save the time to setup and provision a cluster on your own, but don't have to bear the costs of a fully managed K8s cluster.

In any case, there should be no misunderstanding between service vendor and consumer as to what the level of support really is. Especially, when procuring services becomes fast and easy and happens with a few clicks, simply assuming the vendor will take care of everything might create unpleasant surprises. Be sure to be aware of the exact service conditions, which are hopefully communicated transparently and easy to access.