Why do people think Kubernetes is cloud native?

After I published my blog about the top five ways to tell the difference between #fakecloud and the real thing, the most controversial item turned out to be number four: why Kubernetes isn’t “cloud native.” So I decided to dedicate an entire blog to help everyone understand why I think this is a true statement.

First, a little history

Back in the days before the cloud, software applications were tied to the hardware servers they were running on. The public cloud came along, and Amazon Web Services (AWS) started to offer what would later become juggernaut services for the company: storage and compute. 

It was storage and compute, but in AWS’s cloud. As adoption accelerated, more and more services became available and technologists worked to swap non-cloud objects for more and more cloud infrastructure. Everyone was working to replace physical, machine-based systems.

During this transition, some folks at Google saw the possibilities that cloud architecture offered and had an idea on how to break totally free from hardware dependencies with… containers. Kubernetes (K8s) was born (yes, Google is the father of K8s), bringing the world a new layer of abstraction from physical servers.

Rather than keeping K8s as a proprietary product, Google decided to open source it, and the Cloud Native Computing Foundation (CNCF) was formed. Its objective was to support people building things specifically for the cloud so that technologists across industries and around the world could harness all the new possibilities and help push things forward. Still today, the CNCF’s mission is to “make cloud-native computing ubiquitous.”This tweet thread from David Aronchick explains how he was “in the room where it happened,” and how we have come to call Kubernetes cloud native. Basically, we call it cloud-native because everyone agreed it was an early way to get things into the cloud, overseen by a foundation with “cloud native” in the name, and developed by a group that saw the opportunities of cloud-native architectures and understood that Kubernetes offered a way to get there. The rest is history.

K8s: What is it good for?

Back to the present and Kubernetes. Don’t get me wrong: using K8s to get things up and into the public cloud is a great first move. But read this handy Cloud Architecture Maturity Scale, which puts Kubernetes at level two in its zero-to-five ranking. It isn’t the worst, but it’s not always the best, either. Like my friend Forrest Brazeal explains in his “The lift-and-shift shot clock” blog (and also on my podcast), Kubernetes can be a great first step to the public cloud, because it can get you there quickly. As soon as you are there, though, you have to start thinking about how to optimize software for the public cloud and sometimes that means moving OUT of K8s.

In telco, I see too many companies use K8s as their final destination instead of as a stepping stone. Sometimes it is the right solution. It’s important to understand the technical and operational tradeoffs of your decision for the particular situation and optimize appropriately.

So, what is “cloud native?”

You may be wondering, “If Kubernetes doesn’t qualify as cloud native, then what does?” The term itself is hard to define because technology changes quickly and different people apply the term differently (like to their old on-prem solutions!). So I’m going to tell you what I think it means, as of today.

Cloud-native technologies are:

• Built for the public cloud and run on a public cloud from Amazon Web Services, Microsoft Azure, or Google Cloud
• Dramatically cheaper than their old, on-premise equivalents
• Infinitely scalable both up and down without human intervention
• Resilient and self-healing
• Using specific databases that are purpose-built for different analytical or storage use cases
• Lightweight, using well-defined APIs, and priced by the usage
• Dynamic, leveraging serverless technology when appropriate

For telcos running legacy software, achieving a cloud-native tech stack means that you’ll probably be re-architecting most things for the public cloud (or buying software that is public cloud native off the shelf). Kubernetes can help you make the initial leap. But you’re not going to get the massive benefits of the public cloud unless you bite the bullet and start to understand the use cases where K8s is the right choice, and when it’s not needed and complicates your operations. Figure that out, and you’ll be on your way to cloud nirvana.

Recent Posts

Get my FREE insider newsletter, delivered every two weeks, with curated content to help telco execs across the globe move to the public cloud.

"*" indicates required fields

Email*

Name

This field is for validation purposes and should be left unchanged.