Slashdot Mirror
Opinion: DevOps Is Dead (techcrunch.com)
Andrey Akselrod, CTO and a co-founder of Smartling, writes for TechCrunch: DevOps, as we know it, is dead. Perhaps not many people agree with me, but the age of DevOps is just about over. It's a "Perfect Storm" scenario in some ways. Lots of events coming together that drastically change the status quo. And where it all began was the concept and eventual widespread adoption of agile development and continuous deployment practices. DevOps was invented as a way to unite developers and IT operations (system administrators) to help them find a common ground. The premise was to automate the development and deployment tools that require collaborations between both disciplines. But someone still has to come in and write the required tool set. Thus, most companies resolved to create DevOps teams that combined the expertise of both sides to support their developers. The old model of throwing the code over the wall to system administrators who would deploy it stopped working with agile processes and continuous deployment practices. Whose responsibility is it when something goes wrong -- the person deploying the code or the developer? Developers don't know much about deploying and systems administrators don't know much about how the code is supposed to work.
DevOps was invented as a way to unite developers and IT operations (system administrators) to help them find a common ground.
devops was invented as a means to staunch bleeding from companies with 50% or better turnover rates due to rushed products, shit management, and poor work-life balance. the idea being if you could get devs and ops to do eachothers jobs youd invent a new third commodity that could become more resillient to 90 hour work weeks and bullshit feature-before-fix code releases. It failed because devs arent great ops, and ops arent great devs.
The old model of throwing the code over the wall to system administrators who would deploy it stopped working with agile processes and continuous deployment practices.
this process stopped working because of the inclusion of draconian, conflicting, confusing, and often times lip-service change management processes that fit the quarterly management meeting and not much else. CM's gave project and team leaders the sensation of doing something every monday morning when they rubberstamped some code push, but otherwise made life hell when they left for vacation/hangovers. when a code push failed and had to be rolled back, management pushed again to have it rolled forward broken and defied often times their own decrees. In the same breath, theyd crucify you for updating a package or rebooting a server without 15 hours of review and objection from a guy who didnt know TCP from BBQ.
And when I say the cloud, I really mean managed services.
sure, maybe one buzzword killed another but it sure as shit wasnt the latest incarnation of thin clients, hosted services, SAAS, or PAAS, which we now call "Cloud." clouds are just other peoples hardware, so when your devops bullshit went down in flames as a transparent attempt to milk skilled professionals for free overtime and flex-goals, they all quit and submitted their CV's to the cloud. You didnt have to worry about devops for your precious service, but they in turn didnt have to worry about you anymore either unless you skipped a check for the month.
Good people go to bed earlier.
And where it all began was the concept and eventual widespread adoption of agile development and continuous deployment practices.
There's a difference between recognizing the limits of testing and ensuring you can rapidly respond if something doesn't go as expected and reverting is likely to be less successful than fixing forward.... and being unable to plan because you have no idea what you're doing and don't understand system troubleshooting.
But someone still has to come in and write the required tool set.
Yes, this group is called OpsEng.
The old model of throwing the code over the wall to system administrators who would deploy it stopped working with agile processes and continuous deployment practices.
If you're throwing over the wall, you're doing it wrong. You should be throwing it above or below you in the stack, with each group having a clear demarcation point and expected SLAs to other groups internally, so planning, risk assessment, and performance expectations can be performed appropriately.
Replacing one broken culture with another one doesn't fix anything; and DevOps nowadays usually results in developers trying to code their way around their lack of systems skills more than systems engineers getting to be able to communicate back to devs.
Hire a Linux system administrator, systems engineer,
As an operations person by trade, and a developer sometimes by necessity, there is a lot of truth to the idea that a DevOps person is merely someone who used to be called "that System Administrator who codes stuff for us" or a "that poor Developer who has been stuck with the sysadmin tasks and setting up Jenkins"
While buzzwordy, that sort of work might be something that is worth having a name of its own. So I think something that happens to go by the buzzwordy title of "DevOps" is real, but not quite in the way it was being pushed.
I used to joke that DevOps was merely the massive campaign launched by developers who were tired of trying to get Operations to give them root access in Production so they could change things without having to actually fill out a change control and explain to someone who wasn't a developer how to do it. And some of the ideas behind it still sort of smell like that, but that really never became real practice outside of a few types of applications that really lent itself to that sort of pacing.
Instead, I think it has sort of matured into a sort of tools mindset where we are able to use more software defined infrastructure and certain tools to actually break out of the mold of the sysadmin who was first and foremost that guy who was responsible for going to the datacenter and installing Linux or a hypervisor aside from any other tasks. We still need those people, but I think it this is a milepost in the differentiation of admins.
I don't hire "DevOps" people, and while that is the name of a cross-team group where I work, we're still Operations and Development and under different management. And strictly speaking, I always believed that this was how it was supposed to work. If there was anything where DevOps really provided value, it was in the very simple proposition that Ops and Dev should talk to one another and work less like two walled fortresses that occasionally sent heralds between them with formal communications. There is also value in your Puppet/Chef/Ansible/Docker as well, although that could have happened without "DevOps".
But more importantly, as a reference "description", if I tell a recruiter what I need and I was to say a DevOps person, they usually get me exactly who I want. I don't think that usage is dead or dying.
So no, I don't think DevOps is meaningless. It just isn't the "movement" that it started off as and it matured into something slightly different. Perhaps we'll call that something else more descriptive someday and the term can be relegated to the trash heap of history. Until the next buzzword.