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.
3 Security Teams To Think About Implementing For Your Organization
In this short article, you’ll learn a few key team definitions for any organizations trying to implement a proper security practice. Blue Team When you
PURPOSELY Exploiting A Kubernetes Cluster
There’s only one way to secure a Kubernetes cluster from an application stack (Deployments, Pods, ConfigMaps, Secrets, etc etc.) perspective, and that’s to see and
Exploiting (Pentesting) An AWS EKS Cluster
By default, Kubernetes clusters are not secure in the slightest. Everything from: Not being forced to set SecurityContexts. The default Service Account is used to
AppSec: The Security Specialty That Rules Them All
In this blog post, you’ll learn about what AppSec (Application Security) is, what you need to break into AppSec, various AppSec tools, AppSpec terminology, and
Attacking A Kubernetes Cluster (Enter Red Team Mode)
There have been several reports over the years from organizations like Red Hat and various security research firms and independent engineers that give us a
Implementing Kubernetes Pod Security Standards
Just about every security issue is due to a misconfiguration. Think about it – security bugs are always due to some misconfiguration at the code
Why Python Is Good For Cybersecurity
Whether you’re in the game of automation/scripting or software engineering, there’s a typical question that you’ll ask yourself. “Why this language?”. The answer could be
What You ACTUALLY Need To Know For A Cybersecurity Job
Cybersecurity is arguably the “coolest” IT-style job role in 2024 (others may put cloud-native in that category). Because of that, many engineers are trying to
Impacts Of Not Setting Requests, Limits, and Quotas
Despite the innovation in the tech space from mainframes to servers to virtualization to cloud to Kubernetes, one thing holds true – resources are resources.