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."
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.
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.
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.
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,
What DevOps was supposed to be was the leave the system administration to the admins and let the Dev teams maintain their product. Ops should not be burdened with directly supporting Dev's products. If something goes wrong, Devs should fix it. Ops should make tools that allow Devs to deploy their production code in a safe way.
In other words, Ops manage the infrastructure and tools, and devs manage their applications on the infrastructure using the tools ops gave them. This becomes important as the number of products is constantly changing. Ops can't keep up with managing some dev's web app for them.
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.
> I can't wait for the DevOps movement to die a quiet death,
If I were you, I'd wait to see what replaces DevOps You may well end up looking back on the good old days of DevOps.
Being long since retired, I have no experience with the DevOps concept. It sounds pretty bizzare. I suspect that any organization that found it appealing will buy into most any magic based development scheme.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
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.
Docker isn't that bad. Although we did have some operations people who understand how it works, so we know that you have to scan the original host that the containers were made on for vulnerabilities and make sure it is patched and all of that before you deploy a new one. And that you have to rebuild and redeploy it when patches and vulnerabilities are released.
Yeah, there was a lot of "developers love Docker", but as an ops person, I think it can help with some of the real issues we have around scaling and even security. We don't "need" Docker for that, because there are other tools that could do all that, but it's actually okay.
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
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.
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.
"Being long since retired, I have no experience with the DevOps concept. It sounds pretty bizzare."
It is not, in fact. It all boils down to just taking a tight team of people, with the proper push, seniority and complementary abilities to cover top to bottom a service's needs and let them do their stuff.
Doesn't sound such a new concept, does it?
"I suspect that any organization that found it appealing will buy into most any magic based development scheme."
Probably you are right since any organization that thinks "DevOps" is a new shiny silver bullet is so disconnected to their business reality that they already are cannon fodder for any snake oil seller -of course, that's the case for a depressing percentage of business anyway.
"Docker isn't that bad."
Docker isn't that bad in the same sense PHP isn't that bad: while it may be judiciously used in some scenarios, it's ability to be misused probably makes it safer to just outright ban it.
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.
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.
Where are my freaking mod points when I need them ?
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.
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 can't wait for the DevOps movement to die a quiet death,
If I were you, I'd wait to see what replaces DevOps You may well end up looking back on the good old days of DevOps.
Being long since retired, I have no experience with the DevOps concept. It sounds pretty bizzare. I suspect that any organization that found it appealing will buy into most any magic based development scheme.
If you have no experience with the DevOps concept and it's something that sounds bizarre to you, you probably just never worked in a small organization. If the organization is small enough, the sysadmin and the developer are the same person. As an organization grows and additional staff are hired, you will see more specialization but it's still not unusual for a dev to retain the ability to deploy to production in smaller shops. Even if that's not the case, in a smaller shop the devs and the operations people are seen as part of the same team rather than separate entities and are accustomed to working closely together.
In large organizations you have more specialization and often times more bureaucracy and less efficient communications. Software is more complex and so is the release process. What I see devOps as doing is using tools to add automation to the process so that fewer steps that require human intervention are required. What remains are the cultural barriers that say "this thing must be performed by this group, fill out this form and we'll schedule it" when in reality if all groups worked together, a simplified process could work much more efficiently and reliably.
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"?
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 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.
Heh, you should read the new proposed security assessment guidelines for the FedRAMP Accelerated program for government Cloud purchases.
They basically suggest that containerized applications are a higher level of security than VMs. If you understand the sort of reasoning they're using it sort of makes sense, due to smaller attack surfaces and all of that, but I still found it amusing.
Unfortunately, that hilarity will likely become the standard for government Cloud security soon. So, biting my tongue, installing Docker, hoping for the best.
"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.