Is it because of the unwanted surprises? Or because it's too difficult to do?
It is because it breaks our development workflow. Imagine you are an accountant working on a financial report to the board which is purely a desk affair but frequently you have to go down to the warehouse and factory to manually count hard assets which should have been done by an internal audit team.
Imagine if you are working the cash register at the take away drive through window with a long line of cars waiting for their turns but you need to go to the kitchen to prepare the food yourself for every order instead of delegating that work to dedicated kitchen staff.
Anything that requires concentration and focus like maths or programming does not mix well with other equally time consuming and attention diverting issues like DevOps or taking support calls.
You have this mathematical structure and branching in your brains and your brain is spinning for pattern matching and what ifs scenarios and logical tests and you are forced to stop this momentum, suspend it in memory to attend to some DevOps concerns which require a different theater and orchestra to be set up in your brain only to be suspended again to load all the previous intricate programming context and re-familiarize your brain with all the twist and turns you had taken earlier and track where you are in that logical mesh.
I'm not sure I got the question correctly, but @chilimatic has a very good point: in many (most?) companies, DevOps is a buzzword but not real. I mean, HR realized that DevOps had much more traction than Sysadmin, so they just replaced sysadmin in their job posts.... but from what I see here the majority of 'DevOps' jobs are in fact sysadmin ones, with only ops and no dev.
When you want to hire a devops so that the engineers don't have to care about the ops, you got it wrong. DevOps is a philosophy first. You need a leader/heo/guru/whatever to lead that mutation/philosophy change, but doing devops can only be done if all the dev side is taking ops into account (I'm not saying they should manage the ops, but they should care about it.
True devops is achieved when the ops side (alerts, incidents, ...) in handled by specialized software engineers that also master the ops side (the real devops job), and when the software development is done by people understanding (at least the big picture) and taking care of the ops side (how will my software be run, what's the underlying infra, how is the system discovery working)
As long as it's used as a sysdamin-recruitement buzzword to hire a sysadmin to do the ops while the engineers to the dev, it will be nothing more than a buzzword. But some places got it right and really try to move forward and increase their velocity and resiliency by adopting - as a team - the philosophy.
There are some good answers here. As always, "it depends". It's not always undesirable, but most of the time it is. In my experience, DevOps is often responsible for maintaining legacy systems, thus never gets to create new stuff. DevOps is also at the beck and call for other internal staff, thus a constant flow of interruptions and arbitrarily prioritized demands. Their job is to hold things together while all the other devs get to work on the new, cool stuff.
Azzuwan Aziz
Problem Solver
j
stuff ;)
In my experience since I worked as DevOps and a Senior Dev and blabla arbitrary startup jobtitles.
Devs mostly wanna remain in the "Virtual-Realm" they wanna create and code their idea.
For example how many Devs are thinking about the CAPs theorem when using concurrency or Message Queues and how the encryption is working inside the CPU :) ....
Or how Virtual-Ram is accessed or the Kernel handles Memory? how does the machine interact with your App/Code and how to optimize it?
They don't want to care how Docker, Vagrant, Varnish, nginx works .... it just should work, so they can do what is interesting to them ... to create an Idea.
Oh ... and you become the bitch for everything as well, since many companies mistake DevOps with Ops .... gg so you're stuck doing system monitoring, reading the data logs analyze 3rd party dependencies and have less time to implement something you'd like. Fighting with the Ops to get basic access, fighting with you co-workers about "Understanding SQL is better than an ORM" and so on and so on :)