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.
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.
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.
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.
Many struggle with "if you build it, you operate it" because many developers don't want to be on pager duty.
Yes, this is definitely happening.
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.
In my perspective, DevOps is a fundamentally different job from what Systems Administration has historically been.
It’s a strange new world to me but I like it.
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.
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.
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.
System Administrator responsibility is limited to...adminstration/operation.
If you have "DevOps" positions that have dual responsibility to operate and develop, that it something different, no?
---
I'm not saying this is actually the case. But DevOps being a job is not necessarily just a rebranding.
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.
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.
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.
- Use Terraform to build infrastructure as code
- Get involve in containerising applications
- Run and operate Kubernetes
- Spend a lot of time on CI/CD
- Improve the development experience
- Implement service discovery
- Build and run developer platforms
- (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.
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.