Containerising Doesn’t Give You Cloud-Native Status

Written by Pini Reznik
June 25, 2021

Cloud native is a method, not a moniker. It’s cultural as much as architectural.

Pini Reznik

There’s no escaping buzzwords in the world of tech. From DevOps to digital transformation, it’s hard to step – or perhaps more accurately, click — into a boardroom in 2021 without being inundated by them, especially if you’re an IT or telecom channel company.

If you were to create a word cloud of all the tech terms used in boardrooms around the world today, “cloud native” would probably be right there in the middle. The problem is, a recent survey found that more than 95% of IT business leaders claimed to be cloud native, but they couldn’t quite agree on what that meant. Does a business just have to be “born” in the cloud to be classed as cloud native, or is simply putting some processes in the cloud enough? Perhaps dabbling in containerisation with a tool like Kubernetes is enough to get into the cloud-native club?

Here’s the thing: Cloud native isn’t any one group of things. It’s a way of doing those things. Cloud native refers to a particular approach to designing, building and running applications that isn’t so easy to pin down and label. It’s a complete architecture; a philosophical approach to creating applications that take full advantage of everything cloud computing has to offer. It affords businesses, including MSPs and VARs, the flexibility and agility to move at pace, pivoting rapidly into new routes-to-market and leaping on ideas as they arise. Lead times on new ideas are measured in hours rather than days, allowing organisations to respond to turbulent and unpredictable market forces. It’s difficult to think of a year on record more turbulent and unpredictable for companies than 2020, and that’s why cloud native has a seat at the table in boardrooms.

But are businesses in the IT and telecom sector — groups who are the precursors of digital transformation processes — leveraging cloud native to its fullest potential? If a managed service provider thinks that pulling a tool like Kubernetes into its arsenal makes it cloud native, it’s sadly missing the point. Containerizing your first application is nothing but a drop in the cloud-native ocean, and here’s why.

Putting Culture Above Containers

One of the biggest mistakes IT companies tend to make when “going cloud native” is putting architecture above people. And that makes sense — after all, architecture is at the core of their businesses. Containerization, microservices, automation and orchestration are essential to the cloud-native philosophy, but they don’t add up to much if a business doesn’t bring its people along for the ride. In a recent survey, the Cloud Native Computing Foundation (CNCF) found that “cultural changes within the development team” was seen as the No. 1 obstacle to embracing cloud native; that makes it a more important issue than security, complexity, training, storage and vendor support for the majority of businesses.

It can’t be said enough: cloud native isn’t simply a case of exchanging one set of technologies for another set of technologies. It’s an entire culture, and you can’t have a culture without people. So, with that out of the way, what are the fundamentals of cloud native?

Architectural Principles of Cloud Native

We’ll move onto the all-important cultural principles shortly. But first, let’s quickly run through the architectural principles of the cloud native approach. To even consider defining itself as cloud native, a business should have a firm grip on the following:

Containerisation: A method of “packaging” or encapsulating an application in its own virtual run-time environment, complete with the dependencies it needs to function, making it easy to test, move and deploy.
Dynamic management: Using cloud-based servers that can be flexibly provisioned on demand. Typically this will also allow businesses in a public cloud environment to only pay for the resources they use.
Microservices: Designing applications as a collection of small, independent components that are decoupled from business-wide dependencies. These microservices can be deployed, upgraded, scaled and restarted completely independent of other services, making businesses more agile and resilient.
Automation: Being able to replace manual tasks like maintenance and updating with scripts or code so they happen independently and reliably.
Orchestration: Tying all of the above together by automating the deployment, scaling and management of containerised applications, often using a tool such as Kubernetes to control and automate tasks.