CloudRoads

View Original

Cloud-Based ≠ Cloud-Native ≠ Cloud-Agnostic

Published on Mar 16, 2021 | 5 Mins Read

Throughout the past few months, I have been having discussions with IT leaders regarding a wide array of topics. There’s no doubt that the pandemic has accelerated cloud adoption especially for those industries that are thriving.

One of the interesting topics discussed that’s confusing to many is cloud-based vs. cloud-native vs cloud-agnostic. While the three approaches are somewhat similar and related to cloud computing, they’re drastically different in terms of application development, infrastructure, and architecture.

While this is not an either/or decision to make when building for the cloud, In this blog post I will demystify the pros and cons of each and highlight key capabilities.

Cloud-Based

While there’s no one standard definition of cloud computing, I prefer to have two definitions. One for the common person and another for the tech-savvy one.

For the common person, I describe it as electricity. We all need to have electricity to power our appliances, preserve our food,  and stay warm in the winter. Similarly, organizations large and small have  IT needs (compute, networking, and storage) to do business and compete in the marketplace. They can either build (i.e: on-premises datacenter), rent (i.e: colocation data center), or consume what you need when you need it (i.e: cloud providers). 

For the tech-savvy, I describe it as someone’s data center that provides the aforementioned IT needs in a very unique way that is:

  • API-centric

  • Self-service

  • Elastic

What does that mean for Enterprise IT? It means the ability to programmatically deal with almost all of IT needs in terms of computing, networking, storage, security, ..etc in a self-service and elastic way as demand goes up or down. 

Such requirements can be met in the datacenter (i.e: on-premises ) using one or more private cloud platforms and we call it private cloud. Both in the data center and a cloud provider and we call it a hybrid, or across multiple cloud providers and we call it Multi-Cloud. 

A cloud-based approach would take advantage of such unique characteristics to scale up or down applications, provision resources on-demand, and overall improve the speed to build and release software. 

For example, a traditional 3-tier application that has been re-architected to benefit from cloud-specific features such as elasticity, auto-scaling, and scalability is considered a cloud-based application. 

Cloud-Native

Luckily, we have an agreed-on definition for cloud-native computing from the CNCF -- A sub-organization of the Linux Foundation that supports the advancements of cloud-native computing. As of 2019, the v1.0 definition says:

Cloud-native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.


These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

In a nutshell, you can think of cloud-native applications as cloud-based applications grounded in containers.  While you may be able to operate containerized applications in a traditional datacenter, they won’t be able to utilize the unique features aforementioned for the cloud in terms of API-centricity, self-service, and elasticity and hence won’t be cloud-native in nature.

The exception would be if you decide to invest in a private cloud platform in your datacenter.  This can enable you to run cloud-based and cloud-native applications. In fact, many organizations prefer that model for reasons related to cutting costs, security, and compliance. 

It’s important not to confuse microservices with cloud-native. Microservices is an architectural style built on the idea of building decoupled services. Each service does one thing and does it well.   While there are benefits of using containers over VMs for microservices, Microservices can be implemented using containers, virtual machines, serverless,..etc. 

Cloud-Agnostic

Usually, Enterprise IT is driven by cost, security, and uptime. CIOs want to juggle those three while spearheading digital innovation, setting strategy,...etc. 

A public cloud approach can help increase uptime but cloud spend and security might be a concern. A private cloud approach can help reduce costs and increase security but uptime might be a concern. Even a hybrid cloud approach can address some but not all of such factors.

For that particular reason, IT leaders want to formulate a cloud strategy that’s adaptable. Having said that, They might subscribe to a cloud-first strategy for net-new applications but decide that certain parts of their application portfolio should be cloud-agnostic. 

The main drivers of going cloud-agnostic are usually avoiding vendor lock-in and assuring a predictable performance across almost any infrastructure. While cloud-native applications are inherently portable since they’re grounded in containers, they are usually platform-specific (i.e: Kubernetes) and that can pose a challenge in terms of networking, storage, and security.  

You can think of cloud-native as one approach to going cloud-agnostic but certainly not the only way.

The following table summarizes the different approaches and the pros or cons of each: 

See this content in the original post

IT leaders should consider the aforementioned approaches as tools in their toolbox as they’re not mutually exclusive. While there’s no one size fits all approach, one should thrive to find the best-fit product or service for his/her particular situation.

Some enterprises developed a cloud-first strategy years ago such that everything has to be cloud-native.  Always assess your current situation and keep in mind that the crawl-walk-run approach can go a long way provided that you set a solid strategy and execute on it.