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.
...advertising for techcrunch? Have you really sunk this low?
BeauHD. Worst editor since kdawson.
Please, somebody get CmdrTaco to start a kickstarter to get the site back ...
Life isn't like a box of chocolates. It's more like a jar of jalapenos. What you do today, might burn your ass tomorrow.
I can't even read through this guys opinion. WTF?
Holy jesusballs that is a lot of typos
captha:drunker
"DevOps was invented as a way to unite developers and IT operations (system administrators) to help them find a common ground."
I thought the idea was to make developers do system administration and save money. Did I miss something?
Do you have ESP?
Unicode on Slashdot is dead!
Breakfast served all day!
'nuff said
Hey, Mike can you deploy this summary for me? Just copy it from the email I sent you.
Editing, as we know it, is dead. Perhaps not many people agree with me, but the age of editing is just about over he age of DevOps is just about over. ItÃ(TM)s a ÃoePerfect Stormà scenario in some ways. Submitters donÃ(TM)t know much about spelling and UTF and editors donÃ(TM)t know much about how the English language is supposed to work.
DevOps is a large, stinking pile of bullshit. While the idea may have originally been to encourage tighter collaboration between developers and system administrators in "agile" environments, that's not how most "DevOps" environments work. In most cases, DevOps ends up being implemented as a way to save money by combining development and operations positions into a single hire.
The problem with this approach is that most developers do not understand or have experience with proper system administration practices, and most system administrators aren't the best developers. You typically end up with one or more of the following scenarios:
1) the re-invention of multiple wheels as DevOps w/development backgrounds build custom tools and processes for themselves, rather than leverage existing and long-standing tools/practices known to experienced system administrators.
2) the installation of multiple development tools on production systems (bad for all kinds of security reasons).
3) deployment tools that unfailingly trust 3rd party repositories as part of their build processes (see: Node's / npm's recent "left-pad" fiasco). Hey devs: take a cue from @siracusa about how to *properly* manage 3rd party dependencies and *remove* 3rd party repos from your production build scripts
4) Docker. Containers are great! We love containers! Wait, what? We should apply security updates to our container? I'm sure the upstream maintainer is doing that. I TRUST THEM IMPLICITY! MOAR CONTAINERS!
and so on...
I was going to come up with a flip side to this, which would be bad things that sysadmins turned developers do - but I'll leave that as an exercise to the reader.
I can't wait for the DevOps movement to die a quiet death, just so HR people will stop trying to use it as an excuse to merge two complementary but non-interchangeable positions into a single hire.
I am confused. I thought FreeBSD is dead!
Insert BOLD claim here to get attention because I'm lonely.
DevOps, as we know it, is dead. Perhaps not many people agree with me
Should have stopped right there.. because the next sentence fragment should be "because I'm a raving lunatic who doesn't understand the words coming out of my mouth"
It is now official. TechCrunch has confirmed: DevOps is dying
One more crippling bombshell hit the already beleaguered DevOps community when TechCrunch confirmed that DevOps market share has dropped yet again, now down to less than a fraction of 1 percent of all positions. Coming on the heels of a recent TechCrunch survey which plainly states that DevOps has lost more market share, this news serves to reinforce what we've known all along. DevOps is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive job openings test.
You don't need to be the Amazing Kreskin to predict DevOps's future. The hand writing is on the wall: DevOps faces a bleak future. In fact there won't be any future at all for DevOps because DevOps is dying. Things are looking very bad for DevOps. As many of us are already aware, DevOps continues to lose market share. Red ink flows like a river of blood.
AgileDevOps is the most endangered of them all, having lost 93% of its core developer/administrators. The sudden and unpleasant departures of long time AgileDevOps developers Andrew Clay Shafer and Patrick Debois only serve to underscore the point more clearly. There can no longer be any doubt: AgileDevOps is dying.
Let's keep to the facts and look at the numbers.
OpenDevOps leader Lennart Poettering states that there are 7000 users of OpenDevOps. How many users of SystemDevOps are there? Let's see. The number of OpenDevOps versus SystemDevOps posts on Slashdot is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 SystemDevOps users. DevOps/OS posts on Slashdot are about half of the volume of SystemDevOps posts. Therefore there are about 700 users of DevOps/OS. A recent article put AgileDevOps at about 80 percent of the DevOps market. Therefore there are (7000+1400+700)*4 = 36400 AgileDevOps users. This is consistent with the number of AgileDevOps Slashdot posts.
Due to the troubles of Caldera, abysmal sales and so on, AgileDevOps went out of business and was taken over by SCODevOps who sell another troubled OS. Now SCODevOps is also dead, its corpse turned over to yet another charnel house.
All major surveys show that DevOps has steadily declined in market share. DevOps is very sick and its long term survival prospects are very dim. If DevOps is to survive at all it will be among OS dilettante dabblers. DevOps continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, DevOps is dead.
I was doing DevOps before it was cool, and now I'm doing it after it's obsolete. Warby Parkers and luxuriant 1800s facial hair should spontaneously appear on my face any second now.
"When information is power, privacy is freedom" - Jah-Wren Ryel
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.
"Developers don't know much about deploying and systems administrators don't know much about how the code is supposed to work."
That's the problem. DevOps was never a solution, but more the term used by companies that were searching for a solution. Lots of studies done, probably lots of consultants got paid - but an actual solution that was better than what people had been doing for years anyway? Never seen one yet...
Enjoy life! This is not a dress rehearsal.
managers have outsourced -EVERYTHING-, rendering devops, whatever that is, dead along with the entire IT industry
clickbait
DevOps isn't dead. It just smells funny.
But someone still has to come in and write the required tool set.
This is what is killing it. Not the idea that developers have to write deployable, maintainable stuff. Ops needs to plug it in correctly. So lets create a software lifecycle that sits both parties down at the table while the requirements paper is still blank. That's a good idea. What makes it smell like a rotten corpse is the idea that a nice, shiny toolset must be procured to do the job. And consultants tacked big price tags onto their products and shoved them down the CIO's throat.
Have gnu, will travel.
ButtScractha! Get Cha' ButtScractha Here! ButtScractha!
Click-bait! Get Cha' Click-Bait Here! Click-Bait!
How's are these?
God Is Dead - Discuss!
Morals Are Dead - Discuss!
Python Blows Like A Cold Winter Day In the Arctic - Discuss!
Girls Can't Code - Discuss!
Only Girls with a Natural Vagina Should Use a Girls Bathroom - Discuss!
SlashDot Is, Was, Or Has Become a Badly Spelt Click-Bait Havens - Discoos!
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,
It's always a good day when a buzzword dies before I ever get the chance to learn what it means.
Not dead, just lying comatose until the next generation of MBAs "invents" it again.
Or...were DevOps just an invention to try and get sys Admins to do development work so you didn't have to hire a developer at a higher cost? Now we just need ExecOps so that we can fire all the executive staff and have our sys Admins do everything the CEO used to do at a tenth of the price.
System configuration is part of the solution. If developers can't define the needed system to be deployed in, they can't test their end product either. The term DevOps should have never existed, but is now really an ice breaker at the bureaucratic pack ice.
I checked into the author's venture, Runtime Technologies, and this is one of the blurbs I found;
One suspects their staff writers are quarantined deep in the darkest heart of Dogfood City.
I've been doing "devops" for 30 years. Or call it "full-stack development". I personally call it being familiar with all the tools at my command.
SRE, or Site Reliability Engineering, is the future of asking a team of engineers to handle a production environment. In fact, Google literally just released their book on the subject. https://landing.google.com/sre...
Developers don't know much about deploying
That's what you get when you can the more experienced, more expensive developers for twice or three times the number of code monkeys.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
Whose responsibility is it when something goes wrong -- the person deploying the code or the developer?
If devops is to work, don't these have to be the same person?
DevOps killed Kuali, it's fitting that DevOps should die as well. Watch out for zombies GM.
I think that DevOps was dreamed up by a bunch of bean-counters (CIOs, CFOs, Accountants, etc.) to reduce headcount and make the developers (the "Dev" part) be responsible also for deployment and operation (the "Ops" part) of the infrastructure and systems. Because, they argue, that Developers can deploy code, but Operations personnel cannot develop applications. It was doomed to fail from the outset. Any decent software developer who is an analytical, creative and disciplined designer and writer of computer programs views the deployment of code and the ongoing maintenance of the systems that run it as a janitorial chore. They don't want to do it. Its a different mindset. Likewise the 'Ops' folks love the infrastructure, spinning things up and watching them hum along - they breath life into that code for the end users and keep the users happy. They are different mindsets and different skill sets. And different talents and temperaments. Developers *must* be risk-takers to innovate or rise above anything above mediocre. Quite the opposite is true of the Ops folks who, while no less important than the developers, cannot gamble and take risks - they thrive on "uptime", no exceptions and nothing out of the ordinary. Ops people often like to dabble and develop tools and utilities to help them do their job, and they do it expertly, but they don't want to maintain 50000, 100000 or 2000000 lines of ever-evolving source code.
A scientist that develops a product - a cosmetic, a glass cleaning fluid, whatever - doesn't want to be trudging the streets banging on doors to sell it - they want to be developing the next product. The salesperson on the other hand doesn't want to be slaving for years with no payoff to develop a product - they instead want to be on the streets immediately engaging people to consume the product with the least effort, time invested and risk - they want predictable and near term results. They are by nature and design different.
Developers don't want the chore, boredom and rigor of the Ops folks and Ops folks don't want the uncertainty and unpredictable outcomes and challenges that Developers face. It is a fantasy in the mind of naive bean-counters ignorant of the temperament, personality, mindset, skill set, likes and dislikes of the essential distinct disciplines of software development and software deployment and maintenance. It's just not true that they can be exceptionally well done by the same individual and sustained at that level. I could be wrong, but I don't believe that when you take any two related entities and reduce them to a common denominator that the quality of either entity is elevated above its initial state, nor that the quality of the whole is greater than the sum of its two constituent parts. The final consumer then, of the common denominator, is inexorably receiving an inferior product.
The DevOps fallacy might spin well in a boardroom for a while but eventually it will show on the bottom line as the quality of product and service decline and the personnel turnover increase.
The need for automated deployment isn't going anywhere. The bigger your site, the more important it is to have automation in place. It doesn't matter whether you are running on servers in the next room, or on Amazon, you still have to have a reliable deployment mechanism, unless you can tolerate prolonged outages. DevOps might be called something else, but it's not going away.
The idea of DevOps is to improve the communication between operation and development. Especially as software becomes more fluid, the constant change requires not only improvements in development, but also methods to deploy the software without destroying the system and without giving the admins a headake .
In the beginning was the word
and the word was buzz and it was bad.
Then Satan moved over the face of of the CIO and said:
"Let there be darkness"
And the evening was really dawn, and it was already the fifth day because it was crunch time.
Then Satan said "let there be bugs"
and there were bugs. Boy were there bugs...
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
If you you strip away the hyperbole, the original story is getting at the valid point that the sensible balance of infrastructure control is shifting away from IT and towards Developers and normal users. In that respect it is kind of obvious to those of us who've been around for a while; the stuff that users can easily do today would boggle the mind of most sysadmins from a few years ago.
However, it doesn't automatically invalidate the need for the DevOps function within an organisation. In many instances the engineering problems we are tackling now are far more challenging. Jenkins with Docker running on boxes under someone's desk (or in the cloud) will probably work well for a team of four or five linux hackers in a single office. But if you've got 100's products for multiple OS/arch combinations being produced by 1000's of contributors globally and continually releasing, then having a good DevOps function is essential..
All that's really happening is the goal posts are continuing to move and you can now get away with a bit more organisational/product complexity before it becomes sensible to centralise the DevOps (or whatever it is being called this year) function.
There never was that level they call DevOps. And I'll tell you something I've sene with Agile over the years. Two things fall down completely flat with Agile - bug chase and documentation.
DevOps is just another named iteration of a thing who was there all the time... it's just a buzzword. it's not about the name and definitions it's about what needs to be done and by whom. who cares if a system administrator or DevOps or Integration engineer or system developer. just another buzzword.
Look, it's very simple, every company needs this: Define a business process and implement it so it will service all the needed people and system the fastest, the easiest with rollback option and no downtime. now you can choose the title.
Devops is just another named iteration of a thing that been always there. It's buzzword, nothing more nothing less, this is why it's really hard to define this thing. For me, it's all about this: The business defines a business process or goals, someone design and plan it and someone implement it so it will be the fastest, easiest and accessible for all the people/systems, all that with a rollback option and no downtime. going back to your assumption, you can call it devops, system ops engineer, integration engineer, system programmer, system administrator, someone who know how to program and but of how to install things and all that and etc. DevOps is not dead since its just a buzzword. stick with the business goals and stop, that will actually help.
"DevOps was invented as a way to unite developers and IT operations (system administrators) to help them find a common ground."
This quote got it right. But there are problems:
Companies want to sell a product.
Right, "I want buy a hundred units of teamwork please."
Devs quite often see it as a way to bypass Operations:
"We will automate everything so we won't need any pesky sysadmins."
Ops are often in charge of NO:
"No thank you. We don't trust development and our way works just fine."
Tool chains and other tools are useful, but they are not the main focus of DevOps.
The most important feature of DevOps is team building (IMHO):
Getting Dev and Ops to work together
Getting Dev and Ops to trust each other
BTW, it really is DevQaOps:
QA is a critical member of the team. They write the automated tests that give Dev immediate feedback about problems. Automated test give Ops the confidence that when they deploy new code the site is not going go down. There may be problems but they will be minor. Not show stoppers that make the site stop working.