5 ms·

I disagree, i move in different circles from the author. In my little world DevOps is often more dev-heavy (and needs to mature it’s ops credentials), SRE has b

I disagree, i move in different circles from the author. In my little world DevOps is often more dev-heavy (and needs to mature it’s ops credentials), SRE has become the new-age Ops. DevOps is primarily tackling a people problem, there’s certainly plenty of useful tools to help but at its core, it’s about people. Encouraging people to work in frequent small increments (think XP) rather than quarterly releases. Getting rid of the change management beauraucracy, encouraging developers to consider security as they’re designing and writing software. DevOps is a broad church, it’s effective too. People like to over-focus on the tools of DevOps but I’d take today’s world of version controlled (vs. “Ohh Brad has the config GUI code on his desktop, speak to him about making a change“), automated CI pipeline (vs. builds at the end of the quarter that require stop-the-world help and assistance from all developers, also RIP merge guy), automated deployment into many environments (vs. Excel list of tasks for QA team and different excel list of tasks for prod ops). I’ll take SOA over the-DB-is-the-network 00’s enterprise software architecture, oh and with automated DB deployment (albeit still without a real solution to automating stateful db rollback even today). These are all DevOps factors, from architecture to testing, from security to working and growing together as a team. The tool-only view of DevOps is just yet another excuse to ignore the hard problem: helping large numbers of people work productively together.

bovermyer 4y ago
It appears that you and the author both agree on the core definition of "DevOps" as a term. Mr. Briggs' article has two main points: * convincing developers to do operations is too hard, and * what they actually need is another type of engineer to build and manage an operational platform for them With regards to the second point, that already exists: platform engineering. The first point is messier. I disagree with the point, but it also misses the point. Like you say, the real goal is to help large numbers of people work productively together. That's a nebulous goal, though, and difficult to guide people towards. I think that's why people are confused and frustrated by "DevOps" even this long after its conception. It's also why people will continue to be confused and frustrated by it long after the term itself has gone away.

bovermyer 4y ago

It appears that you and the author both agree on the core definition of "DevOps" as a term. Mr. Briggs' article has two main points: * convincing developers to do operations is too hard, and * what they actually need is another type of engineer to build and manage an operational platform for them With regards to the second point, that already exists: platform engineering. The first point is messier. I disagree with the point, but it also misses the point. Like you say, the real goal is to help large numbers of people work productively together. That's a nebulous goal, though, and difficult to guide people towards. I think that's why people are confused and frustrated by "DevOps" even this long after its conception. It's also why people will continue to be confused and frustrated by it long after the term itself has gone away.