The problem with DevOps is not really how it is practiced, but how it is named. DevOps is a bucket that a bunch of things are thrown into, and everybody thinks the thing they threw in is DevOps with the others being mislabelled.
Is having a DevOps team wrong? No, having automation experts, infrastructure experts, integration experts, etc. all makes perfect sense. Bundling all those disciplines under a single term is what is wrong.
Is aiming to do "less DevOps" using "serverless" wrong? No, aiming to reduce infrastructure maintenance and design overhead is perfectly sane. Interpreting that as entirely avoiding infrastructure, or as affecting any of the other disciplines is what is wrong.
What we need is better work descriptions and team organizations. But while the buzzword DevOps is bad, it's not so bad to have a fancy term that executive management understands and can put some money behind - money that allows you to spend time or buy solutions to solve your actual process problems are.
"DevOps" was never originally a team or job role, it was just a workplace culture philosophy that dev and ops should work closely together rather than in isolated, and often mutually hostile silos as was common in the 90s.
It just became a buzzword that everyone had to have, then C-level leadership needed "invest in DevOps", "grow the DevOps team" (because buying is easier than fixing the culture) until we lost sight of the original point and DevOps just became... ops.
I’ve always considered DevOps to be Developer/Operator - as in - you run the stuff you build. This perfectly aligns incentives for creating stable, scalable systems. If it goes down or breaks, the ones who wrote it are the ones who feel the pain.
My last job was the first place I saw DevOps as developers working along side operators as DevOps, which was a slight improvement over when they didn’t work together, but seems unnecessarily disjoint. Unfortunately, they had compliance requirements that forced developers and operators to be separate humans with separate access. Not wanting to get back into that world, I’ve not looked at how strict those requirements are or if there are ways around it (HIPPA, FIPS, etc.), but it was an annoying distinction.
> I’ve always considered DevOps to be Developer/Operator - as in - you run the stuff you build
This is also exactly how i've always understood the term, and it makes perfect sense.
But the origin of the term is indeed in distinct dev and ops people working more closely together. The origin story is basically Patrick Debois watching this talk, and then turning the title into a noun:
The problem is that lots of developers who have no interest in operations, and even most who do aren't that good at it. I've worked with perfectly capable developers who didn't really know what an IP address was beyond "numbers with some dots in them".
Personally I view platform engineering (or SRE) as the best endpoint of the ops role and devops philosophy. A good platform engineer is a developer that knows OSes, networking and databases and can expose abstractions that meet the requirements of application developers, akin to how a good application developer knows their the business domain and can expose an interface that meets the requirements of users. Nowadays, the platform engineering is often done by AWS or Google and that's sufficient for many developers and smaller organisations, but many orgs will probably still need some people of various skillsets between what is exposed by the cloud and the business requirements.
I mainly think traditional ops is just a dead end. If something happens often enough that you feel like you need to develop a runbook and hire someone to follow it, you should just be automating the fix or fixing the underlying problem. DevOps in the sense of applying a development philosophy to ops (i.e. automation and version control rather than paper runbooks) and applying an ops philosophy to development (i.e. writing stable systems that are robust in the event of failures) is still a valuable philosophy, but the word itself is meaningless now.
Back when I hunted willy mammoths, "DevOps" meant that there was no "dev" and "ops"; developers did ops, to avoid the friction of throwing code over the wall. Essentially it meant more "vertical" "full stack" teams, instead of horizontal layers. You knew how to write and run your system, and probably has a narrower scope of product than someone who was dev for more features or who was ops for more apps.
That’s how I thought about it (and lived) as well. Developers knew how to configure operating systems and databases, deploy them, etc. Everything but racking their own hardware. And sometimes even that.
Interesting. When I started I was told the idea is you apply operations principals to your developer workflows, i.e. your developers making code is as important as getting their code to production.
Yep. At work, I'm being a bit picky about the wording, but it's shifting people into a better direction. We don't have DevOps people. We have a fairly modern operations team, we have more or less modern developers and tasks or projects follow a DevOps-mindset.
Like, if your DBA is attending plannings of teams working on a database heavy project. That is an action following a devops-mindset - breaking up siloed knowledge at the right places in a good way in order to save time on both sides. Weeks of planned work can disappear with the words "Oh there's a postgres extension for this. Give me a week to check it out."
Or, if we work on some system so a consultant managing a customers system can roll versions forwards and backwards automatically with a simple UI. Again, something following the devops-spirit of removing yourself from the loop, putting trust into the automation and enabling people to work with less friction. But again, this isn't done by a "DevOps engineer", it would usually be done by one of our operational dudes with a focus on automation and pipelines in close cooperation with the dev-team.
It may be picky and pedantic, but it steers thoughts into a better place. And it gives us an answer to "What the hell is ops doing all day?" Making your devs better, and you money, good sir.
Interesting point and one that I feel applies equally to Product Manager, another catch all title that has a ton of stuff thrown in.
IMO there are 3 distinct roles that product gets thrown into, 4 really but the technical product manager is completely different.
Research/data, operations and UI/UX and then the 4th being the technical product manager.
The person that maps and sets up the metrics, KPIs, product intelligence and knowing the business model is very different from the person that knows the UX flow and can inform the UI.
The problem IMO lies in the middle management layer, maybe ai will be able crack that but for us ;)
It seems to be a problem all over many disciplines tbh
As someone who has managed teams (including devops teams, while not being a dev myself) for 26+ years...
What we need is LESS HR.
And what youre saying is what we just refer to as an SME (Subject Matter Expert [SUBJECT])
Its stupid to worry about labels. But if youre an SME on the sites DBs, or Network, or scaling factors etc... your the SME for [SUBJECT] and you can still be an SRE, Dev, Ops, Network guy and still be on the Devops team/ops team/ IT team.
I've been an automation engineer on small dev teams (5-15 devs) and felt like I had tremendous impact. There were a few larger integrations I was generally hired for and then got to tackle pain points I had seen and heard about within the dev team and on the business side. Not to mention being able to refine CI/CD and take that off developers hands.
I've been at a large organization for a while now and my backlog is mostly planned out quarters ahead and I don't feel like I have nearly the same impact.
With 15 people and 7.5 hour work days, saving each person just 30 minutes a day is cost equivalent to a permanent full time role. At 30 people, you need to save just 15 minutes. At 90 people, 5 minutes.
And that is without considering that a full time role would keep doing more work than that singular time saving, or the decreased operational cost from failures in manual process execution.
Just because the jobs seem menial to you does not exclude it from bringing great value to an employer.
(Above numbers are subject to crude linear extrapolation, but are sufficient to make the point.)
Is having a DevOps team wrong? No, having automation experts, infrastructure experts, integration experts, etc. all makes perfect sense. Bundling all those disciplines under a single term is what is wrong.
Is aiming to do "less DevOps" using "serverless" wrong? No, aiming to reduce infrastructure maintenance and design overhead is perfectly sane. Interpreting that as entirely avoiding infrastructure, or as affecting any of the other disciplines is what is wrong.
What we need is better work descriptions and team organizations. But while the buzzword DevOps is bad, it's not so bad to have a fancy term that executive management understands and can put some money behind - money that allows you to spend time or buy solutions to solve your actual process problems are.