4 ms·

I think nowadays requiring that all application developers should also do ops (DevOps?) is a bad idea. Sure they should have basic shell skills, but when you’re

I think nowadays requiring that all application developers should also do ops (DevOps?) is a bad idea. Sure they should have basic shell skills, but when you’re on Kubernetes or similar, understanding what’s underneath is not vital. Instead, rely on specialized teams that actually want to know this stuff, and become the experts you escalate to only when things really go sideways and the abstractions fail (which is rare if you do it well). If your budget is too small for this, there are always support contracts. As someone who’s been hiring for both sides, I see this reflected in candidates more and more. The good devs rarely know ops, and the good ops rarely code well. For our “platform” teams, we end up just hiring good devs and teaching them ops. I think the people that are really good at both often end up working at the actual cloud providers or DevOps startups.

blinkingled 4y ago
But then there's the problem that now you have two teams - ops team doesn't understand the app and app team doesn't understand the ops/infra side. I of course agree with your point that there should be two teams but you need a few guys who understand both app dev and ops/infra/OSes/k8s internals etc. And finding these people has been nearly impossible.
- MaKey 4y ago
  I am one of those rare people :) Coming from the Linux sysadmin and networking side I'm currently working on going deeper into programming and expanding my knowledge there. In Europe the pay for someone like me appears to be capped at slightly above six figures though, which I will reach soon, so I'm currently a bit unsure on how to progress career wise.
- jethro_tell 4y ago
  You can just add an ops guy with minimal coding to a dev team and it works wonders. Ops guy does the ops stuff, writes the shell scrips and consults with the devs on how to build what they need to build. The ops guy has an opportunity to level up his coding since the devs are doing code reviews for him and devs have an opportunity level up their ops knowledge because they are working with someone who understands what hand how platform should be built.
  - wernerb 4y ago
    I think it's great to "bring" knowledge to devs in this model. But not commit to individual wishes for features and implement them willy illy. The "ops guy" needs a team too, preferably to build a company shared platform that suits the large majority. This only goes of course when you either hit scale or are a large company. When smaller it's perfectly fine to unload unwanted things to one or two people. I do very strongly believe in "you build it you run it". Keeping servers up is different than keeping your application up. I think a dev should know what health checks/probes are, what a good period time they need for their application. It's the "ops guy"'s job to make the dev guys job as easy as possible and bring expertise and knowledge when needed

blinkingled 4y ago

But then there's the problem that now you have two teams - ops team doesn't understand the app and app team doesn't understand the ops/infra side. I of course agree with your point that there should be two teams but you need a few guys who understand both app dev and ops/infra/OSes/k8s internals etc. And finding these people has been nearly impossible.

MaKey 4y ago
I am one of those rare people :) Coming from the Linux sysadmin and networking side I'm currently working on going deeper into programming and expanding my knowledge there. In Europe the pay for someone like me appears to be capped at slightly above six figures though, which I will reach soon, so I'm currently a bit unsure on how to progress career wise.
jethro_tell 4y ago
You can just add an ops guy with minimal coding to a dev team and it works wonders. Ops guy does the ops stuff, writes the shell scrips and consults with the devs on how to build what they need to build. The ops guy has an opportunity to level up his coding since the devs are doing code reviews for him and devs have an opportunity level up their ops knowledge because they are working with someone who understands what hand how platform should be built.
- wernerb 4y ago
  I think it's great to "bring" knowledge to devs in this model. But not commit to individual wishes for features and implement them willy illy. The "ops guy" needs a team too, preferably to build a company shared platform that suits the large majority. This only goes of course when you either hit scale or are a large company. When smaller it's perfectly fine to unload unwanted things to one or two people. I do very strongly believe in "you build it you run it". Keeping servers up is different than keeping your application up. I think a dev should know what health checks/probes are, what a good period time they need for their application. It's the "ops guy"'s job to make the dev guys job as easy as possible and bring expertise and knowledge when needed