4 ms·

What i find interesting about how Google/AWS/Netflix are setup is their interesting line between ops and devops. Development teams are expected to run their own

What i find interesting about how Google/AWS/Netflix are setup is their interesting line between ops and devops. Development teams are expected to run their own services - but after a while. SREs are there to help make the transition. They are the ops experts. I think for smaller shops and startups, there is an important lesson - don't throw out ops! Your in-house ops people are Google's SREs. Most devs I work with could not run services in production without significant help. Google, etc, have great structures in place to handle this. Smaller shopps should take care.

baus 11y ago
I don't think the trend toward having devs handle all the ops is a good idea. Ops teams, for good reason, tend to be way more conservative than devs. Plus I don't think it is effective to constantly interrupt dev teams with operational issues.
- jamesblonde 11y ago
  Agreed, but there is definitely a trend towards pushing devs to think more about ops. We internally use chef/kitchen and get devs to run their code on kitchen unit tests before it can be considered ready for a PR. Previously, we only did unit tests, and it's a great improvement. But, yes, the bar is much higher from that to actually running in production.
- djb_hackernews 11y ago
  They are conservative because of the ops/dev divide. The constant interruption is a sign of bad ops/dev communication. Unified, the devops have confidence in what they are deploying and actively work to minimize interruptions via automation.
- mentat 11y ago
  Interrupting them is what pushes them to push quality code not just throw it over to ops and hope for the best. It works quite well with deployment velocities that would shock even normal devops shops.
rohitnair 11y ago
In AWS, if anything, it's the other way around. Devs always run their own services at first, and ops teams start helping out once the service reaches some kind of scale where a dedicated ops team makes sense. (source: I work for AWS)

baus 11y ago

I don't think the trend toward having devs handle all the ops is a good idea. Ops teams, for good reason, tend to be way more conservative than devs. Plus I don't think it is effective to constantly interrupt dev teams with operational issues.

jamesblonde 11y ago
Agreed, but there is definitely a trend towards pushing devs to think more about ops. We internally use chef/kitchen and get devs to run their code on kitchen unit tests before it can be considered ready for a PR. Previously, we only did unit tests, and it's a great improvement. But, yes, the bar is much higher from that to actually running in production.
djb_hackernews 11y ago
They are conservative because of the ops/dev divide. The constant interruption is a sign of bad ops/dev communication. Unified, the devops have confidence in what they are deploying and actively work to minimize interruptions via automation.
mentat 11y ago
Interrupting them is what pushes them to push quality code not just throw it over to ops and hope for the best. It works quite well with deployment velocities that would shock even normal devops shops.

rohitnair 11y ago

In AWS, if anything, it's the other way around. Devs always run their own services at first, and ops teams start helping out once the service reaches some kind of scale where a dedicated ops team makes sense. (source: I work for AWS)