sysadmins liked to make sure said computers worked smoothly.
I mention this because this pattern has not changed. Not one bit. Let’s move on.
Ops teams didn’t know in detail what they were releasing, so couldn’t fix things if they went wrong. The best they could do was restart things and hope they worked.
I mention this because this pattern has not changed. Not one bit. Let’s move on.
The solution was clearly to get rid of the separation: no more silos!
The development team didn’t want to – or couldn’t – do the Ops work
The exceptions I’ve seen in the wild implemented a purer form of DevOps when there existed:
Strong management support and drive to enable
So across the industry, those that might have been branded sysadmins first rebranded themselves as Ops, then as DevOps, and finally SREs. Meanwhile they’re mostly the same people doing similar work.
‘cloud native centres of excellence’ (who just ‘advise’ on how to use new technologies), or ‘federated devops teams’ (where engineers are seconded to teams to spread knowledge and experience) come from.
Note: Should be a good complement of treating your platform team as a product team.
Anyone who knows anything about political or organisational history knows that these plans to self-destruct often don’t pan out that way, and you’re either stuck with them forever, or some put-upon central team gets given responsibility for the code in perpetuity.
One of the most common complaints about centralised teams is that they fail to deliver what teams actually need, or do so in a way that they can’t easily consume.
This factor can be mitigated with good management. I’ve seen great benefits from moving people around the business so they can see the constraints other people work under (a common principle in the DevOps movement) rather than just complain about their work.