Re:DevOps uses a capability model, not a maturity model
by marcosdumay on Thursday April 06, 2023 @10:15AM
(#35468573)
> 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.
Re:DevOps uses a capability model, not a maturity model
by mjr00 on Thursday April 06, 2023 @10:27AM
(#35468706)
> 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.
Re:DevOps uses a capability model, not a maturity model
by nightpool on Thursday April 06, 2023 @01:44PM
(#35471798)
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"
Re:DevOps uses a capability model, not a maturity model
by morelisp on Thursday April 06, 2023 @04:35PM
(#35474028)
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.
Re:DevOps uses a capability model, not a maturity model
by Leo_Germond on Friday April 07, 2023 @01:02AM
(#35478207)
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.
Re:DevOps uses a capability model, not a maturity model
by seidoger on Thursday April 06, 2023 @05:46PM
(#35474975)
> 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.
Re:DevOps uses a capability model, not a maturity model
by KingOfCoders on Saturday April 08, 2023 @08:07AM
(#35492479)
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.
Re:DevOps uses a capability model, not a maturity model
by KingOfCoders on Saturday April 08, 2023 @08:06AM
(#35492473)
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.
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.