What Does "Building a Cloud-Native Application" Really Mean?

To understand what cloud-native really means, we first need to do a “match the following” exercise. Match the statements in the left column with the tech company that would have said this statement.

If you guessed 1c, 2d, 3a, and 4b, then you are getting a fairly good idea of where this write-up is headed.

In this write-up, there will be hyperbole, there will be ridicule, and there will be rhetoric.

Unfortunately, all of it is quite well earned when it comes to the topic of “Cloud Native Apps”. Like many others in the tech industry, cloud-native, too, is an overused (even abused) term.

The definition of cloud-native apps changes from vendor to vendor, depending on what they have to sell, and from thought leader to thought leader, depending on what they have to thought-lead (or should it be think-lead? I always get confused).

Let us look at the first statement.

Cloud-native is about how applications are created and deployed, not where.

So, “where” is not important — may be the cloud, may not be the cloud. Then what are cloud-native apps native to really? An app running on-premises, if built using the “right architecture, processes, and culture” seems to have earned the right to be called cloud-native. It is like saying an app running on Android or Windows is “native to iOS”.

I thought an app had to utilize some special characteristics and be optimized for the underlying platform to be called native to that platform.

Anyway, we move along.

Cloud-native apps are built using containers and orchestrated using Kubernetes

When exactly did we decide that a packaging format for deployment and the use of a super complex resource orchestrator makes an application modern?

Isn’t the idea to make sure that your app can accomplish what it has set out to do with the scale, availability, and reliability expected of it? Then why such specific requirements as the use of a packaging format and a sci-fi-esque-sounding technology?

Anyway, by having a name (and more importantly a domain name) resonating with the term “Cloud Native”, the Cloud Native Computing Foundation (CNCF) has earned the SEO ranking to provide a credible-ish definition.

So, we move along.

Cloud-native is about utilizing fully managed auto-scale services in the public cloud

No prizes for guessing the reference here is to AWS and their Lambda lovefest. It is a valid alternate narrative — focus on business logic expressed through code, don’t worry about where the code is running, how it scales, how the database is configured, how messages arrive, etc.

In terms of doing justice to the “cloud-native” claim, it comes close — unprecedented scale and reduced infrastructure management have been consistent promises of the cloud since the early days.

However, “short-lived pieces of code execution” suffering from things like “cold-start” (which can best be explained as a side-effect of internal implementation now unduly forced upon the customer cognition), are not suitable for all the computing people are doing. Not today at least.

Let us keep going.

Cloud-native is about utilizing a DevOps-oriented methodology to operate applications

Automation, continuous integration, and continuous delivery/deployment are some things that come to mind when people say DevOps. These concepts are not really new and even if they were, they can be (and are being) used for delivering software that has nothing to do with the cloud — either for running or building such software.

Exactly which part of DevOps fairy dust makes this software cloud-native is not clear.

Even though this write-up sounds like venting, it is really meant to call out how so many of our statements (“our” being the tech industry) seem not to make sense even after one double-click. So, we should keep trying.

Also published here