DevOps is hot right now. It is the new (well, new-ish) cool kid on the block that every company wants and is willing to pay lots of money for.
It’s also a pet peeve of mine.
Not DevOps itself but the fact that the concept has been distorted to the point of being almost useless.
TL;DR: DevOps is a lot more than bringing in a “DevOps Engineer” who knows AWS, Ansible, Terraform, Docker and Kubernetes.
The old ways
A traditional IT organization has a development department and an operations department. Yes, reality is usually a little more complex than that but this is close enough to illustrate the problem. The development department is responsible for writing the software code. This code is then passed on to the operations department to be deployed to the client (a paying third-party or another internal organization), thus delivering the value proposed by the IT organization.
In other words, the people involved in the software development lifecycle are isolated in two distinct silos. This causes a big problem.
Many software engineers will recognize the “it works on my machine” scenario, where a piece of code someone wrote works perfectly on their computer but fails miserably once it is executed elsewhere. If the developers are nice people, they will try to help figure out where the issue lies. Otherwise, since it’s not their responsibility to run the code but only to write it, they can say it’s not their problem and move on with their life, leaving the operations team to fix their mess.
Meanwhile, the development team carries on, writing more code and, again, tossing it over the wall to the operations team. Sometimes the operations team still hasn’t finished fixing the previous problem and they’re already having to handle another set of changes.
The result is an organization that has frequent problems delivering their proposed value, one where people seem to work against instead of with each other, and one that ultimately may end up piling up unsolved problems that will eventually blow up in their face.
What most people nowadays call DevOps is actually just a mix of systems administration, infrastructure engineering.
When someone says they’re looking for a “DevOps Engineer”, they usually mean someone who knows:
- a little bit of systems administration, Linux, bash, etc;
- a little bit of GCP or AWS;
- how to set up a continuous integration pipeline with CircleCI, TravisCI, Jenkins or a similar tool;
- a little bit of Docker;
- Kubernetes just because it’s cool and everyone has to use it, right?
And that’s the gist of it.
This person will not write any application code, will work on a separate team isolated from the development team, and will probably be looked at as the weird guy who speaks “server”.
And this is where it starts to bother me.
The term “DevOps” comes from combining “Development” and “(IT) Operations”. DevOps is a set of practices meant to break down the barriers that traditionally existed between development and operations teams. This enables shorter development cycles while also pushing for high quality, providing continuous delivery of value to the customer.
Ironically, companies do the exact opposite. They hire someone for a “DevOps Engineer” role who ends up working alone, or at most, in a team with other “DevOps Engineers”. Instead of getting rid of the silos in which development and operations teams used to work and were the cause of the problem, they simply replace the names of the silos. In essence, they just replace the word “operations” with “devops”, completely negating the benefits that DevOps is supposed to bring, but they still feel great because they’re using the latest cool buzzwords.
This wrong notion of what DevOps is has spread to the point that most people I talk with, even some seasoned software engineers, have no idea that they’re missing the point. Unfortunately, by distorting the original meaning and concept, we lose the opportunity to reap the benefits of true DevOps.
To put it another way, most companies that recruit “Devops” people have yet to recognize the problems that DevOps proposes to solve. Thus, to put it bluntly, they’re just wasting money and adding more confusion to the mix because they don’t know what they’re doing.
DevOps is about a lot more than just hiring a “DevOps Engineer” who knows how to use the kind of tools I mentioned above.
Those tools are important but are not the most important thing. They solve specific development issues but the root cause of The key is a change in mentality.
They solve particular development issues but in reality, your organization may not be directly suffering from those issues, and the cause of your issues are manifested elsewhere.
It may not even be a problem
I’m not sure why this happened but I blame it on ignorance and the need to sound cool. At the risk of being unfair, I’d say most of the blame falls on recruiters. Recruiters want to sound cool to attract more talent. But the vast majority of recruiters don’t know the first thing about the roles they’re recruiting for. We’ve all seen the job ads that require more years of experience with a given technology than the technology actually has. Or ads that require the candidate to be a specialist in every technology under the sun. So they end up using words just because they sound cool and not because they represent what they’re looking for. Marketing departments are probably also to blame. If it sounds cool, they’ll use it for something - even if it’s something different than the original meaning.