It doesn’t tell me anything about what you do; and it implies that sysadmins never used to code either.
There are people pushing “devops tools” but those tools used to be called deployment or build tools. The word is pointless ambiguity.
Additionally: the “title” was coined as the name of a conference to include developers. The actual intended job title (and original conference name) was “agile systems administrator” according to the person who invented the word (Patrick Dubois).
> It doesn’t tell me anything about what you do; and it implies that sysadmins never used to code either.
Back when Luke wrote Puppet, he himself admitted that he was a mediocre developer with a good idea. His premise was that most SysAdmins weren't developers and that they would be more effective with a DSL that wrapped a templating engine and an executor then really learning how to code to build their own tools.
This set just an ugly trend. Next came Chef, which was written by someone (Adam Jacobs) who was pissed off at Luke because he felt entitled to 100% of his time. This was an incredibly dramatic exchange, Puppet Issue #1010 (I can't seem to find any of the old tickets anymore). Adam was making bank off of Puppet consulting, Luke was barely scraping by.
So Chef came along, it was supposed to bridge the gap between Puppet and developers. It was also garbage, but after a few years you could sort of kind of do real development on it.
Then we got Ansible, meh. Salt Stack which was more for managing api driven saas infrastructure but had/has a lot of the bad architectural decisions made by Puppet.
Now we have Terraform, which is OK, but also garbage. On top of that there's the Terraform CDK, which sort of lets you code, but is really just a golang-like DSL that generates HCL or Json. We also have Pulumi, which like the TFCDK, is a golang-like DSL that .. generates HCL to be run by Puppet.
All of this garbage because Luke felt that Sysadmins couldn't code.
You hit on the most important thing about DevOps: DevOps is not a job title - as any DevOps person will tell you. Obviously it _is_ a job title, but what they mean is that it isn't supposed to be one. Its supposed to be a way of looking at the SDLC to reduce friction, decrase siloing, and approach shipping and building software into production with the same SWE discipline that feature work is given.
The failure of the industry to actually grok this has resulted in the re-framing of DevOps as SRE - which is also misunderstood by 99.9% of engineers and managers - and more helpfully, in the rise of the Platform Engineering meme.
In my time as a platform engineer - or what devs call a 'DevOps Engineer' - which has never been my job title thankfully - I've found that people either think "DevOps" are wizards or drooling idiots. At the same time, however, many devs are unwilling or unable to consider the complexities of productionizing an application before those complexities cause delays. The point of DevOps was to catalyse cultural change, not to build a new silo for people to misunderstand and ignore.
In some companies, DevOps mean: developers do everything poorly, including ops. No dedicated Ops or security teams in company or applicable training for developers.
In others companies it means separate siloed DevOps teams and people, You need to raise request to do anything on your servers. Sometimes deployment mean getting DevOps team approval in process.
I also dislike DevOps terms because it is not specific enough on how you should organize Dev and Ops concerns.
"it implies that sysadmins never used to code either"
It does, but to be honest, when I studied computer science "not coding" was a big deal.
There were many people who simply didn't like to do it for whatever reason, and those weren't "theory people". There were meetups on how to structure your studies so you would get your degree with at least code to write as possible, and most of those people focused on getting jobs in operations later.
For some of them DevOps was cool, because it finally allowed them to learn to code in an area they were interested in, but for others it meant their low-code jobs transformed to developer jobs over time, which they didn't like at all.
Unfortunately here in Germany the majority of “devops” is just a bunch of operations people who maintain terraform and ansible markup, no real dev involved.
DevSecOps seems to just be plugging sonarqube into ci pipelines and installing siem/wafs.
It is, but it's difficult to introduce. Just hiring 'devops' people for your ops team, or giving developers access to AWS is missing the whole damn point. It requires reorganizing work in a way that makes a lot of people angry, as they now have to do things that so far they've just tossed over the wall to another team and then complained loudly when that didn't work.
You have to convince developers that they're responsible for making software easy to deploy and debug, and get them to carry pagers during work hours. You have to convince them to make the product internals clear for everyone, including to operations people, and get them to do knowledge exchange with them. You have to enable them by providing insight into production deployments and providing a platform that unifies production/development as much as possible without tons of boilerplate required per project (common database interfaces, common logging interfaces, common CI, common release procedures, common development environment).
You have to convince operations teams to write programs in something other than bash, and to generally follow good software engineering practices, to write operations-level code that is as testable as the application itself. You have to enable them by giving them the means to build a company-wide production platform where complexity is decimated by moving every product team onto the simplest possible setup. You have to let them build bespoke tooling and accept that these lines of code are as important as the application code itself.
With all of this implemented well, the differences between ops and dev roles will begin to blur, people with different backgrounds will mingle within and across teams, and you will end up with a more platform/product split between teams rather than a development/operations split.
My last couple devops roles were somewhat this, involving mostly infra-type stuff. It's really a catch-all term for someone who keeps the "10000 foot view" of the product so the "real" devs can focus on their own little cog in the wheel. I usually absorbed all of the testing automation, centralized logging/metrics, "IT" (directory/ldap, backups), sane security and networking etc etc and ensured their was a coherent story soup-to-nuts. Wrote a lot of python/glue and "business"-oriented infrastructure management tools along the way. Had to be the point person for anything in the aws console, from dbs to vpns to docker containers to cdns etc etc and dealt with integrations to other saas/products as well
It's the opposite where I work. We are "DevOps Engineers" but we spend most of our time writing Java and we get by using Kubernetes, Docker and Ansible but I always feel like we are scratching the surface a bit.
All the *Ops words are just attempts by people to name things. None of these attempts are particularly helpful, except perhaps as conversation starters.
I am not a "DevOps" engineer. I am a digital platform engineer, with specialization in writing code to connect things to other things.
When I talk to people outside of tech, I just tell them I'm a software engineer. It's close enough.
GitOps is a deployment methodology. Sure its a buzzword, but product devs have plenty of those as well.
I _do_ agree that DevSecOps is a pointless concept - as is FinOps and other xOps crap - its become a way to throw work over the wall, which is what DevOps was trying to fix.
This endless taxonomy of terms for the people who do shit that we don't want to do is a definite drag on _actual_ acceleration of SDLC in the cloud.
GitOps does have a meaning beyond just “use git”. But you aren’t wrong that the strength of the meaning is rapidly fading as does any phrase that catches on with product marketing.
To me, DevSecOps is mostly about seeing what tests can be done whilst not getting in the way of the development/deployment process too much.
That's not a bad thing and there's meaningful security testing that can be done with that strategy, but it's hard to cover all aspects of security testing in a fully automated DevSecOps pipeline.
The missing link here is that "Ops" should no longer be the traditional imperative, reactive approach to systems design and maintenance.
Ops in all three of these becomes the modifier. This is why most practitioners today will tell you that DevOps/DevSecOps/SecOps are less individual titles and more a cultural way of thinking and operating and that the philosophy is executed by engineers of all types.
It's important to remember the origins as well. Prior to DevOps, developers and operations teams were siloed in ways that hindered healthy growth in todays distributed systems and cloud environments. These "*Ops" terms were born of the necessity to impress upon people the importance of interoperability between traditionally isolated and independent departments.
*Ops is the natural progression of Conway's Law into modern engineering organizations.
I'm sure this is redundant, but since no one has mentioned yet:
"The Phoenix Project" and "The Unicorn Project" are awesome books for this, and I recommend them both in audiobook.
This is absolutely wrong - DevOps is not a job title. At least it shouldn't be, as anyone in the sector will tell you. The conflation of DevOps responsibilities and specializations with SysAdmin work is the reason why the vast majority of "DevOps" teams are...vastly unqualified.
These are temporary job titles since most of the IT work these days comprise of gluing things together. I think these types of jobs will vanish with in the decade due to platforms like Microsoft's power platform or dynamics 365.
[+] [-] dijit|4 years ago|reply
It doesn’t tell me anything about what you do; and it implies that sysadmins never used to code either.
There are people pushing “devops tools” but those tools used to be called deployment or build tools. The word is pointless ambiguity.
Additionally: the “title” was coined as the name of a conference to include developers. The actual intended job title (and original conference name) was “agile systems administrator” according to the person who invented the word (Patrick Dubois).
http://blog.dijit.sh/devops-confusion-and-frustration
[+] [-] fourthwaveska|4 years ago|reply
Back when Luke wrote Puppet, he himself admitted that he was a mediocre developer with a good idea. His premise was that most SysAdmins weren't developers and that they would be more effective with a DSL that wrapped a templating engine and an executor then really learning how to code to build their own tools.
This set just an ugly trend. Next came Chef, which was written by someone (Adam Jacobs) who was pissed off at Luke because he felt entitled to 100% of his time. This was an incredibly dramatic exchange, Puppet Issue #1010 (I can't seem to find any of the old tickets anymore). Adam was making bank off of Puppet consulting, Luke was barely scraping by.
So Chef came along, it was supposed to bridge the gap between Puppet and developers. It was also garbage, but after a few years you could sort of kind of do real development on it.
Then we got Ansible, meh. Salt Stack which was more for managing api driven saas infrastructure but had/has a lot of the bad architectural decisions made by Puppet.
Now we have Terraform, which is OK, but also garbage. On top of that there's the Terraform CDK, which sort of lets you code, but is really just a golang-like DSL that generates HCL or Json. We also have Pulumi, which like the TFCDK, is a golang-like DSL that .. generates HCL to be run by Puppet.
All of this garbage because Luke felt that Sysadmins couldn't code.
[+] [-] chazu|4 years ago|reply
[+] [-] Chyzwar|4 years ago|reply
In others companies it means separate siloed DevOps teams and people, You need to raise request to do anything on your servers. Sometimes deployment mean getting DevOps team approval in process.
I also dislike DevOps terms because it is not specific enough on how you should organize Dev and Ops concerns.
[+] [-] k__|4 years ago|reply
It does, but to be honest, when I studied computer science "not coding" was a big deal.
There were many people who simply didn't like to do it for whatever reason, and those weren't "theory people". There were meetups on how to structure your studies so you would get your degree with at least code to write as possible, and most of those people focused on getting jobs in operations later.
For some of them DevOps was cool, because it finally allowed them to learn to code in an area they were interested in, but for others it meant their low-code jobs transformed to developer jobs over time, which they didn't like at all.
[+] [-] nix23|4 years ago|reply
Absolutely, i call myself adaptable Administrator ;)
[+] [-] stopyellingatme|4 years ago|reply
[+] [-] cyberpunk|4 years ago|reply
DevSecOps seems to just be plugging sonarqube into ci pipelines and installing siem/wafs.
Is it really better anywhere else?
[+] [-] q3k|4 years ago|reply
You have to convince developers that they're responsible for making software easy to deploy and debug, and get them to carry pagers during work hours. You have to convince them to make the product internals clear for everyone, including to operations people, and get them to do knowledge exchange with them. You have to enable them by providing insight into production deployments and providing a platform that unifies production/development as much as possible without tons of boilerplate required per project (common database interfaces, common logging interfaces, common CI, common release procedures, common development environment).
You have to convince operations teams to write programs in something other than bash, and to generally follow good software engineering practices, to write operations-level code that is as testable as the application itself. You have to enable them by giving them the means to build a company-wide production platform where complexity is decimated by moving every product team onto the simplest possible setup. You have to let them build bespoke tooling and accept that these lines of code are as important as the application code itself.
With all of this implemented well, the differences between ops and dev roles will begin to blur, people with different backgrounds will mingle within and across teams, and you will end up with a more platform/product split between teams rather than a development/operations split.
[+] [-] allendoerfer|4 years ago|reply
[+] [-] temp0826|4 years ago|reply
[+] [-] tupac_speedrap|4 years ago|reply
[+] [-] gonzo41|4 years ago|reply
[+] [-] jstx1|4 years ago|reply
Apart from the name mismatch and that it could have been just "Ops".
[+] [-] bovermyer|4 years ago|reply
I am not a "DevOps" engineer. I am a digital platform engineer, with specialization in writing code to connect things to other things.
When I talk to people outside of tech, I just tell them I'm a software engineer. It's close enough.
[+] [-] zikduruqe|4 years ago|reply
[+] [-] trabant00|4 years ago|reply
Thank you for all the buzzwords without which poor sysadmin old me would've never heard of coding, automation, security, version control and so on. /s
[+] [-] gls2ro|4 years ago|reply
ProdBizSupportUxGitDevSecOps - one person doing everything (or maybe I am msising some other Ops)
On a more serious note I think there is a trend to ask a lot of deep knowledge from one single person in too many areas.
[+] [-] chazu|4 years ago|reply
[+] [-] goodpoint|4 years ago|reply
I hoped it was a parody. Making up fancy names for ordinary things - I wonder if it's hubris or immaturity in the industry.
[+] [-] skywhopper|4 years ago|reply
[+] [-] raesene9|4 years ago|reply
That's not a bad thing and there's meaningful security testing that can be done with that strategy, but it's hard to cover all aspects of security testing in a fully automated DevSecOps pipeline.
[+] [-] notwedtm|4 years ago|reply
Ops in all three of these becomes the modifier. This is why most practitioners today will tell you that DevOps/DevSecOps/SecOps are less individual titles and more a cultural way of thinking and operating and that the philosophy is executed by engineers of all types.
It's important to remember the origins as well. Prior to DevOps, developers and operations teams were siloed in ways that hindered healthy growth in todays distributed systems and cloud environments. These "*Ops" terms were born of the necessity to impress upon people the importance of interoperability between traditionally isolated and independent departments.
*Ops is the natural progression of Conway's Law into modern engineering organizations.
[+] [-] CrazyPyroLinux|4 years ago|reply
[+] [-] sparcpile|4 years ago|reply
SecOps = sysadmin has to apply the CIS/SCAP/whatever security template to the machine
DevSecOps = developer also has to apply the CIS/SCAP/whatever security template to their machine
It all ends up becoming marketing jargon for suits looking to follow the next big trend.
[+] [-] chazu|4 years ago|reply
[+] [-] amne|4 years ago|reply
[+] [-] drran|4 years ago|reply
Sysadmin is a System Administrator, which performs operations manually.
[+] [-] polotics|4 years ago|reply
[+] [-] aaccount|4 years ago|reply