3 ms·

These two statements don't reconcile: > Being both a developer and an operator is already tough (but critical to build good software) > Yes, with effective au

These two statements don't reconcile: > Being both a developer and an operator is already tough (but critical to build good software) > Yes, with effective automation, monitoring, orchestration and so on, this is all possible This argues for having a separate ops team to handle the complexity centrally (e.g. operating a kubernetes cluster, providing standard building blocks), so developers can concentrate on their services.

philwelch 9y ago
You can and should have a cross-functional team (containing both devs and operators) to build and operate your infrastructure automation. But the operation of the individual services still falls on the teams that own them.
- ec109685 9y ago
  Right, but the complexity the author complains about is then not on the individual services’ developer teams.
  - cc81 9y ago
    I'm starting to like more and more that you have a "devops" team that is responsible for the application in all environments. They deploy and monitor it but also expose that monitoring to others. Then you have the platform teams that support them by managing the platforms they use, the monitoring solutions etc. and work as much as possible so the devops teams can be self service. I have no experience with it though but I feel that having all knowledge in all devops teams does not scale to any sufficiently complicated environment and the idea of the dev team not being responsible for deploying to production sucks.
  - philwelch 9y ago
    That's the point, yes?
    - ec109685 9y ago
      Right, if you have a strong team supporting orchestration (or outsource to a cloud), the need for every developer to be an operations specialist goes down, yet the team can still support a larger number of services efficiently.
dwmkerr 9y ago
I see what you mean. What I was trying to say is that regardless of whether you have combined devops or separate dev/ops, there is a lot of complexity in managing an orchestration cluster. I kind of muddied it by suggesting the devops approach is important to be building good software (which I think is actually arguable). However, I don't actually think a central team is always necessarily the best way to handle the cluster, it depends on the setup in the org and how many people are using it. In some cases it might be best to have the team who use it most heavily handle it, and share their best developers with other teams on rotation. But there's lots of options here. I agree the points are a bit unclear!

philwelch 9y ago

You can and should have a cross-functional team (containing both devs and operators) to build and operate your infrastructure automation. But the operation of the individual services still falls on the teams that own them.

ec109685 9y ago
Right, but the complexity the author complains about is then not on the individual services’ developer teams.
- cc81 9y ago
  I'm starting to like more and more that you have a "devops" team that is responsible for the application in all environments. They deploy and monitor it but also expose that monitoring to others. Then you have the platform teams that support them by managing the platforms they use, the monitoring solutions etc. and work as much as possible so the devops teams can be self service. I have no experience with it though but I feel that having all knowledge in all devops teams does not scale to any sufficiently complicated environment and the idea of the dev team not being responsible for deploying to production sucks.
- philwelch 9y ago
  That's the point, yes?
  - ec109685 9y ago
    Right, if you have a strong team supporting orchestration (or outsource to a cloud), the need for every developer to be an operations specialist goes down, yet the team can still support a larger number of services efficiently.

dwmkerr 9y ago

I see what you mean. What I was trying to say is that regardless of whether you have combined devops or separate dev/ops, there is a lot of complexity in managing an orchestration cluster. I kind of muddied it by suggesting the devops approach is important to be building good software (which I think is actually arguable). However, I don't actually think a central team is always necessarily the best way to handle the cluster, it depends on the setup in the org and how many people are using it. In some cases it might be best to have the team who use it most heavily handle it, and share their best developers with other teams on rotation. But there's lots of options here. I agree the points are a bit unclear!