I disagree with your disagreement. There's nothing we do under the umbrella of "DevOps" that wasn't part of competent service ownership twenty years ago. I read your article and the point that stood out for me was the notion that the skills to drive tools like chef, puppet are somehow new and different. But I know better, because although I use those tools today, back in the day we used cfengine and a bunch of declaratively/injectively configured shell & perl scripts to achieve basically exactly the same effect.

Back then we called this "systems administration". But we were most definitely working with developers and running the SDLC across silos.

It's nothing new, it's just got a label.

As a relatively old guy, I always thought that DevOps was just the new name for what people have always been doing. It is literally just now that I've realised that other people think it is different :-) Possibly younger people don't understand what system administrators used to do...

"Possibly younger people don't understand what system administrators used to do..."

System Administrators used to blame developers. Developers used to blame System Administrators. Devops is in part an attempt to mediate between "silos".

Bad System Administrators used to blame developers. Bad Developers used to blame System Administrators. Real Systems Administrators attempt to mediate between "silos".

therego...

Therefore we need a new title to distinguish "Real System Administrators" from server technicians. So, we get "devops" for people who understand both.

Except in reality we get people who are bad at dev and bad at ops pretending they can do both

You get people who aren't very good in every kind of role in every kind of organization. Sturgeon's Law applies to everything, even people. If you have more than 10% of your team doing really well you're ahead of the game.

DevOps role is different because it assumes full product ownership. Typical system administrators are focused on just the infrastructure portions. In a DevOps role you are more focused on the things running on that infra, as well as the infra. It's a more encompassing role than the traditional 'sysadmin' role.

In the olden days before it became fashionable to outsource everything to "specialist" the sysadmin team often had full product ownership.

You're talking about the difference between sysadmins of the 90s and devops of today. The comment you replied to was talking about the difference between product engineering and operations engineering -- he's defending the idea that devops is a specialization of engineering as a whole. It looks to me like you're right, and the comment you replied to is right, and you seem to be agreeing.

He's not saying that chef and puppet are different because they're new; he's saying that using chef and puppet and docker all day long is a different job than debugging CSS and JavaScript or implementing REST api in scala all day long.

Right, but your parent is saying that job is not some new "DevOps" thing, it is just well functioning operations. "DevOps" is meant to evoke bi-directional buy-in and cooperation between the people working on development and the people working on operations. Re-naming the operations role "DevOps" doesn't get you that - you could still have low buy-in and poor cooperation between development and "DevOps".

I agree, and I agreed with that previous comment and the one before it. But I don't see where the comment I replied to made any reference to the name not doing what it says. I only see him saying that what we call DevOps existed before we called it that.

In any case, of course the name doesn't cause buy-in to happen, just like hiring an "Engineer" doesn't mean the person will do a good job engineering.

You're not saying that we should avoid a term meant to evoke the idea that cooperation is expected, because it might not happen, are you? I can only see rightness in trying to be clear about what's expected and naming roles to suggest positive cooperation is part of the job. If "DevOps" is meant to suggest buy-in and cooperation, you've convinced me that it's a better description than whatever it was called before.

I am saying that using the "DevOps" term for a role undermines the effectiveness of the term as a definition of culture. "I'm just a developer, I don't need to worry about this DevOps stuff, that's what we have the DevOps engineers for!"

If you have the job title "DevOps X", then you've missed the point of DevOps.

The entire thing was brought in to remove the silos between SysOps and Dev. If you have people in the "DevOps" role, then you've just created a new silo, which means you just have traditional SysOps with a new and fashionable, but less meaningful name.

Unfortunately, "Cultural Engineer" as a title has some pretty scary implications. So the DevOps Engineer is becoming a cultural engineer of the company with a better name.

Which of course is title inflation and title overloading. Now if they'd just overload the salaries, we'd be set.

I've seen this a few times in the thread and I don't get it. Nobody is saying there is a "Cultural Engineer" role, they are saying that there are operations roles and development roles, and that DevOps is not a role, but a culture where the people in both roles understand, help, and cooperate with each other.

A devops engineer should know how to apply devops to your organization before the other roles have become proficient. It's someone to ask vs. reading the Internet for things that might not apply to you.

You are conflating bad sysadmins with systems administration itself, and blaming bad cultures (typically managment driven) on the employees..

This train of thought can be dangerous - especially once your business grows to support more than a handful of customers.

Can you name a profitable organization that has successfully eliminated ops/devops? I've yet to find any example of this.

At a certain level of scale, silos can be a very beneficial thing.

I don't really care about titles so if calling someone a DevOps Engineer helps them and connects the right engineers to the right roles, great. Fighting against this use of "DevOps" would be like fighting against how the word "literally" is misused to mean "figuratively".

However for me, "DevOps" is more than just CI/CD and tech automation, it's about not working in silos and having empathy for others in the team (and the customer!). This is a culture and mindset that everyone in the team needs to have.

Because DevOps also include things like Agile, Lean, MVP, avoiding local optimisation, minimizing the amount of work in progress, and many other things. DevOps is not just about infrastructure, you need buy in and a change of mindset (compared to waterfall) from the Devs, QAs, PMs and even sales / upper management. This is really a company-wide change aka culture. So unless you are the one putting all of this in place, "DevOps engineer" doesn't really make sense. Automation engineer is what most "DevOps engineer" really are: automating as much as possible everything that touches the infra.

Completely agree. None of the current top comments even mention what DevOps actually does. I can't understand where the motivation is coming from to obscure it into some fuzzy "human" wankery.

It is actually the opposite. The whole thing started out as a movement to improve cooperation between development and operations ("fuzzy human wankery") and has been obscured to mean "an operations person who automates things", which didn't need a new name, because they already did that.

and, if you are going to bring in a person or persons to be that 'Devops specialist' and help your devops transformation, don't bother if you aren't going to empower them to facilitate real changes, or if you are going to put them in their own little silo and leave them to get on with just automating some manual stuff - that way you will have some automation that may or may not do what you want, but you won't achieve real transformation and reap the benefits thereof.

totally agree, don't see the point of the article