Cloud Agnostic vs. Cloud Native: What’s the Difference?

Someone at work recently asked, "What is the difference between cloud agnostic and cloud-native?"

‍

As we compared and contrasted the two terms, I had a realization — there’s no difference. While one is technically a subset of the other, cloud native and cloud agnostic are really two sides of the same coin. Let’s dive in and explore the ins and outs of each concept. 

‍

Cloud native: Deploying cloud-based environments at scale 

‍

Cloud native is all about your technologies and how you leverage them. Here’s the official Cloud Native Computing Foundation (CNCF) definition: 

‍

"Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds.”

‍

In order to achieve cloud native status, your applications must be scalable and live in the cloud. That's it. Examples include containers, service meshes, microservices, immutable infrastructure, and declarative APIs.

‍

Cloud native means you're able to deploy successfully in the cloud (no added bloat or antiquated design principles). But it doesn't specify which cloud. Public, private or hybrid — it doesn’t matter. 

‍

Cloud agnostic: Designing applications to function in any cloud 

‍

If cloud native is a strategic approach, cloud agnostic is more of an ideology followed by an organization — software engineers, developers, managers, etc. It simply means your cloud native applications are designed to work in any cloud. 

‍

Unlike cloud native, there are no dependencies on one provider, public or private. But if you are cloud native, you should also be cloud agnostic. Unfortunately, technologies and the people that use them aren’t always truly agnostic. Here are some examples to show you what this looks like in real life. 

‍

‍

Why are so many cloud native tools not cloud agnostic?

‍

In many cases, cloud native applications are deployed using DevOps and Git Continuous Integration (CI) methodologies. However, a great deal of the cloud native tooling out there isn’t cloud agnostic. For instance, deploying in AWS uses one set of resources and code, but deploying in GCP or Azure uses completely different code. 

‍

I've been doing a lot of work in Terraform lately, and this is one of my biggest gripes. But this isn’t just a Terraform issue — it’s a problem across all the available tooling: 

‍

To deploy a virtual machine in GCP, you use the resource <code>google_compute_instance</code>. But in Azure you use <code>azurerm_linux_virtual_machine</code> and in AWS it's <code>aws_instance</code>

‍

Why? Why is everything different? And more importantly, why is the onus placed on the end user to figure this out? 

‍

This pain point serves no purpose — it's just bad naming and abstraction. It often happens because providers are written by different teams and companies. But if another layer of abstraction was added, I would be able to declare the thing I want, point it at a cloud provider, and it would happen. Imagine this: I want a virtual machine with:

• 8 cores
• 32GB RAM
• 30GB disk
• Networking set up a certain way
• Firewall configured to allow traffic on a couple ports

‍

I declare all of that and deploy to a cloud. Then, if I want to change providers, I tweak one line and now I'm deploying elsewhere. That would be truly cloud agnostic. But when the language is cloud-specific, we have yet to realize cloud agnosticism.

‍

‍

Here's another angle to consider. How often have you been forced to use one cloud provider because all your stuff is already there? Or simply because it's what your engineers know? How many times have you cobbled together a solution because it wasn't clear which services already exist for your use cases?

‍

If one provider is bleeding you dry, wouldn’t it be nice if you could easily switch to another solution? So why are we still designing systems that are provider dependent?

‍

Evolving to cloud agnostic

‍

Let's boomerang back to our original question. Being cloud native does not necessarily mean you are cloud agnostic. It all depends on your tooling. Even if 90% of your tools are cloud agnostic, one or two incompatible services could hold you back. 

‍

Emphasizing a cloud agnostic mentality during the decision process is a great way to proactively solve these issues. But make sure you stick to that decision across the entire software lifecycle — it’s extremely easy to slip into single-cloud dependencies.

‍

Just because you are cloud agnostic does not mean you have to be tool agnostic. Major cloud providers offer many of the same services and tools, which gives you the flexibility and resources you need without compromising your cloud agnostic stance. 

‍

Keep in mind — if you're dependent on cloud-specific services, your ability to change is going to be hindered. But if you can abstract and keep your applications away from talking directly to cloud APIs, you’ll be two steps ahead.

‍

Architecting a standardized future

‍

The world has been on a cloud native trajectory for years now. It's about time we created standards for providers to follow. Let’s make deployments happen seamlessly between any provider.

‍

While there’s also plenty of room for innovation at the provider level, the concepts of cloud native and cloud agnostic are well established at this point. There is little reason not to standardize. This will enable more and more companies to seamlessly transition to the cloud — which will make the world more secure and convenient. 

‍

Within the walls of each company, there also needs to be a clearly defined and easy-to-use standard for everyone to follow when they want to deploy or reach out to a service. And there's even a discussion worth having about the level at which this standard should be written and followed. 

‍

Should it be for individual teams? (Please no!) Or would it make more sense at the organization level? Company-wide? It all depends on your objectives. 

‍

Adopting cloud agnostic: From definition to deployment

‍

Let’s go over a brief history lesson of the cloud. Initially, IT infrastructure and applications lived in on-premise environments with best practices designed for this setup. Then the cloud native idea gained traction and people moved their infrastructure to it. 

‍

But many enterprises only became cloud native on one cloud. Even though they leveraged cloud technology, they were dependent on a single provider. This means they weren’t technically cloud native.  

‍

Next, businesses started deploying in multi-cloud environments. While this gave them more options and flexibility, they were still very environment-dependent.

‍

Cloud agnostic is the next frontier — a truly standardized, universal infrastructure that enables companies to drive seamless, multi-cloud deployments.

‍

If this approach is still new to you, here’s some good news: you can adopt the cloud agnostic mentality now and skip many of the steps along the way. Trailblazers have already learned (and documented!) the headaches and lessons learned throughout their transitions — allowing you to bypass these issues and revolutionize the way you do business.

‍

So what’s the difference between cloud native and cloud agnostic? 

‍

Cloud native is a practice. Cloud agnostic is an ideal — the next step. If you are cloud native, you are on track to being cloud agnostic. Or at least you should be. And if you need any help along the way, Copado can step in and accelerate your digital transformation journey.