As Kubernetes continues to gain traction, Kubernetes related oppurtunities continue to grow as well. That's great! But while most Kubernetes related engineering roles are pretty similar to each other, in my observation, there seem to be important differences between them as well.
Here, I just want to capture the three main flavours Kubernetes related Engineering roles I've noticed and their pros and cons.
Site Reliability Engineer
Also known as DeveOps Engineer or Cloud Engineer, the Site Reliability Engineer role is the most common of the three we'll talk about today. The distinguishing sign of the role is that you're responsible for (a) production Kubernetes cluster(s) and your team is primarily measured by it's reliabilty, cost effectiveness and utility.
Google has written a lot about the role and different companies abide by that description to various degrees. This is also the only role of the three, that I have personal experience with.
- Hands-on Experience operating (a) Kubernetes cluster(s) i.e
- Lots of Production Insights to share with the rest of the community
- Incentive to influence the Cloud Native Community to solve important problems together
- Lots of fun for folks who enjoy learning new things all the time
- Lots of opportunities with the growing no. of businesses adopting Kubernetes
- Time & Focus are divided between programming, operations & communication. Ergo:
- Limited chances to role the dice on long term software projects
- Wide scope of respobsibility i.e:
- The whole cluster rather than just Ingress, although possible in a big enough team
- Shifting respobsibilities as Cloud vendor capabilities grow/change
- Employer may not have the bandwidth/budget for significant community participation
Software Engineer ( Kubernetes )
If you've ever wondered who maintains, the Kubernetes Core or important plugins like CoreDNS, it's Kubernetes Software Engineers. I'm making up the title but the work is real i.e. Software Engineers improving or extending the Cloud Native ecosystem.
This role predominantly exists with vendors with a vested interest in Kubernetes like Cloud vendors or Services companies. Google, for example, has a whole team dedicated to maintaining the Cluster, Horizontal & Vertical Pod Autoscalers.
- Focus on Software Engineering Skills
- Potential to learn the internals of various technologies e.g. Prometheus, Docker, Flagger and share with the community
- Opportunity/Incentive to represent customer use cases in the larger Cloud Native Community
- No quick “production” feedback like in SRE
- Limited Experience operating a kubernetes cluster
- Reletaively fewer oppurtunities in the community, but still lots of them!
While vendors might hire Software Engineers to help improve their Kubernetes offerings, they might hire Engineers to better understand the community's needs and help guide the product strategy. That's the Developer Advocate role and there's a growing no. of them in the Cloud Native Community.
If you're not familiar with the role, there's a great FAQ by Dustin Ingram.
- Great opportunity to learn in public
- Work on skills such as giving talks, Videography, Writing Blogposts
- A very visible position, great opportunity to create a public profile
- Incentive/Oppurtunity to create significantly useful resources for the community:
- Writing books and etc.
- Creating or maintaining to important open source projects
- The chance to explore "what’s possible with Kubernetes”:
- Creating lots of “demo” apps to show what's possible with Kubernetes
- Being "user zero" for new products or features
- Great opportunity to be valued as an engineer for strengths in:
- Stakeholder management
- Product leadership
- Far fewer oppurtunities than a SRE or SWE roles
- Role not well defined and may change significantly between companies
- Evangelism vs. Advocate
- Report to marketing vs. director of engineering
- May require lots of travel
- Difficult to distinguish between work and hobby projects
- Not clear what the employers' non-compete for the role look like:
- If you write a book, create a youtube channel does the employer need to sign off?
- Almost no first hand production experience in the role
- Hard to measure your impact:
- makes it hard to know what's worth working on
- makes it hard to prove that you're doing a good job
All three roles seem to have a lot to offer and like flavours of an ice cream, they can be mixed and matched. Software Engineers give talks and Site Reliability Engineers write plenty of software. Folks might also be able to move between these roles easily enough.
I hope others find this list as helpful as I did. If you feel like I've missed an important aspect of these or would like to share other kinds of engineering roles you've seen in the Cloud Native community, I'd love to hear from you!
Top comments (0)