Is A Kubernetes Engineer The New Sysadmin?

Throughout my Kubernetes journey, which started in about 2016 (around one year after Kubernetes hit public), I saw the impeccable options that we as engineers have when it comes to an orchestrator. I remember using containers for the first time and thinking “this makes my development so much easier. I just test it locally without having to spin up a Linux box”.

Yes, containers and orchestration made things easier.

However, did it make the job role easier?

In this blog post, I share my thoughts on how being a pro at Kubernetes is quickly becoming a “jack of all trades” role and why I feel that way.

The Sysadmin Way

I remember my first job. I would sit at a bench-looking thing, open up desktops/laptops, and change the components (RAM, hard drive, etc.). I was so happy! I thought to myself “wow, this is great. It’s so much fun. I’ll be doing this forever!”. Little did I know I wouldn’t be (although, I still build gaming computers so… I guess I sort of am). After that job, I moved on. Fast forward a decade and I’m here.

During that decade, one of my first true engineering jobs was being a Systems Administrator. This involved everything from:

• Networking
• Servers
• Infrastructure knowledge
• Security
• Automation
• Storage

and everything else I’m forgetting off the top of my head.

I think I even got asked to look at the microwave one time (I wish I was joking).

Within that role, I literally did everything. It was a “jack of all trades” role. Sure, in some organizations there was a storage specialist or a networking specialist, but for the majority of jobs out there, that wasn’t the case. A Sysadmin had to do everything.

Although, as we all know, it’s always better if a person specializes.

The Kubernetes Way

Fast forwarding to now, we have something called Kubernetes.

I remember first working with Kubernetes I was like “wow, this is awesome! This is definitely a specialty in the engineering space that I want to stick with”.

That was in, I believe, 2016.

Little did I know that Kubernetes wasn’t a specialty at all.

Let’s break down what you need for Kubernetes:

• Networking
• Servers
• Infrastructure knowledge
• Security
• Automation
• Storage

and the other hundred things that I didn’t list.

…. huh, wait a minute.

That….. list looks like the above Sysadmin list.

Ahhh, now you see where I’m going with this!

Over the past couple of weeks, I’ve been getting a lot of specialized work for Kubernetes Security. It got me thinking “wow, this could be a specialty in itself”, and that’s absolutely right.

The thing about Kubernetes is that it’s so broad that you simply need specialists. It’s not even a “nice to have” or an “option” at this point. It’s a necessity.

The Need For Specialties

How does a specialist come about? What do you specialize in? How do you do it? Well, here’s the thing. In today’s world, or at least right now, there won’t be someone focusing on just a specific part of Kubernetes. Well, actually… let’s take a step back. There won’t be a TEAM focusing on a specific area of Kubernetes.

What I envision is a sort of “high velocity” team. For example, let’s say you have eight people on the team.

• Two of them would focus on infrastructure and networking
• Two of them would focus on security
• Two of them would focus on automation (creating clusters, GitOps, etc.)
• Two of them would focus on the development piece

Here’s the reality we live in today – organizations are hiring DevOps engineers and expecting them to do a million things including Kubernetes. Well, I guess that means that the DevOps Engineer role is looked at as a Sysadmin too…. (spoiler alert).

If organizations want to excel, they must begin to start thinking about high-velocity teams. We cannot simply hire smart people and expect them to do everything. Maybe that worked back in the day, but back in the day, we had to update ourselves every 2-5 years. Now? a new product is launching weekly (or daily). That 2-5 years has now gone down to 6 months. With that being said, finding someone that can “do it all” is incredibly impossible, regardless of how much you want it.

Start creating high-velocity teams. Give engineers specializations. Stop expecting engineers to know everything.