Organisational Benefits of Kubernetes

Before actual collaboration with companies and providing our professional Kubernetes training, we often have to explain the benefits of Kubernetes to several stakeholders, especially at the enterprise level.

We believe that the Kubernetes community does a very good job explaining the technical details and benefits of switching to its technology base. However we also believe that we can do an even better job at advocating it at the management level.

Technical champions inside organisations sometimes have a hard time understanding the perspectives of various stakeholders inside their organisations, so we thought we’d make a “how to convince your boss” list of benefits of a Kubernetes transition to communicate its advantages more effectively.

Most benefits can be summarised in one word - standardisation, but let’s dig a bit into specifics.

Standardised hiring

A standard job post for a backend/DevOps person just a few years ago used to include a list of requirements which usually included a permutation of several of the many technologies available at the time (Puppet, Chef, Ansible, Docker Swarm, Mesos…), mostly driven by the requirements bespoke backends of each company.

To achieve things coming out-of-the-box with Kubernetes, backend and DevOps teams usually built their own solutions out of necessity, using tools they were personally familiar with. This made finding people with exact needed skillsets hard and usually included a long onboarding time.

Looking at job postings of companies utilising k8s right now we see a simplified job posting, focusing on Kubernetes experience with a few “nice to have” skills.

A big objection to keep in mind is that Kubernetes is a fairly young technology and finding qualified engineers can be harder, but a whole ecosystem of education and certification has sprung up in recent years (including MSB), so it’s becoming less relevant.

Standardised configuration management

A major advantage, that we feel is not being talked about enough is standardisation of configuration management inside k8s.

In every company I’ve personally worked in the past, a large part of onboarding has been just knowing how to store, use and find various configurations necessary to access in my services. There were usually a few “old-timer” DevOps who knew how everything fits together and where the various configurations were stored, and they were indispensable to the running of the company.

In companies that are advanced k8s users we currently see the DevOps teams being freed up to focus on process automation, building whole project templates that allow you spin up and integrate whole services in no time, with security, secret management and processes built in, so engineers can focus on building the actual services. This allows engineers not only to build their own services, but also to be able to quickly jump into other teams' services and have a good understanding of how things work.

Enforcing standards

A big part of Kubernetes' mechanisms that don’t get enough attention are mechanisms that allow you to encode various security and process requirements into the cluster itself, ensuring a standard baseline of security and governance practices that have to be respected before a workload is permitted to be deployed on the cluster.

Various admission controllers allow you to enforce best practices through code and reduce micromanagement overhead of your teams.

This is a somewhat advanced topic, but we think it’s not discussed enough and important enough that we have a whole day training devoted just for this topic.

Easy access to a huge software ecosystem

Almost every open-source or commercial project currently offers a Helm chart or a Custom Operator to deploy directly into your cluster using a standardised and fully configurable interface.

Here’s an example of a highly available postgres cluster being deployed with one command and visualised using the MSB platform:

This allows teams to choose technologies needed for running their services and spend minimal time deploying them, while knowing best practices are followed. Most engineers are not experts in deploying things like high availability elasticsearch clusters, and before k8s a lot of preparation had to take place to ensure a production-ready system. Currently we get the benefit of the community or vendors spending time optimising their packages, so we can easily configure and use them.

Removing vendor lock-in

This point has been reiterated multiple times, and research shows that organisations rarely take advantage of it, but it’s still important to keep in mind. Kubernetes provides a standard API to which all cloud providers have to conform to, giving you the flexibility to negotiate and switch providers once operating at a significant scale.

We hope you’ll take these points into consideration when deciding on your Kubernetes strategy, or they will be useful to you to convince your organisation to make the switch.

If you’d like to hear first hand from a professional selling k8s into organisations, please have a listen to our podcast episode with Jeroen Overmaat, Rancher NEMEA Regional Director