Canonical Survey highlights skills shortage in Kubernetes

Earlier this week our friends at Canonical published an interesting survey into the state of Kubernetes and Cloud Native. As a vendor in the space, you’d expect it to be a largely self-affirming exercise validating every aspect of their strategy, however on this occasion it presents a refreshingly honest insight into what’s really going on out there in Kubeville.

 

Canonical asked 1156 professionals 50 questions (which is a lot) about their attitude and feelings towards Kubernetes. The results present a picture of a technology with huge promise, but still in its very early stages of maturity and still with reasonably serious barriers to mainstream adoption.

 

It seems everyone wants to believe this tech is the answer to their IT woes, but not everyone is finding the journey and the transition to Kubernetes an easy one. This validates a lot of our thinking about the technology. We are of the belief that Kubernetes is the future, but for organizations to derive meaningful, and cost-effective benefits from it, then some things need to change….

 

So, here are the 5 data points we found most interesting.

 

 

 

According to the survey, 55% surfaced lack of in-house skills/limited manpower as the biggest challenge to adopting Kubernetes and containers.

 

For us, this number is surprisingly low as we see lack of skills as being a more dominant factor defining the eventual mainstream adoption of the tech. Still to this day, it’s very hard to get started with Kubernetes unless you either 1) hire in (scarce) experts to help you, or 2) invest the time and money to retrain your operations staff in this new technology (and then enter the gauntlet to retain them in the face of their dramatically increased market value).

 

If you’re not familiar, Portainer exists to try and solve this very issue for organizations adopting containers/Kubernetes. Portainer simplifies and abstracts away the inherent complexity that makes Kubernetes hard to operate, and it does this through an intuitive management tool. This allows upcoming and in-demand platform engineers to easily configure their clusters with sufficient “guardrails” that once set, equips developers with the self-service tools they need to get on with building and deploying their apps within safe constraints/confines.

 

 

 

46% of 1141 mentioned that security is the top priority for operators. The next thing on the list is resource optimization and utilization. Again, this is another surprising number as it either illustrates respondents don’t have a deep understanding of the tech (possible) or they’re more advanced than we are giving them credit for.

 

The reason why we’re obsessed with security is that by default Kubernetes isn’t all that secure. Kubernetes is all about giving engineers choice, the choice to decide how their platform is comprised and configured. Unless you either know how to secure your cluster yourself or choose a Kubernetes distribution from a well-known vendor that applies default security rules for you, then you face the risk of running an unsecured cluster.

 

In May 2021, TrendMicro reported that their analysis has found 50,000 compromised Kubernetes Clusters, all of which were running malware containers. For sure, correctly configuring a Kubernetes environment with the identity and access management controls you need is possible using the native tools but it’s crazy hard and time-consuming. In our opinion security – particularly with respect to correctly configured identity management/RBAC is a massive issue for any organization.

 

Portainer acts as an interface between a person and the machine, and so all authentication and access control into the Kubernetes environments is federated and managed by Portainer. This allows you to seamlessly integrate any external authentication provider, and to centralize your users' access and permissions for the environment.

 

3. While 45.6% of respondents report using Kubernetes in production, only 15.7% report using Kubernetes exclusively.

This is arguably the most significant insight from the report for us and it’s almost gets lost in the noise. Only 15.7% of organizations are dedicated Kubernetes shops, which means 84.3% are running a mix of orchestrators. The report doesn’t help us understand what else people are using, but we’re assuming it means there’s some Swarm, some Docker and perhaps some serverless in there alongside Kubernetes.

 

The significance of this can’t be understated. Each time you add a new orchestrator the specialist resource requirements you need on staff increase almost exponentially. For what of a better analogy, Kubernetes speaks German and Docker speaks Greek. So, if you’re running Swarm and Kubernetes you need Greek and German speakers on staff which, in a resource-constrained market, is a huge burden most organizations will really struggle with. Again, it’s a self-serving insight for us, but an important one because Portainer is the Google translate of the orchestrator world. If you use Portainer you don’t need a Greek speaker and a German speaker, you just need a Portainer speaker and unlike German, Portainer is incredibly easy to learn.

 

 

 

Docker Kubernetes comes next with 31.7% votes. This is an interesting data point as it illustrates how quickly the market is changing and how the Docker hegemony is being challenged in the Kubernetes world.

 

Not 3 years ago, Docker was the industry standard for developers but Kubernetes is changing the way developers see and experience containerization. Docker on the desktop is a fine choice if you want to deploy a bunch of containers on your laptop, but if you want to deploy those same containers in a way that more accurately represents “production” then it's likely you will need to use Kubernetes on your laptop.

 

Both Docker Desktop and MiniKube help you with this process, deploying you a self-contained Kubernetes cluster, that you as the developer, administer. This is great if you know how to use Kubernetes, not so great if you rely heavily on CI/CD in production to help ease the deployment journey.

 

Portainer can be deployed by a developer, on their machine, and configured to manage their local Docker and/or Kubernetes environment, providing a really easy interface that acts as a pseudo CD toolset to help deploy their container-based apps quickly and without writing a single line of YAML.

 

Equally, a centralized instance of Portainer can be configured with agents that are deployed on developers' machines, also facilitating easy access/management, but this time integrated with corporate IT access and authentication systems.

 

 

This insight itself isn’t that interesting (other than the note a commentator made assigning ‘Kubris’ to the 11%), however the inverse of the stat that says 89% of people say they can’t do everything they need using Kubernetes is interesting, particularly given who responded to the survey.

 

It reinforces point #1 that Kubernetes is super hard to use and the number of people who truly know how to drive it is impossibly small. There are two schools of thought as to what to do with the complexity problem. One says ‘retrain everyone and get on with it, and the second says ‘hide the complexity and pretend Kubernetes doesn’t exist’.

 

We’re a massive advocate of the second, and if you’re struggling with the complexity of Kubernetes then you should take a look at Portainer.