Cloud Agnostic: A Quick Guide

What is cloud agnostic?

Cloud agnostic refers to an approach or perspective where software is designed so that it can work with many cloud providers or cloud platforms. Switching between different cloud infrastructure providers is easy for a cloud agnostic set up or, at least, there are no technical barriers preventing it. Instead of something strictly working on GCP only, it will work on virtually any cloud provider out there, without changing your code.

A lot of people think that cloud agnostic means writing one version of a thing and that code works everywhere. The reality is it requires a lot of work to get things working on any individual cloud provider, so you can’t really write something that will work absolutely everywhere in one fell swoop. Instead, you put in extra effort to make sure things are continually cloud agnostic and will work across as many providers as possible. Nothing is automatically cloud agnostic. 

This is one of the reasons we built OpsMaru, to make cloud agnostic approaches easier. Let me put it another way: the opposite of cloud agnostic is vendor lock-in, and we built our entire product to end vendor lock-in. 

The risks if you don’t take a cloud agnostic approach

If you don’t use a cloud agnostic approach, you risk being held ransom by a provider. They can raise prices, impose new kinds of restrictions or lower the quality of their product and support. If you’re locked in because your cloud setup can’t move easily to a new provider, then you have to put up with those kinds of changes. You even have to put up with charges you don’t agree with and would never have agreed to in hindsight.

Cloud agnostic meaning

What does cloud agnostic mean? The meaning of cloud agnostic is really straightforward: if it can run on different cloud providers, then it’s cloud agnostic. 

“Agnosticism” traditionally refers to when someone doesn’t have firm beliefs that God exists or doesn’t exist. An agnostic person is open to the possibilities when it comes to that question. When we talk about “cloud agnostic”, we’re using the idea of agnosticism metaphorically to suggest that the person or the cloud setup is again “open to the possibilities”. 

A cloud agnostic system can work with different cloud providers so it isn’t limited to any single provider. It’s agnostic about which provider you go with.

Cloud agnostic benefits: Why bother with cloud agnostic at all? 

Easier multi-cloud:

If your setup is truly cloud agnostic, that means that you can host your applications or services across several different cloud vendors. As a knock-on effect, you can maintain uptime and potentially host different parts of your application in different geographic locations to lower latency or meet geographic requirements (for example, for data hosting, aka “data sovereignty”).

Cloud agnostic costs: 

There are dozens if not hundreds of cloud providers available today. That means that there will often be someone in the market who is trying to gain more customers and offering lower prices or better perks than your current provider. 

Cloud agnostic migration: 

If you work in a highly regulated industry, being able to change cloud providers quickly and easily to meet regulatory demands to have data hosted in a specific location, for example, is a great idea. If you aren’t using a cloud agnostic approach, it’s still possible to move but it’s significantly more painful and can take much, much longer. 

You may also end up in vendor lock-in again if you don’t make relevant architectural changes during your move. In which case, the situation could happen again further down the line. 

How to build cloud agnostic applications

Building a cloud agnostic application doesn’t require a lot of specific changes or technologies. Instead, you actually want to build with common, standard tools that will be supported by as many providers as possible. 

Real talk: if you are tempted by a service or dare I say it, microservice, that brings dependencies or requirements that limit your other choices, you should seriously reconsider it. Stay as flexible as you can for as much of your architecture as you can. Especially resist pushes to use a new technology which limits your options for other components.

Cloud native vs. cloud agnostic

These are sometimes thought of as opposites but that’s not the case. As the folks at Copado put it, “Cloud native is more of a philosophy that drives resilience and scalability. Meanwhile, cloud agnosticism centers on eliminating dependence upon any single provider.” Those things aren’t incompatible! In fact, you kind of want them to work together, don’t you?

What does cloud native mean in terms of cloud agnostic?

Nothing really, because these aren’t opposites. 

Cloud native means that a cloud setup is designed from the start to exist in the cloud. It’s not meant to be amphibious between running on a server and running on, say, AWS. Instead, it’s built from the start with the idea that everything will operate on cloud resources.

In practice, cloud native also typically refers to a cloud setup that is built using Kubernetes (sometimes written as K8s). 

The K8s ecosystem is full of free OSS tools but it’s an incredibly convoluted landscape that’s difficult to navigate. On top of that, you have to combine the many tools in the landscape together to provide your app’s functionality. This is why Kubernetes is pretty daunting to get started with.

Here are some quick facts to help you get oriented around cloud native setups:

• The cloud-native landscape is full of smaller units or parts that work together called microservices. 
• Your app will need to be packaged up in such a way that everything required to run it is in the same container with it, aka containerization.
• You’ll also want to use an orchestration tool to manage the containers for your application. And this is typically Kubernetes.

Kubernetes cloud agnostic

This is not only theoretically possible but table stakes for most Kubernetes setups: they should be cloud agnostic, or at least mostly cloud agnostic. That being said: this is not easy to pull off and creating a cloud agnostic K8s set up is very demanding in terms of people and time. 

Certain microservices may only work with certain providers, and this introduces vendor lock-in that would make the setup no longer cloud agnostic. In principle, this doesn’t have to be the case although it’s a frequent result.

In practice, once you have nailed down your K8s setup to run on AWS or Azure or what have you, you’re very unlikely to want to go through it all again for a new cloud provider. In a way, the infamous difficulty of Kubernetes operates as a kind of vendor lock-in for any K8s system you’ve successfully set up. Switching costs can themselves become the barrier that keeps you with a provider, rather than any technical requirements to use that provider.

Doing Cloud Agnostic the Easy Way

You expected this paragraph, right? Well, if you’re looking for a way forward with cloud agnostic that doesn’t require weeks of work and trial and error – or Kubernetes – take a look at our docs and at our demos for different frameworks. OpsMaru was created so you can build a cloud platform in minutes instead of days or weeks. It allows you to easily switch between cloud providers too so you can be fully cloud agnostic.