Are you confusing Cloud-Based vs. Cloud-Native?

Are you using the term "cloud native" wrong? After chatting with many IT leaders, we realised there is a general confusion between cloud-based vs. cloud-native. (And sometimes cloud-agnostic, but that's a discussion for another day). They both relate to cloud computing, but has very different architecture, infrastructure and app development.

In this short post, we take a stab on explaining the two.

?. Cloud-based refers to application/resources that are hosted in a public or private cloud.

?. Cloud-native, according to the official definition from Cloud Native Computing Foundation (CNCF) is:

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.

Simply put..

Your application using AWS/Azure/GCP managed service is most definitely cloud-based. And if the same app is built with containers with a loosely-coupled microservice architecture using declarative API, deployed in a Kubernetes cluster, then it's cloud-native.

On the flip side, if you're on a public cloud but your application is deployed in a virtual machine and don't use containers, then you're not cloud native. If your application is using mostly fully managed services and has little portability between the cloud providers, then you're not cloud native.

You might ask:

"Ok, so what if I use cloud and cloud native interchangeably? Isn't most modern software cloud native anyway? Why is the distinction important?"

Because saying your application is deployed on the cloud, and deployed in a cloud native way means something completely different.

Imagine this:

Your boss asked you to build a computer vision solution in a cloud-native way, but instead you leveraged a cloud-based managed service: AWS Rekognition, Lambda Functions, Dynamo DB and S3.

The computer vision app is quickly deployed and created immense value for the business. The boss is happy, you're happy. Unfortunately, she assumed but poorly articulated that the reason the app has to be cloud-native is because your company is going Azure in two months.

She expected a general portability for your app, which is the main selling point for cloud-native, and asks you to move this app from AWS to Azure. Instead of 2 months of re-integration, you have to completely re-architect and re-build your solution from scratch.

There is nothing wrong with the architecture you built. It's just miscommunications.

Bottomline:

Miscommunications attribute to 90% of confusion.

So avoid this disaster by using the right cloud-term ??

----------

We're trying out this LinkedIn Newsletter thing, and committing ourselves to publishing at least one piece of article per month. So hit subscribe if you want to be our guinea pig ??