> 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.
If you are a “DevOps engineer” - how is what you are doing any different from operations folk 25 years ago if you aren’t working with developers and embedded into their teams?
Rule #1 is never make assumptions about anyone on the internet…
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.
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.
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
This is very, very wrong. Why do you think that?