Earlier this month I took the exam for the Kubernetes and Cloud Native Associate (KCNA) certification and passed.
After years of working in AWS Serverless, this raised some eyebrows. People asked: why?
Here's the honest answer: I've passed on applying to jobs because I didn't know Kubernetes (K8s). That needed to change.
The Reality of Job Postings
Look at DevOps and platform engineering roles today. Many of them want AWS experience, serverless knowledge, AND K8s expertise. Not all, but enough that it's a pattern.
Specializing deeply in serverless has been valuable for my career. But at some point, gaps in your knowledge start closing doors. When I'm scanning job postings and thinking "I could do this role, except for that one requirement," it's time to consider filling the gap.
This isn't about chasing every new technology. It's about recognizing when a skill has become common enough in your field that not having it limits options.
What "Best Tool for the Job" Actually Means
I still believe in "serverless first." But here's what I've learned: the best tool depends on context.
At the end of the day, users care that what you build is reliable, works, and solves their problem. Unless they're an engineer or tech geek, they don't care if you used K8s or serverless. They care about the outcome.
Tech decisions are made by people. People make choices based on their experiences and what they know. A lot of teams use K8s. Whether they "need" it is a value judgment that depends entirely on your perspective and experience. That's not what this post is about.
What I've realized: if I'm working with a team that's chosen K8s, fighting against that to use serverless creates friction. Understanding their world helps me work with them effectively, even if I'd make different choices.
This isn't about one technology being better than the other. It's about understanding enough of both to collaborate with different teams and make informed decisions when I do have a choice.
K8s Is Complex, But Learnable
People aren't wrong when they say K8s is complex. It is. There are a lot of moving parts.
But here's what studying for the KCNA taught me: if you take the time to understand the components and how they fit together, it's not magic. It's learnable. Breaking it down into pieces makes it manageable.
The complexity isn't a reason to avoid it. It's just a reason to approach it systematically.
My Advice: Depth First, Then Breadth
If someone asked me "should I learn K8s?" a year ago, I would have said: get really good at one thing first.
Master the fundamentals of whatever stack you're working in. Build that depth. Then expand your toolbelt.
Trying to learn everything at once means you'll be mediocre at many things instead of excellent at one. Depth first, breadth later.
Disclaimer: this is what works for me. Your situation might be different, and that's okay.
That's what this K8s certification represents for me. Not abandoning serverless or becoming a "K8s person." Just adding another tool to solve different problems.
What's Next
The plan is to complete the Kubernetes Resume Challenge and build some personal projects. The goal is practical knowledge, not just cert credentials.
Honestly, it's been fun to be a beginner again.
I'd love to hear from you: Have you learned outside your specialty? What pushed you to do it, and what did you learn in the process?
Top comments (0)