> I'd still classify what they're doing as DevOps type of work.
This is very, very wrong. Why do you think that?
This is very, very wrong. Why do you think that?
The OP wrote:
> As an SE, I'm exposed to everything. Customers running Kubernetes, ECS, Lambda, bare metal, air-gapped environments. AWS, Azure, GCP, hybrid setups. CI/CD in Jenkins, GitHub Actions, GitLab, CircleCI. I have to understand their environment well enough to actually help them, so the learning is constant. The stagnation I felt in DevOps? Gone.
These are all things I deal with in my day to day as well in a DevOps / Infrastructure / Platform type of role. I mean, not literally everything like air-gapped environments since the companies I work for don't have that but it's all things in that category of line of work.
The only difference is I usually don't interface directly with the company's customers of the services being built. It's more like the company's staff are my customers because I'm working with developers, management and sometimes other parts of the business on ways to help optimize their workflows which all funnel back to helping create a better end customer experience.
The problem you’re suffering from is assuming that the limited range of situations you’re familiar with is the same as what everyone else is doing.
In the past 8 years I’ve led the architecture of a startup - cloud + app dev. Then spent almost 4 years working at AWS ProServe involved with large cloud + app dev “cloud application modernization” projects and now 2 years doing the same as a staff level consultant at a 3rd party consulting firm. I think I’ve seen my fair share of how large private companies, startups, government organizations and colleges work.
A lot of my projects pre AI involved bringing modern DevOps practices to an organization - convincing operations to use IAC and best practices and have them more embedded into the dev teams.
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.
If you are just throwing things over the fence - you’re an “operations” team and get none of the benefits of DevOps
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.
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.
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