Containerising Doesn’t Give You Cloud-Native Status

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

June 25, 2021

5 Min Read

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:

  • 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.

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.

  • Delegation: Offering individuals the tools, training and discretion they need to safely make changes, then deploying and monitoring them as autonomously as possible.

  • Dynamic strategy: Communicating strategy to teams, but allowing them to modify that strategy in response to their own results and findings.

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.

Read more about:

Free Newsletters for the Channel
Register for Your Free Newsletter Now

You May Also Like