DevOps as a movement died when it started being used as a job title. In my experience, it quickly stopped being a philosophy for Dev and Ops teams to work on working better together and just because a new name for System Administrator.
Before the popularity of the term "DevOps" it was always true that any System Administrator worth hiring knew how to script for automation (the job title for people who didn't was System Operator). Unfortunately the market was flooded with a lot of people in that role who barely knew what they were doing and so resisted every change anyone else in their company wanted.
From my perspective, the greatest achievement of the DevOps movement was to push the bar higher for the expected skill level of the average SysAdmin. I see that as a good thing.
> DevOps as a movement died when it started being used as a job title. In my experience, it quickly stopped being a philosophy for Dev and Ops teams to work on working better together and just because a new name for System Administrator.
The "DevOps" job title can arguably just be a sysadmin, but I do think the main ideals of the movement are just so tightly ingrained in software now that we don't even notice.
It's easy to forget that 10-15 years ago, the most common dev/ops model was "toss it over the fence"--developers write code, do a ton of QA work on the test system, and then toss it to ops, who had no idea what metrics to look for beyond standard cpu/mem/etc. Your dev team would write up a "runbook" for operators to follow if anything broke, which was usually just restarting things until they got into a good state again. The big tech players of the 00s like AWS and Google were probably more advanced of this, but the rest of the world largely wasn't.
Now, the most common model for companies of all sizes is "if you build it, you operate it". Devs are expected to know what metrics to expose, have oncall rotations, and have direct access to their production systems. Cloud, CI/CD and git helped quite a lot in this regard, reducing time between deployments from months to weeks to days to hours and minutes.
This continues to be the lasting legacy of "DevOps" IMO, it shouldn't be understated how much of an impact it had on our industry.
> It's easy to forget that 10-15 years ago, the most common dev/ops model was "toss it over the fence"
15 years ago it was often still I without the C, integration that wasn't continuous. Code freeze 1 month before release, put all the bits of code together, everything breaks, try to fix it.
And with the bad (compared to Git) merging capabilities of SVN, last minute merges of feature branches (hurray branchless!) for a release cadidtate to hand over to QA were a nightmare.
I do think CI/CD and automatic deployment made the difference. Coming from copying a Zip file to a server, to deploying a WAR, to having release trains wit dedicated ops teams most of my CTO coachees now have automatic deployments and ops teams mostly for monitoring, incident management and capability planning.
Many struggle with "if you build it, you operate it" because many developers don't want to be on pager duty.
> It's easy to forget that 10-15 years ago, the most common dev/ops model was "toss it over the fence"
Hum... My first guess is that what really changed was the ratio of developers working on places that do this to the ones working on places that integrate the jobs.
The wall was never the only model around. It still isn't. The same kind of company that practiced it still largely have walls. The IT industry just hired a lot of people.
> Hum... My first guess is that what really changed was the ratio of developers working on places that do this to the ones working on places that integrate the jobs.
Well sure, and that's because software companies that integrate the jobs is now so much more widespread and commonplace, thanks to "devops". Kind of my point.
I agree, but I think the GP makes a good point that it wasn't really necessarily any sort of initiative or movement within the organizations that had bad practices—or even the types of organizations that had those practices, like legacy IT orgs—but instead the groundswell of new organizations, including startups, small/medium-businesses, and other more-modern technologies companies, that drove the adoption of new practices. And in most cases, they did this by necessity—they didn't have the funding to pay two separate teams to manage their new website, they didn't have the luxury to wait for 6 month deployment cycles, they needed the reliability of continuous testing but were able to take the up-front cost of short-term unreliability to build up those test suites. Only once engineers who had used these practices and seen them be successful at other companies started to migrate to more legacy industries did devops practices start seeing adoption outside of the "bleeding edge"
Your optimism is refreshing but ultimately wrong. We did "solve" those problems but then immediately 10xd the incidental complexity of both our development and operations work in exchange for nothing.
I'm not sure where this 10x comes from but if this is about modern on-demand CI clustered runners vs old timey dedicated hardware and servers, then you have to take into account the fact that those hardware and servers were never properly cleaned of their mess, hard to configure, and had low general availability. This switch was a big gain IMO, even if docker and k8s are far from being simple to operate.
As a developer and sysadmin, devops is distinctly different thing. Deep knowledge of operating systems is traded for knowing how to manage an entire virtual data centers with code. This is far beyond the “scripting automation” of the past.
In my perspective, DevOps is a fundamentally different job from what Systems Administration has historically been.
As a developer and sysadmin, there is no trade and only difference is that you probably (and I'm saying probably because probably some poor fucker had at some point) won't need to debug NIC driver/firmware problems on "cloud" server.
We have both on-prem and cloud stuff, we've ran automation (via Puppet mostly) from the very beginning, and so far biggest difference is that writing template-backed YAMLs is utter shit compared to "proper" programming language or purpose built DSLs.
Like, I complained that Puppet is just kinda "shitty half-finished programming language" compared to just having Python/Ruby as DSL but boy I'm fucking happy to use it now (and to be entirely fair, it got better over time as a language) compared to whatever the fuck tool is in vogue this time that uses the "data language + template language" (because apparently programmers deploying the code can't program or something) model for interaction.
Same kind of work sans running to DC to fix stuff but you now have black boxes you have no chances fixing/analysing yourself and your broken code might fix itself next day because you thought it was your bug, but just a given cloud API decided to return nonsensical error that looked like it was your fault (greetings to MS Graph API team here)
As a developer and sysadmin, there is no trade and only
difference is that you probably (and I'm saying probably
because probably some poor fucker had at some point) won't
need to debug NIC driver/firmware problems on "cloud"
server.
Then the words "private cloud" drop by, and you find yourself fixing idiotic purchasing decisions that somehow led you to building custom firmware ROMs for intel X520 NICs
I try to frame "DevOps" roles not as "doing DevOps work", but instead "enabling DevOps work". So, for example, setting up systems to make it easier for developers to take control of their own deployments and environments.
I joined the industry when "Systems Administrator" was becoming a generic term for "person who adds users to a server". Same thing happened to "DevOps": Google made some noise about how cool it was for coders to do Ops work, so people started assuming "DevOps" meant "a coder who adds users to a server". Stupid people come to stupid conclusions and popularity cements the new definition. Same thing with the terms "hacker", "skinhead", etc. C'est la vie.
DevOps died because it was a handful of engineers trying to force a movement about solving business problems. We were never going to be successful. Business people need to push the movement, not us.
That said, we can continue the movement anyway, if only to improve our own work. If more true DevOps faithful become managers, then directors, then VPs, then maybe in 30 years engineering orgs won't be run as horribly as they are now.
- (To a lesser extent) Build and run cloud environments including Serverless components
This seems like a new set of responsibilities which don’t fit cleanly into Development or Sys Admin, and are substantial enough such that someone could specialise in this role full time.
I think that DevOps as a job title is one of the best things that ever happened to the industry.
You may like Platform Engineering even more as there's a lot of crossover with what you mention. A key difference from your list is that you enable teams to build and run their own applications, so they remain responsible throughout. You would provide a simpler way for them to do it, so they could self-serve.
For me, coming from Ops, DevOps seemed like a description for people who worked almost exclusively in Web, service-style companies, where their goal was to ensure that continuous integration and continuous deployment did what their names suggest.
Having a DevOps onboard also surely meant that the company didn't need a system administrator anymore, but that's not really because DevOps was a new name for sysadmin -- they automated sysadmns out of existence.
I still prefer not to touch Web and service-style products. And, in my world, DevOps doesn't really exist. People with similar set of skills are usually called "infra" or "automation". Having worked in automation department one would most likely have learned enough to apply for DevOps position in a company which needs that, and vice versa.
It's like saying "hacking" disappeared when it started being used as a crime.
Hackers that fiddles with stuff still definitely exist.
The same way the DevOps movement still exists.
But your point is not invalid, hiring a "DevOps" engineer is futile; especially given how the goal of any engineer in charge of DevOps should be to render their job obsolete.
> DevOps as a movement died when it started being used as a job title. In my experience, it quickly stopped being a philosophy for Dev and Ops teams to work on working better together
I would argue that it was the other direction, in my experience the DevOps philosiphy was very similar in at the core to the agile philosophy; however it met the same fate as the agile movement. Everyone who was an "agile" consultant or "scrum master" found a new buzzword to declare themselves experts of and then use to go around doing a whole lot of nothing and generating impressive sounding promises, before moving onto the next gig.
Eh, I see devops as automated systems administration. Knowing how to be a good by-hand sysadmin is an enormous advantage in knowing how to automate things.
> From my perspective, the greatest achievement of the DevOps movement was to push the bar higher for the expected skill level of the average SysAdmin. I see that as a good thing.
I wish I agreed. As far as I can see, the title is just as closely associated with being an expert consumer of cloud services as it is with actual skills relevant to development and IT operations, or anything we'd recognise as sysadmin today.
Before the popularity of the term "DevOps" it was always true that any System Administrator worth hiring knew how to script for automation (the job title for people who didn't was System Operator). Unfortunately the market was flooded with a lot of people in that role who barely knew what they were doing and so resisted every change anyone else in their company wanted.
From my perspective, the greatest achievement of the DevOps movement was to push the bar higher for the expected skill level of the average SysAdmin. I see that as a good thing.