Containerising Doesn’t Give You Cloud-Native Status

By Pini Reznik

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:

The above principles are core to the cloud-native approach. If an internet provider, for instance, wants to leverage the speed and other…

…strategic advantages that come with being cloud native, it needs to have a tick next to each of the above elements. If that seems challenging, it’s because it is challenging. But the next step is even harder . . . .

Cultural Principles of Cloud Native

Getting the architectural elements in play is critical, but it’s nothing without the following two cultural elements to go along with it.

Ultimately, cloud native is about how companies create and deliver, not where. So, when channel leaders see an application built and deployed in rapid iterations by a squad of independent, compact, feature development teams – and those teams are collaborating via an integrated platform that decouples infrastructure while providing automated monitoring and testing – that is when you know you are looking at cloud native in action.

Pini Reznik, chief revenue officer and co-founder of Amsterdam-based Container Solutions, is a developer and configuration manager who’s spent more than 20 years improving development processes and shortening time-to-market. This article uses information from a book Pini co-wrote, “Cloud Native Transformation: Practical Patterns for Innovation,” which you can download for free here. The book unpacks a limited-risk way of achieving a cloud native transformation through a methodology called Think Design Build Run (TDBR), which looks at technology, strategy and organisation culture. You can follow Pini on LinkedIn or @containersoluti and @pini42 on Twitter.