Help me understand this 'embedded in developer teams' in a larger company. Do you have no central infrastructure with centralized tooling, alerting, standards and knowledge?
Team A has a devops engineer, Teams B through F have one, how do they have any capacity to pursue long term strategical projects, save money and operational effort with centralized hosting and tooling, and basically have some autonomy, when they are enslaved to a Scrum Master and some hokey pokey Fibonacci numbers and T Shirt Size nonsense having to argue priorities in every Sprint against people who don't care about operations?
That's what embedded devops is to me - an operational role enslaved to dev leads, the poor guy who has to troubleshoot a failed release while the devs are at the bar.
Unless my straw man is wildly off, no thanks to that embedded stuff.
That’s exactly what it means , a person who reports to the infrastructure team who decides standards and is embedded with the devs as part of the project.
If you are just throwing things over the fence - you’re an “operations” team and get none of the benefits of DevOps
Understood, but so far what I observed is the embedded devops pressured/saying Yes/beholden to a PM running sprints, and the central infra team management constantly has to intervene to protect the embedded devops engineer politically.
Maybe my experience is a rare example, but my conclusion so far is that it's tricky to prevent this painful situation, and requires vigilance.
And once you have the infra team saying no all of the time and being antagonistic - you’re back to old school operations and you aren’t a DevOps shop.
But if they never say no, how do you maintain central infrastructure standards?
If you say yes all the time, I feel like that's how you turn devops into Ops monkeys who are reactive, since people are operating on Sprint timelines instead of optimizing for long-term stability.
Looking through the AWS lens because that’s the one I know.
The goal of the centralized ops team is to put just enough guardrails on the Organization (a group of AWS accounts) to keep the company in compliance - no public access S3 buckets, no one has organization::* permissions, set budget limits per account or organizational units etc, establish budget thresholds (or in the case of Isengard - AWS’s account vending machine - you can do almost anything except spin up an Oracle DB) . Let each team be responsible for their own deployments, monitoring, etc. For the most part, the top level operations department should be responsible for the Organization, setting up service control policies, Security monitoring and then the embedded DevOps person should be an SME not the department of “no”.
If you make the dev team a long with the embedded ops person responsible for their account/monitoring and they get called once a twice, they will figure it out