Companies increasingly use public cloud services to run critical applications that form the core of their operations.

Cloud providers are naturally interested in capturing higher-order services (for example, database-as-a-service, etc.) that customers can consume once on their platform. This effect raises margins for cloud providers, but also helps to lock customers in, due to the proprietary nature of vendor API’s and overall engineering skill set requirements. This vendor lock-in and its consequences are one reason that sparked the conversation around cloud neutrality today.

So, what exactly is cloud neutrality and why you should care?

What is cloud neutrality?

The term “cloud neutrality” alludes to another concept – net neutrality. Do you recall the discussions about net neutrality a few years back?

Those in favor of it argued that internet service providers (ISPs) and governments should never be in the position of placing restrictions on consumer access to internet networks. The restrictions can extend from content and platforms to equipment and modes of communication.

Cloud neutrality draws on a similar premise. It prioritizes building an environment where:

• there’s healthy competition between vendors,
• no provider has an unfair advantage over any other provider,
• and clients using a particular cloud service aren’t locked out of using services from other cloud providers.

Why are businesses interested in cloud neutrality?

Reason 1: interoperability.

A typical organization today uses multiple and interoperable cloud providers. For instance, you might partner with an IaaS vendor to manage your infrastructure, a SaaS company to solve your workflow applications and a PaaS provider for building a development environment.

It’s not fair to be locked into a deal with a single cloud provider that prohibits you from collaborating with other businesses. Vendor lock-in has one major drawback: you become vulnerable to any changes made by the providers.

Let’s say that you decide to move to another provider because your existing one no longer satisfies your requirements. Or you’d like to combine services from various providers in order to maximize your product offering. This is where you’ll find yourself locked in. Since the specifics of various cloud providers’ tools and services (such as semantics or APIs) don’t fit, you won’t be able to transfer apps or data across them. Interoperability of resources or records, collaboration, and portability becomes extremely difficult.

This problem is closely connected to another one: deplatforming.

Reason 2: Fear of deplatforming

Breaching a vendor’s contract can have dire consequences. Deplatforming is a rare occurrence, but it still happens, famously or infamously, as we saw recently in the United States last January 2021.

Service providers may cancel contracts for material violations of the terms of service, refuse to renew them or provide terms that are so unattractive that not renewing the contract is the only real option. This is valid not only for cloud service providers, but also for payment processors, e-commerce service providers, conventional web hosts, and many other essential internet infrastructure providers.

Achieving cloud neutrality means that once a provider stops supporting an essential functionality, companies should be able to turn to another vendor without worrying about compatibility issues and downtime.

Reason 3: Increasing infrastructure resilience

Being able to move fast from a CSP will improve your resilience to cloud failure. Even the most well-known cloud service providers experience outages (remember November 25, US East Coast), which can lead to serious financial and reputational consequences.

One way to avoid this is to duplicate significant portions of the infrastructure and workloads in two locations. This solution is expensive and very effective. For those using Kubernetes, you can also elegantly deploy logical clusters that span across more than one cloud provider. As soon as one failure is detected, Kubernetes declarative engine will just recreate the missing resources in another place. Other technologies will duplicate your data in multiple independent locations, so that if one location goes down, your data is still available elsewhere.

Is multi-cloud the answer?

Let’s be fair: many organizations still become multi cloud by accident: a recently acquired company that brings a new provider, a team of developers that experiment with a different provider, or simply a research group that needs access to some ML services that only one cloud can provide. You happen to use more than one provider. It does not mean that you planned for it.

Multi cloud as a strategy to achieve cloud neutrality is entirely different. This multi cloud is when organizations distribute their workloads independently across multiple providers and when applications are spread through multiple public cloud services. With this approach, you can also take some extra steps in cost optimization, because you now have access to not just one price list, but all price lists of all the clouds where your applications can live. Many of the risks associated with vendor lock-in are eliminated if you do it correctly.

This is one of the primary reasons why there are companies like us, working on solutions to give developers the freedom to deploy their applications wherever they want.

Join the cloud native community at KubeCon + CloudNativeCon Europe 2021 – Virtual from May 4-7 to further the education and advancement of cloud native computing.