This response is going to be a bit different from what you'd typically expect as answer to the question the author of this post has. I was in a role that could be considered "DevOps" somewhere around the end of 2013, at a time when the big changes, from traditional systems administration to what's now called "DevOps", began to happen.
The thing I liked the most about it was that it wasn't "DevOps" as it was known today, it was systems administration with some amazing (semi-)new tools that made the job significantly easier and the systems that came out of the job better, more stable, more predictable and easier to maintain.
At the end of the day I (or rather, the people I worked with and learned from, since I was extremely junior at that point in time) was an operations person. I wasn't an operations guy tasked with developing stuff, I wasn't a developer tasked with operating stuff. I had a clearly defined role and got to reap the benefits of tools and progresses made in culture.
At the same time it was still necessary for me to understand the architecture of the systems I was maintaining, to understand how the different moving parts integrated into each other. I needed to do that so that, if something went wrong, I could fix it. Understanding how everything worked was what helped me to utilize the aforementioned tools to their fullest capabilities. What I dislike about "DevOps" is, coincidentally, located in a very similar area.
Everything started out as an extension to traditional systems engineering / operations. A stronger focus on virtualization or the use of containers, more reliable automation software, integrating of mechanisms to validate / test configuration changes before rolling them out, encouraging development of better soft skills and more emphasis on the security aspects. The "Dev"-part of "DevOps" meant that aside from wonky shell-scripts there would be the occasional Ruby or YAML for configuration-related stuff.
That was what it started out as. But that's not what "DevOps" is nowadays, "DevOps" is .. well, nobody actually really knows. You have the textbook-definition, you have the definition that's uncomfortably prevalent in a lot of the European job-market ("Java-developer who can work with Jenkins and also do Kubernetes", you have the different filter-bubbles of developers who think they are operations people, you have the different filter-bubbles of operations people who think they are developers .. and more.
The uncomfortable reality, as it seems to me from my limited point of view, is that "DevOps" has become an excuse for management to save money. We don't need an operations team, we don't need a development team, we could just do "DevOps" and safe money that way.
There are tons of super-talented people out there who do amazing work, but in most cases, mixing those two fields will lead to results that aren't what they could be if you give people a chance to work in an environment they are truly comfortable with, knowledge-wise and task-wise.
As I pointed out in another thread, I'm very much interested in development, coding, software engineering. But it's not an area I have any form of professionally applicable knowledge in. My stackoverflow'd Python-scripts are an abomination. I'm a disgrace to the "Dev"-part. A friend of mine is an amazing developer, his solutions to software-related problems are elegant, efficient and way out of my league. The moment he tries to build a fail-safe system I'm crying tears of agony because he has no idea what he's doing.
Both of us would be considered "DevOps", both of us would, if it weren't for the company being a good one and assigning us responsibilities according to our area of expertise, would end up doing the exact same job, neither of us actually qualified for it. That's what "DevOps" tends to do, force people into roles they are neither comfortable with nor equipped for. On both "word-sides".
On top of the structural problems that come with "DevOps", I have some technical grievances with it as well. I'm aware that this is a personal, quite subjective opinion.
To make things simpler and easier to maintain, we added more and more abstraction layers. That, in turn, made everything more complicated in the long run. To deal with dependency hell, we created container. To manage containers, we created container-orchestration platforms. To manage those we created appropriate management tools. So instead of one source of potential problems, I now have four. Not exactly simpler.
My grievances for the problems with the modern tech stack (and the environmental problems surrounding it) would be big and lengthy enough for a dedicated, separate post & I don't want to make my comment any longer than it already is. The point I'm trying to make is that we, often, ended up overengineering the solutions to problems that could have been solved much, much easier.
Don't get me wrong, I'm very much for furthering developments and growth with regards to how we approach technological challenges. I dislike "DevOps" because I feel that we took more than a few very, very wrong turn somewhere along the road to today. That's why I dislike "DevOps" as it is today.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This response is going to be a bit different from what you'd typically expect as answer to the question the author of this post has. I was in a role that could be considered "DevOps" somewhere around the end of 2013, at a time when the big changes, from traditional systems administration to what's now called "DevOps", began to happen.
The thing I liked the most about it was that it wasn't "DevOps" as it was known today, it was systems administration with some amazing (semi-)new tools that made the job significantly easier and the systems that came out of the job better, more stable, more predictable and easier to maintain.
At the end of the day I (or rather, the people I worked with and learned from, since I was extremely junior at that point in time) was an operations person. I wasn't an operations guy tasked with developing stuff, I wasn't a developer tasked with operating stuff. I had a clearly defined role and got to reap the benefits of tools and progresses made in culture.
At the same time it was still necessary for me to understand the architecture of the systems I was maintaining, to understand how the different moving parts integrated into each other. I needed to do that so that, if something went wrong, I could fix it. Understanding how everything worked was what helped me to utilize the aforementioned tools to their fullest capabilities. What I dislike about "DevOps" is, coincidentally, located in a very similar area.
Everything started out as an extension to traditional systems engineering / operations. A stronger focus on virtualization or the use of containers, more reliable automation software, integrating of mechanisms to validate / test configuration changes before rolling them out, encouraging development of better soft skills and more emphasis on the security aspects. The "Dev"-part of "DevOps" meant that aside from wonky shell-scripts there would be the occasional Ruby or YAML for configuration-related stuff.
That was what it started out as. But that's not what "DevOps" is nowadays, "DevOps" is .. well, nobody actually really knows. You have the textbook-definition, you have the definition that's uncomfortably prevalent in a lot of the European job-market ("Java-developer who can work with Jenkins and also do Kubernetes", you have the different filter-bubbles of developers who think they are operations people, you have the different filter-bubbles of operations people who think they are developers .. and more.
The uncomfortable reality, as it seems to me from my limited point of view, is that "DevOps" has become an excuse for management to save money. We don't need an operations team, we don't need a development team, we could just do "DevOps" and safe money that way.
There are tons of super-talented people out there who do amazing work, but in most cases, mixing those two fields will lead to results that aren't what they could be if you give people a chance to work in an environment they are truly comfortable with, knowledge-wise and task-wise.
As I pointed out in another thread, I'm very much interested in development, coding, software engineering. But it's not an area I have any form of professionally applicable knowledge in. My stackoverflow'd Python-scripts are an abomination. I'm a disgrace to the "Dev"-part. A friend of mine is an amazing developer, his solutions to software-related problems are elegant, efficient and way out of my league. The moment he tries to build a fail-safe system I'm crying tears of agony because he has no idea what he's doing.
Both of us would be considered "DevOps", both of us would, if it weren't for the company being a good one and assigning us responsibilities according to our area of expertise, would end up doing the exact same job, neither of us actually qualified for it. That's what "DevOps" tends to do, force people into roles they are neither comfortable with nor equipped for. On both "word-sides".
On top of the structural problems that come with "DevOps", I have some technical grievances with it as well. I'm aware that this is a personal, quite subjective opinion.
To make things simpler and easier to maintain, we added more and more abstraction layers. That, in turn, made everything more complicated in the long run. To deal with dependency hell, we created container. To manage containers, we created container-orchestration platforms. To manage those we created appropriate management tools. So instead of one source of potential problems, I now have four. Not exactly simpler.
My grievances for the problems with the modern tech stack (and the environmental problems surrounding it) would be big and lengthy enough for a dedicated, separate post & I don't want to make my comment any longer than it already is. The point I'm trying to make is that we, often, ended up overengineering the solutions to problems that could have been solved much, much easier.
Don't get me wrong, I'm very much for furthering developments and growth with regards to how we approach technological challenges. I dislike "DevOps" because I feel that we took more than a few very, very wrong turn somewhere along the road to today. That's why I dislike "DevOps" as it is today.