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.
I can't even read through this guys opinion. WTF?
"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?
Holy jesusballs that is a lot of typos
Looks like lack of Unicode support to me. Let's hope Whipslash et al are on it.
Socialism: a lie told by totalitarians and believed by fools.
Unicode on Slashdot is dead!
Breakfast served all day!
'nuff said
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.
Fixed
I don't know if you've noticed, but every single story on Slashdot links to another site. I guess we're doing free advertising on literally every story we post.
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.
The problem in this case is that it's a shitpost linking to an "article" of absolutely no substance on a topic. "DevOps" is nothing more than a meaningless buzzword used by startups and those aping them in order to seem hip.
Buzzword is dead! Long live buzzword!
(Holy fucking shitty journalism - I clicked into TFA after writing the above - the closing line is "DevOps is dead. Long live DevOps!".)
managers have outsourced -EVERYTHING-, rendering devops, whatever that is, dead along with the entire IT industry
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.
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.
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.
Respectfully, I've been reading about the death of the site for years. It may well be dying, but I don't think Netcraft has yet confirmed it.
Since "Smartling" doesn't even have a Wikipedia entry I checked out their jargon-heavy web site. It looks like they are just another middle-man marketing organisation as every single job there has something to do with sales or marketing. I can't even find a product on their site because every page seems to be more circular buzzword filled crap with no substance, no definitive goal, no results, no demonstrations and no software. They seem to do something involving translations for web sites and "content", which anyone can already do for free with Google Translate.
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.
I've been converted into a developer only I still spend my time doing operations and challenging developers to work securely. I rescue them regularly and explain their errata with your code is bad, your toolbelt is weak or this kernel bug hates you.
You're right about everything but it can be a miserably rewarding existence as if something like that is possible.
DevOps is dead and people like me dragged it out into the street and shot it. Here's a firewalled sandbox go nuts devs. To quote Martha: It's a good thing
---Up Up Down Down Left Right Left Right B A START
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 problem is that DevOps was like cloud computing... something that every company wanted to hop on the bandwagon. Especially when it comes to cost... why have a developer and a sysadmin, when you can have people banging out code, and doing the sysadmin work, with all the trendy tools of the trade (elk stacks, CM tools, CI/CD stuff, and so on.) Having a DevOps guy, to PHBs, means one less H-1B to have to fill out paperwork for and put out bogus job reqs like "five years of Apple's Swift".
Problem is that when you buy a dev/sysadmin who does 50/50 of each and load them down with duties on both sides, you will either get good IT work, good dev work, or a half-assed job between the two.
It's rapidly becoming, if not there already, cleverly disguised click bait of the lowest scientific or tech quality.
~ People that think they are better than anyone else for any reason are the cause of all the strife in the world.
Totally
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.
Not really a joke--I've run into devs trying exactly that often enough. The fix is to align permission with responsibility. Want root? Here, have the whole box, and so now babysitting your contraption is your job. Have fun!
(This is one reason, along with the fantastic underutilization of the hardware that's all that windows gives you, why the overhead of virtual machines is actually worth the cost.)
That, or indeed do the whole change dance and explain what you're doing. Change control is about packing up the changes for reproducibility -- and shaving off the obvious warts and guarding against backfires and so on. Something devs in their hubris like to gloss over, part of the personality that usually gets selected for the job. If you don't want to do that yourself you can delegate that but then you end up explaining what you're doing anyway. Explaining what you're doing is a core skill for anyone with "incomprehensible" tech jobs. If you can't do it, you're not up for the full job. Better get somebody who can to babysit you.
If that's what DevOps does then it's an improvement on the tech scene.
The lady doth protest too much, methinks.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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"?
Most people, especially in most larger organizations, never "got" DevOps, never "did it" and basically just dream up empty arguments about something they've never really experienced or understood correctly. The circumstances don't really allow it, so these people are just doomed.
Look to smaller operations, smaller companies, they've always been doing "DevOps". It's called collaboration. Everything else is a consequence of that. Doesn't have to be limited to just two groups of people either.
This is like asking people to paint like Picasso. Of course they won't "get it"!
Captcha: existing
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.