I'm currently leading a small team of three Golang developers and three SREs to create a company-wide platform utilizing Kubernetes. We're aiming to support around 2000 microservices. Our responsibilities include maintaining the AWS cluster, overseeing worker nodes, managing CNI, implementing authentication and authorization through OIDC, handling the pod auto-scaler, and working with daemonSets like log collectors and Otel collectors. We're also in charge of Argo CD and the development of Helm charts, which we're planning to replace with Operators and CRDs. I'm curious to know how other teams similar to mine are structured. Specifically, what's your team size? How many teams do you have managing the platform? Are the same folks who handle chart maintenance also maintaining the Kubernetes API and infrastructure? I'd love to learn more about your team's setup and how effective it has been for you!
5 Answers
I’m the only DevOps engineer for my company, which has its challenges. If you can, I recommend trying to at least bring in another engineer to share the load! It can get overwhelming quickly with just one person trying to handle everything.
Preach! It’s tough doing all that solo. Don’t be afraid to advocate for help.
Your setup sounds quite reasonable for a modern tech stack. However, I think you’ll need to expand your team as you take on more tasks. I work with a larger crew – around 15 infrastructure folks supporting 100 developers, and it's still demanding. But keeping the teams specialized helps a lot!
Variance in team size often leads to complexity. Having clear roles can simplify maintenance.
Definitely! Having a platform community where developers can help each other out has been a lifesaver for us.
Honestly, I think Helm is overrated as a platform tool. I’d be cautious about relying too heavily on it since it can lead to messy situations where developers circumvent your setup. You might want to look into more controlled deployment processes like GitOps for production environments.
Couldn’t agree more! Standardizing processes makes things easier in the long run.
And using Operators could simplify your deployment strategy while avoiding Helm's pitfalls.
We’ve got a slightly different structure: our infrastructure team handles the core resources while the platform team manages middleware services and application configuration. That division really helps streamline responsibilities and makes it easier to scale up.
Right? Specializing in different layers can allow for better efficiency.
Exactly! Having a team strictly for configuration means cleaner deployments and better control.
That sounds pretty normal, but it's a tough balance. I mean, having a small team that takes on all the responsibilities can lead to burnout, especially if you’re supporting a large number of developers. I've been on a team like that, and we had between 3 to 5 engineers at a time, and it was a challenge.
Yeah, keeping a manageable workload is key. If your team is handling that many devs, make sure you communicate clearly what can realistically be managed.
Exactly! Setting boundaries is crucial. Plus, getting more engineers on board could really help if demand increases.
Been there! Even a small support team can make a world of difference.