Devs don’t want to do ops
Devs don’t want to do ops
Developers are straining under the demands of ‘You build it, you run it,’ and operators are feeling more pressure too. Is it time for development and operations to be separated once again?
TLDR provided by ChatGPT:
As software development grows more complex, the devops approach, which merges software development and IT operations roles, is under scrutiny. Although devops has sped up updates and tightened feedback loops, it's often overburdening individuals by blurring developer and operator roles. Developers have voiced reluctance to handle operations, citing the specialized skills needed. The potential solutions include realigning responsibilities to empower developers with timely information, using container orchestration technologies like Kubernetes to separate developer and operator concerns, and expanding the roles of Site Reliability Engineering (SRE) and platform engineering. The future of software development may require a blend of devops, SRE, and platform engineering to effectively address the growing complexity.
IT operators and DevOps engineers have been a nightmare liability for security, governance and business continuity. The best-case scenario for a DevOps/IT operator is that you get a superhero that does everything and knows it all. All responsibilities and security privileges gravitate towards this role, and knowledge sharing becomes impossible. Lastly, it becomes impossible to track the thousands of out-of-band changes initiated by a DevOps team to an auditor or certifier.
Cloud engineering, feature management and IAC tools have made it way better for engineers to build and deploy self-monitoring systems. A modern software ecosystem can be deployed, updated and migrated on an automated schedule. It can be done, safely without any of the responsible engineers having direct access to environment secrets or sensitive data. All of these changes can be set under version control for auditing purposes. If given the option, any smart employer would prefer the option to invest in such a system rather than support a 24-7 response team.
There will always be a need for surgery on a production environment, but there's no reason that can't be a formalised incident. If you are having weekly incidents that require engineers to do operations work, then that's something that needs to be addressed.
We should all be working to eliminate operations work. IT operator needs to be a trusted security role, not a critical glue with all the keys that holds a system together.
I’m a dev manager in the exact opposite position - I don’t want to move away from devops activities, but rather own them all up. I want complete control over the pipelines. I want as close to 100% unit test, code coverage and integration tests as possible. I want to fully automate deployment (and rollback, if hell breaks loose). Clearly, I want to work with my devops team to ensure near perfect uptime, round-the-clock monitoring, etc. - but definitely not pushing it to someone else or another team. Even better if I have devops members that report to me.
The alternative of begging for change requests that never happens is 100x worse imo
I am really confused by what I'm reading here. This is exactly it. If you have a specific DevOps role or team plus developers... Congratulations you have Operations again. Developers should empowered to fuck (their) shit up and fix it, that means having mandate, tooling and responsibilities for running things in production. And auditing and compliance is definitely possible all while doing do.
Was DevOps about shifting the responsibility to developers? I thought DevOps is more about automation which is a good thing
The DevOps I do is definitely empowering me. I would hate to have a separate admin I have to request stuff from and depend on.
From the article:
“Where it doesn’t work well is by asking developers to do all of that work without centralized expertise and tooling support.”
IMO, developers should be given enough enough to get themselves in trouble. However there's a team that owns and enables those processes.
I've always thought of it like a team who owns an API. That API team owns the api, but if another team wants to use said API, cool, here's some documentation for it (env configs, OAuth2.0 onboarding, distrolist, future features, etc.). Maybe, depending on the company, there's a little more "ceremony" around how much the new team will be using the API just from a load perspective. But overall a team is allowed to digest the API with some guidance.
IMO, this is what should be happening with DevOps/DevSecOps/Operations. They enable the developers to follow some general cookie cutter guidelines with the ability to request adjustments. However, the permutations in what a person can do in operations are so much higher than just a well defined API service.
In my own career, I've found that "ace in my back pocket" is being able to handle a lot of my team's DevOps and general automation of tasks. But when I've coached and mentored folks usually there's a somewhat clear split between the developers who are interested in learning DevOps and those who just want to stay feature-devs.
My target environment is small and specific enough. I value having control and opportunity greatly. I would hate to have barriers to deployment, analysis, changes.
If it exceeds the complexity or workload of where it makes sense, it probably makes more sense as a team collaboration rather than separating devs from ops "again".