CommunityDevOps ExchangePartners
Articles
7/23/2021
10 minutes

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

Written by
Copado Team
Table of contents

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. 

Cloud Agnostic and Cloud Native - Copado

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.

Cloud Agnosticism - Copado

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.

 

 

 

Book a demo

About The Author

#1 DevOps Platform for Salesforce

We Build Unstoppable Teams By Equipping DevOps Professionals With The Platform, Tools And Training They Need To Make Release Days Obsolete. Work Smarter, Not Longer.

Building a Scalable Governance Framework for Sustainable Value
Copado Launches Copado Explorer to Simplify and Streamline Testing on Salesforce
Exploring Top Cloud Automation Testing Tools
Master Salesforce DevOps with Copado Robotic Testing
Exploratory Testing vs. Automated Testing: Finding the Right Balance
A Guide to Salesforce Source Control
A Guide to DevOps Branching Strategies
Family Time vs. Mobile App Release Days: Can Test Automation Help Us Have Both?
How to Resolve Salesforce Merge Conflicts: A Guide
Copado Expands Beta Access to CopadoGPT for All Customers, Revolutionizing SaaS DevOps with AI
Is Mobile Test Automation Unnecessarily Hard? A Guide to Simplify Mobile Test Automation
From Silos to Streamlined Development: Tarun’s Tale of DevOps Success
Simplified Scaling: 10 Ways to Grow Your Salesforce Development Practice
What is Salesforce Incident Management?
What Is Automated Salesforce Testing? Choosing the Right Automation Tool for Salesforce
Copado Appoints Seasoned Sales Executive Bob Grewal to Chief Revenue Officer
Business Benefits of DevOps: A Guide
Copado Brings Generative AI to Its DevOps Platform to Improve Software Development for Enterprise SaaS
Celebrating 10 Years of Copado: A Decade of DevOps Evolution and Growth
Copado Celebrates 10 Years of DevOps for Enterprise SaaS Solutions
5 Reasons Why Copado = Less Divorces for Developers
What is DevOps? Build a Successful DevOps Ecosystem with Copado’s Best Practices
Scaling App Development While Meeting Security Standards
5 Data Deploy Features You Don’t Want to Miss
Top 5 Reasons I Choose Copado for Salesforce Development
How to Elevate Customer Experiences with Automated Testing
Getting Started With Value Stream Maps
Copado and nCino Partner to Provide Proven DevOps Tools for Financial Institutions
Unlocking Success with Copado: Mission-Critical Tools for Developers
How Automated Testing Enables DevOps Efficiency
How to Keep Salesforce Sandboxes in Sync
How to Switch from Manual to Automated Testing with Robotic Testing
Best Practices to Prevent Merge Conflicts with Copado 1 Platform
Software Bugs: The Three Causes of Programming Errors
How Does Copado Solve Release Readiness Roadblocks?
Why I Choose Copado Robotic Testing for my Test Automation
How to schedule a Function and Job Template in DevOps: A Step-by-Step Guide
Delivering Quality nCino Experiences with Automated Deployments and Testing
Best Practices Matter for Accelerated Salesforce Release Management
Maximize Your Code Quality, Security and performance with Copado Salesforce Code Analyzer
Upgrade Your Test Automation Game: The Benefits of Switching from Selenium to a More Advanced Platform
Three Takeaways From Copa Community Day
Cloud Native Applications: 5 Characteristics to Look for in the Right Tools
Using Salesforce nCino Architecture for Best Testing Results
How To Develop A Salesforce Testing Strategy For Your Enterprise
What Is Multi Cloud: Key Use Cases and Benefits for Enterprise Settings
5 Steps to Building a Salesforce Center of Excellence for Government Agencies
Salesforce UI testing: Benefits to Staying on Top of Updates
Benefits of UI Test Automation and Why You Should Care
Types of Salesforce Testing and When To Use Them
Copado + DataColada: Enabling CI/CD for Developers Across APAC
What is Salesforce API Testing and It Why Should Be Automated
Machine Learning Models: Adapting Data Patterns With Copado For AI Test Automation
Automated Testing Benefits: The Case For As Little Manual Testing As Possible
Beyond Selenium: Low Code Testing To Maximize Speed and Quality
UI Testing Best Practices: From Implementation to Automation
How Agile Test Automation Helps You Develop Better and Faster
Salesforce Test Cases: Knowing When to Test
DevOps Quality Assurance: Major Pitfalls and Challenges
11 Characteristics of Advanced Persistent Threats (APTs) That Set Them Apart
7 Key Compliance Regulations Relating to Data Storage
7 Ways Digital Transformation Consulting Revolutionizes Your Business
6 Top Cloud Security Trends
API Management Best Practices
Applying a Zero Trust Infrastructure in Kubernetes
Building a Data Pipeline Architecture Based on Best Practices Brings the Biggest Rewards
CI/CD Methodology vs. CI/CD Mentality: How to Meet Your Workflow Goals
DevOps to DevSecOps: How to Build Security into the Development Lifecycle
DevSecOps vs Agile: It’s Not Either/Or
How to Create a Digital Transformation Roadmap to Success
Infrastructure As Code: Overcome the Barriers to Effective Network Automation
Leveraging Compliance Automation Tools to Mitigate Risk
Moving Forward with These CI/CD Best Practices
Top 3 Data Compliance Challenges of Tomorrow and the Solutions You Need Today
Top 6 Cloud Security Management Policies and Procedures to Protect Your Business
What are the Benefits of Principle of Least Privilege (POLP) for My Organization?
You Can’t Measure What You Can’t See: Getting to know the 4 Metrics of Software Delivery Performance
How the Public Sector Can Continue to Accelerate Modernization
Building an Automated Test Framework to Streamline Deployments
How To Implement a Compliance Testing Methodology To Exceed Your Objectives
Cloud Security: Advantages and Disadvantages to Accessibility
Copado Collaborates with IBM to Accelerate Digital Transformation Projects on the Salesforce Platform
Continuous Quality: The missing link to DevOps maturity