Loud Narrative on Cloud Native

To understand what cloud native really means, we first need to do a “match the following” exercise.

Match the following statements:

1. Cloud-native is about how applications are created and deployed, not where.
2. Cloud-native is about using containers and Kubernetes to deploy and operate applications
3. Cloud-native is about utilizing fully managed auto-scale services in the public cloud
4. Cloud-native is about utilizing DevOps oriented methodology to operating applications

With the following makers:

a) A cloud company which hasn’t broken much ground in the container world but has a popular alternative using managed services

b) A company providing tools and/or services around DevOps processes and automation

c) An IT company which did amazing business in the pre-cloud era but struggling to stay relevant in the age of the cloud

d) A powerful open source foundation with serious marketing muscle, and that backs many container tech OSS projects

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 cloud, may not be 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 of 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 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 DevOps oriented methodology to operating applications

Automation, continuous integration, continuous delivery/deployment are some things that come to mind when people say DevOps. These concepts are not really new and even if they are, they can be (and are being) used for delivering software that has nothing to do with cloud — either for running or building such software. Which part of DevOps fairy dust exactly then 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. I am accepting proposals for good definitions (50 words or less).