‘Cloud native’ confusion continues

I’m not a big fan of tech buzzwords. Even the term cloud computing has driven me nuts at times, and of course new tech terms are created all the time.

Full disclosure, I use buzzwords to communicate ideas if those buzzwords are the way the industry currently explains concepts, such as Internet of Things, edge computing, machine learning, and so forth. Some buzzwords hold on to their meaning for a longer period of time, and we eventually define them in a relatively consistent manner. 

That does not seem to be the case with the term cloud-native computing. If you want to go down a rabbit hole, just Google “cloud native” to see how many ways it’s defined. Little wonder there is still a lot of confusion about what is and isn’t cloud native. However, most of what we associate with cloud native has a great deal of value, such as the ability to build and deploy better systems. 

Perhaps it’s time we defined the concept better. Here are three different ways I see the phrase cloud native being used. 

First, we have vendors who have “cloud native–washed” all their technology, no matter what it is or what it does. These guys put the “cloud-native” buzzword into the descriptions of their products’ features and functionality. 

Second, we have those who define cloud native just how it sounds—the ability to develop systems that leverage cloud-native services. This would include cloud providers’ services such as cloud-based security, cloud-based governance, auto-scaling, serverless, etc., or the ability to leverage a service that’s native to a specific cloud provider. 

Finally, we have wider definitions of cloud native. This would include the Cloud Native Computing Foundation’s (CNCF) explanation: “technologies [that] empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds.” Or, perhaps better put, cloud-native applications can be deployed across multiple cloud environments; this is core to the cloud-native proposition. 

The previous take is that cloud-native applications are bound to specific native-branded cloud services, meaning that lock-in is a likely outcome. The CNCF works with a larger idea that if you do cloud native right, you’ll provide dynamic and scalable application behavior on many platforms, including public clouds, private clouds, and even legacy systems. Typically, this requires the sophisticated use of containers, container orchestration, and microservices to avoid lock-in, which is a desirable outcome of going cloud native. Usually, these systems define a common stack where the private and public clouds are the foundation, but the foundation clouds don’t typically provide services directly to the application. For the record, this is my pick for a better architecture. That is, if you define cloud native the CNCF way. 

The trouble with all the confusion is that it detracts from the overall concept of cloud native, which is valuable. So yes, I’m a bit concerned—not with those who have their own opinions about cloud native and won’t have their minds changed, but with IT leaders who are still trying to figure out the true meaning of cloud native and if it should be part of their futures. 

We may be shooting ourselves in the foot with this one. Just saying.