Right at the beginning he pointed out: nobody is a “DevOp”, it’s a cultural change in how people cooperate, not a new role.
I think he was talking about managing a cloud, not being a customer of one. But I also think it doesn’t change the meaning too much.
He also makes a good point to read books about business operations management from other industries, like automobile industry or aircraft. They’ve solved many organisational questions long time ago.
All you developers always thought you were so clever... DevOps are just becoming Developers now anyway... You tried to pigeon-hole and block us from high-level coding, treating us just like standard ops personnel... But Ironically, Security, Automation & Templatization were our best pals... we are now just evolving into broader spectrum / full stack e2e developers with AI. Often it was the devs who were creating the division, as irony has it - you created these dividing lines in the first place; we just adapted to it. Pretty soon, now - we will be able to Automate AI to the point where, maybe you won't even be required either... Are you happy now? Aha...
I don't view it as a problem or a failure. I view it as the logical conclusion of what happens when very large spheres of knowledge and skill have to be divided because they are each too large for a single role/team. The scopes of Development and DevOps are too large for any single team or person to manage at the same time while doing both right. Managing, deploying, configuring, coding and automating deployments and infrastructure is a full-time job. It leaves little room and headspace for development. Likewise, all the stages of development really leave no room to fit in complex infrastructure design and development. Also most developers don't want to manage infrastructure, and most DevOps folks don't want to do development all the time. So I think what has happened is that we found that the idea of developers doing both software development and infrastructure management is good in theory, but it isn't practical.
It's sort of similar to the idea of having brain surgeons doing both brain surgery and nursing duties. Seems like a good idea, but it isn't practical. There needs to be two different roles. Development and DevOps/Operations are both needed as dedicated entities to support each other.
One good thing that has come out of the DevOps movement is a true engineering approach to operations, as opposed to a lot of the push-button ops that was so prevalent before.
I considered DevOps a disaster since I first read about it. I said so in a reply to an article about DevOps from the owner of DevOps.com. He invited me to describe why, and my reply is still somewhere on that site. Basically, the guy was a programming God. He had written a number of books on it and directed Fortune 50 companies. I'm very good, but I've met better and he was beyond them. You need to be that level to really do Devops good.
In reading about the problem of DevOps, I found euphemisms... "requires to much cognitive capital" or evasion. One CTO pointed out that the developers didn't like it because they never stayed on one task long enough to be comfortable. That's what I hated. I was getting killed by Dev in a Lambda, three git pipelines, 3 AWS environments while trying to lead a team wearing an Agile strait jacket where leads aren't allowed, let alone design. I had made the same functionality for 15 different business units over a period of 8 years and yet went we went to Agile, DevOps, Design, Build, Run, AWS in a one week period, we basically failed.
nurses and surgeons actively work together, like a curling team. The value-add work is done together.
I think there is some truth that operations and development are two vast bodies of knowledge.
Ideally, being engineers on both sides, they would this knowledge challenge into account and operate like a curling team, instead of 4-by-silos (where product work has already been done without context of the system it runs in and that same work is handed off to new each silo without any context)
knowledge workers, if this is indeed what we are, is for disseminating knowledge, not hoarding
what may be the real driver of devops failing, besides legions of consultants giving it the scrum treatment and packaging it up to buy-off-the-shelf via starts, is status quo.
not sure how much really changed outside of new technology (that everyone can get) creating local optimizations
You got that right. They think they are gods and so hold they keys to it all, at least where I have worked anyway. What's funny is when they don't know what they are doing but pretend to, and have the meeting of the gods. You don't need that many of them, but I must admit, a lot of the stuff they do is mind numbing, so you need some.
> We should have just said: “Hey, developers should deploy their own code.” More than that—they should also be responsible for keeping it running. They should monitor it, respond to issues, and use their programming skills to automate deployments so they’re safe, repeatable, and easy for the team to use. Production-minded developers (who are part of the team!) should do a little extra work to make things better for everyone. This was the correct mindset…
Isn’t that asking way too much from developers? It sounds almost like if developers also made coffee for everybody and fixed marketing strategy — that would be an even better mindset.
It’s hard to mentally shift between an intellectually demanding task of product & tools development to a completely different intellectually demanding task of handling random operations problems and maintaining the processes.
Yeah, I guess cloud makes it easier. But it still may be unrealistic to dump everything on the same team of people.
This is an organizational issue, not an industry one. If your "DevOps" team is making it impossible to do DevOps in the name of SOC2 they aren't doing their job.
This is a fixable problem, it's hard work but it's doable.
One of the failures with "DevOps" is to have the kind of GUI/Workflow tools that make the creation and debugging of deployment as efficient for the developer as developing the software itself.
Instead, we have cryptic YAML (and other format) files, hand-generated, that harken back to 1980s programming.
Vendors (like Microsoft, Amazon, Google, etc.) need to improve the deployment process with tools at least as good as the software development tools used to create the software. That would put a lot of deployment use cases back in the hands of developers who would no longer see "DevOps" as a boring, dead-end, assignment. The deployment app would account for the multiple deployment environments (dev, QA, staging, blue/green, training, production, etc.) and the variances between those environments.
Like the testing apps that good developers include with their main project, the deliverable by the software engineers would become threefold - the app itself, the testing app, and a deployment app.
Ah! It’s exactly what Ben Rockwood warned about in this 12 years old presentation: https://youtu.be/h5E--QSBVBY?si=Lelgrc0uGEHkAclO
Right at the beginning he pointed out: nobody is a “DevOp”, it’s a cultural change in how people cooperate, not a new role.
I think he was talking about managing a cloud, not being a customer of one. But I also think it doesn’t change the meaning too much.
He also makes a good point to read books about business operations management from other industries, like automobile industry or aircraft. They’ve solved many organisational questions long time ago.
All you developers always thought you were so clever... DevOps are just becoming Developers now anyway... You tried to pigeon-hole and block us from high-level coding, treating us just like standard ops personnel... But Ironically, Security, Automation & Templatization were our best pals... we are now just evolving into broader spectrum / full stack e2e developers with AI. Often it was the devs who were creating the division, as irony has it - you created these dividing lines in the first place; we just adapted to it. Pretty soon, now - we will be able to Automate AI to the point where, maybe you won't even be required either... Are you happy now? Aha...
division is setup by traditional management structures going back hundreds of years.
"you do job a, you do job b, don't you dare f'n talk to each other and keep this line moving.."
devops had a lot of potential as a grassroots movement, in spite of management, to make lives easier period by breaking down silos.
I don't view it as a problem or a failure. I view it as the logical conclusion of what happens when very large spheres of knowledge and skill have to be divided because they are each too large for a single role/team. The scopes of Development and DevOps are too large for any single team or person to manage at the same time while doing both right. Managing, deploying, configuring, coding and automating deployments and infrastructure is a full-time job. It leaves little room and headspace for development. Likewise, all the stages of development really leave no room to fit in complex infrastructure design and development. Also most developers don't want to manage infrastructure, and most DevOps folks don't want to do development all the time. So I think what has happened is that we found that the idea of developers doing both software development and infrastructure management is good in theory, but it isn't practical.
It's sort of similar to the idea of having brain surgeons doing both brain surgery and nursing duties. Seems like a good idea, but it isn't practical. There needs to be two different roles. Development and DevOps/Operations are both needed as dedicated entities to support each other.
One good thing that has come out of the DevOps movement is a true engineering approach to operations, as opposed to a lot of the push-button ops that was so prevalent before.
I considered DevOps a disaster since I first read about it. I said so in a reply to an article about DevOps from the owner of DevOps.com. He invited me to describe why, and my reply is still somewhere on that site. Basically, the guy was a programming God. He had written a number of books on it and directed Fortune 50 companies. I'm very good, but I've met better and he was beyond them. You need to be that level to really do Devops good.
In reading about the problem of DevOps, I found euphemisms... "requires to much cognitive capital" or evasion. One CTO pointed out that the developers didn't like it because they never stayed on one task long enough to be comfortable. That's what I hated. I was getting killed by Dev in a Lambda, three git pipelines, 3 AWS environments while trying to lead a team wearing an Agile strait jacket where leads aren't allowed, let alone design. I had made the same functionality for 15 different business units over a period of 8 years and yet went we went to Agile, DevOps, Design, Build, Run, AWS in a one week period, we basically failed.
nurses and surgeons actively work together, like a curling team. The value-add work is done together.
I think there is some truth that operations and development are two vast bodies of knowledge.
Ideally, being engineers on both sides, they would this knowledge challenge into account and operate like a curling team, instead of 4-by-silos (where product work has already been done without context of the system it runs in and that same work is handed off to new each silo without any context)
knowledge workers, if this is indeed what we are, is for disseminating knowledge, not hoarding
what may be the real driver of devops failing, besides legions of consultants giving it the scrum treatment and packaging it up to buy-off-the-shelf via starts, is status quo.
not sure how much really changed outside of new technology (that everyone can get) creating local optimizations
You got that right. They think they are gods and so hold they keys to it all, at least where I have worked anyway. What's funny is when they don't know what they are doing but pretend to, and have the meeting of the gods. You don't need that many of them, but I must admit, a lot of the stuff they do is mind numbing, so you need some.
I also wanted to comment on this passage:
> We should have just said: “Hey, developers should deploy their own code.” More than that—they should also be responsible for keeping it running. They should monitor it, respond to issues, and use their programming skills to automate deployments so they’re safe, repeatable, and easy for the team to use. Production-minded developers (who are part of the team!) should do a little extra work to make things better for everyone. This was the correct mindset…
Isn’t that asking way too much from developers? It sounds almost like if developers also made coffee for everybody and fixed marketing strategy — that would be an even better mindset.
It’s hard to mentally shift between an intellectually demanding task of product & tools development to a completely different intellectually demanding task of handling random operations problems and maintaining the processes.
Yeah, I guess cloud makes it easier. But it still may be unrealistic to dump everything on the same team of people.
This is an organizational issue, not an industry one. If your "DevOps" team is making it impossible to do DevOps in the name of SOC2 they aren't doing their job.
This is a fixable problem, it's hard work but it's doable.
One of the failures with "DevOps" is to have the kind of GUI/Workflow tools that make the creation and debugging of deployment as efficient for the developer as developing the software itself.
Instead, we have cryptic YAML (and other format) files, hand-generated, that harken back to 1980s programming.
Vendors (like Microsoft, Amazon, Google, etc.) need to improve the deployment process with tools at least as good as the software development tools used to create the software. That would put a lot of deployment use cases back in the hands of developers who would no longer see "DevOps" as a boring, dead-end, assignment. The deployment app would account for the multiple deployment environments (dev, QA, staging, blue/green, training, production, etc.) and the variances between those environments.
Like the testing apps that good developers include with their main project, the deliverable by the software engineers would become threefold - the app itself, the testing app, and a deployment app.