When will DevOps Die? Part 1
Some are born to Sweet Delight, Some are born to Endless Night!
“Ideas are to objects as constellations are to stars”
― Walter Benjamin
Background
In 1999 I was working for a large company in Israel. One day our esteemed Unix system administrator told me that very soon NT 4 will replace all the expensive Solaris systems he used to maintain for developers.
Fast forward to 2019, and I am not sure if Microsoft is so dominant in our field anymore. Solaris machines are hard to find outside certain fields, but Linux is everywhere; in routers, mobile devices and servers we still use the POSIX or Unix way to control them.
I haven’t seen that guy for 20 years and I don’t know what he is doing nowadays but with a tweak or two, his skills are still in demand.
In more than 20 years in the field, I have seen many companies, technologies and professions come and go. Software development and IT is a very dynamic field, Blink for a moment and you will find your self nonrelevant. Take a wrong career move, and suddenly your possibilities will become limited.
In the following series of articles, I will try to define and see if DevOps as practice makes sense, and does it have a future or even present. Mind you, I am a melancholic guy, so bear that in mind when you read my post.
Let’s start with the quote “Ideas are to objects as constellations are to stars”. It’s taken from Walter Benjamin’s book “The Origin of German Tragic Drama”. It means, that when you look at a group of stars in the sky, you see a pattern which is a constellation. Same goes to any historical or cultural research, one sees patterns of objects and from them, ideas rise.
Who is Walter Benjamin you might ask? A German Jewish philosopher, cultural critic, and essayist. An eclectic thinker, combining elements of German idealism, Romanticism, Marxism, and Jewish mysticism. He was also one of the first western thinkers who understood the power of technology in our modern world. He saw the changes that radio and cinema brought to our society, and I think its always thought-provoking to use his ideas against a cultural phenomenon. He was a Berliner, and since I am now living in Berlin, I think it’s a nice Closure.
So what is the constellation I that see?
One constellation that troubles me a lot, is the fact that everyone around me is looking for a DevOps engineer! But why should it bother me? Why shouldn't I be happy that my profession is in rising demand? The reason is that life taught me different, whenever my profession was in huge demand, a decline happened.
I always listen to the market and what it can offer me. In 2015 I started getting more and more job offers for a new role; DevOps engineer. The relation to that and my older job title “quality assurance engineer” was around 60% to 40%. In 2019 the relations have changed, as about 95% of all the offers I get are for DevOps engineer job. Furthermore, salaries and demand are surging; I get too many offers! Check this site for information about salaries rise.
Too many offers? how can that be a problem? one should rejoice when his line of work in need. Well from my experience, everything that is reaching such a peak is destined to become obsolete. It happened to other jobs I had, like Windows system administrator, or QA engineer for manual testing, It always happens just when the trend is reaching the mainstream.
Let’s define two terms first; one is avant-garde and it represents some new and experimental ideas. The second one is mainstream, it represents the opposite of avant-garde, a general common view that a majority agrees on. Normally ideas start with the avant-garde, which is by nature a small group of people, driven by a similar idea or ideology and then slowly move into the mainstream.
Right now, we see DevOps is moving fast into the mainstream. How do I know? When I go to a meetup and I see older non-technological companies looking for SREs (Site Reliability Engineers) and DevOps Engineers (not one, but enough for full platoon), I know we have reached a peak. It can take some time, but there will be a decline in demand.
Another question we need to ask ourselves is, are those companies really ready to work in a DevOps environment? Are they willing to make a shift? Can a company hire a group of engineers, ask them to automate their infrastructure and release pipelines, and expect the DevOps genie to make the magic?
This rise in salaries and demand for DevOps engineers in the EU can hint on a welcomed change, I see this as a good sign, as it means our field is changing and evolving. Culture is becoming an important aspect of IT and software delivery, and we start to question our old methods and learn new ones!
The interest in DevOps from 2012 to 2019
The interest in DevOps Engineer
Many of us remember jobs and technologies that disappeared (for example Flash and Solaris OS to name a few). We need to understand that everything we are using now will disappear in a couple of years, yes even Kubernetes. But let’s agree on something, not everything disappears — some things stay in the legacy (or enterprise) world and before things disappear completely, they move from the avant-garde to the hands of the mainstream.
We still have many people using tools that are forgotten and considered unsexy, especially in some older, more traditional companies and in the public sector. Not everyone needs the new bling and cool stickers on his laptop, but we need to bear that in mind.
Wait you say, can you please explain and define what is DevOps? And what is a DevOps Engineer? Is he/she a developer or an operations guy?
What is DevOps?
DevOps is a loose set of practices, guidelines, and culture designed to break down silos in IT development, operations, networking, and security. Sharing and collaboration are at the forefront of this movement. In a DevOps approach, you improve something (often by automating it), measure the results, and share those results with colleagues so the whole organization can improve.
A long time ago software was released in very long intervals, in a slow, pricey and inefficient process that resulted in disputes between operation teams and developers.
Later when agile methodologies arrived with some “new” technologies like microservers, virtualization, and infrastructure as code, we found out we can release software much faster. We discovered that when we automate things in the right way, there is less room for mistakes.
Since the landscape of the software industry has changed so much, we acknowledged that we need to change the way we design, create, test, deliver and maintain software nowadays. We also understand that the change is first a cultural change, and then a technological one.
We can deliver fast iterations of software versions, and we can’t think about our servers as unique and expensive hardware but more as a dispensable piece of code. Suddenly a new creature presented itself in the world of software development, The DevOps Engineer.
The DevOps Engineer
We agreed that DevOps is a cultural shift backed by changes in technology. I would like to go further into the rabbit hole and ask, who is this creature that we call DevOps Engineer?
Furthermore, how can you engineer a cultural change? if we want to break the barriers between departments with DevOps, wouldn’t it make more sense to spread them in other development teams? Would it make more sense to invite a group of DevOps experts, and empower, (yes empower!) the developers to take care of their own code?
Ask yourself, as a DevOps Engineer, did you actually work in a DevOps environment? Or are you still being part of an operations team that is only labeled as DevOps team? Do you take part in the development scrum sprint? Do you feel that you, as a DevOps engineer, share the responsibilities with the development teams?
Maybe the truth is somewhere in the middle? Some operations people are getting better at automating and writing code? Maybe some developer teams are getting better in infrastructure and operation? If you look at things from that perspective, it seems that we might be doing many mistakes, but our field is slowly getting more mature and unified!
This is true for the DevOps Engineer, but not for an SRE or a DevOps consultant. I think that the “Site Reliability Engineer” is a valid practice, and it’s a result of the cultural shift that the DevOps movement brought to the world of IT. It’s one of the options that many current DevOps engineers might follow later.
Furthermore, the role of DevOps consultant makes much more sense, since he is an external expert who is brought to mentor developers in the ways of DevOps. He can also build and fix specific things that trouble developers in their infrastructure, but he can be external, and save the company money in the long run. One of the reasons I actually took an offer to be a DevOps consultant was this rationale, for me, this is a valid role.
So we are back to our question; what is a DevOps engineer? Is he a developer or is he an operations guy? Honestly, I can say that from my own experience and perspective most of the time he is still working as a classic system administrator using some new tools, getting code thrown over the fence at him from developers (just in smaller chunks and faster), he still needs to ssh to the machines at night and built proper monitoring for the production, I mean Devs would not do that right?
The DevOps Dilemma
We as DevOps Engineers allow developers to take responsibility for their own code. This means that when we are good at our job, we might actually find ourselves without one. As I see it, DevOps is a cannibalistic profession, our goal is to achieve a NoOps or the developer-oriented environment.
But wait, should we go deep into the existential crisis of our profession? Definitely not! The current situation allows us as DevOps engineers to learn and understand software in better ways. The only thing we need is to keep an open mind, get better in coding and people skills (which is part of our job description as DevOps Engineers anyway). DevSecOps is a practice that I believe will grow in demand soon.
Take me as an example; I started as a network administrator in the 90s, moved to be an MS Windows system administrator and support engineer for some time. In 2005 I decided to put all my effort in the Unix world, and I started a new path in my life, quality assurance engineer and integration specialist. Now I am a DevOps consultant, and I know for sure this is not the last path I am taking in my long career.
So what's next?
In the upcoming articles, I would introduce currents in Infrastructure world, I would present the changes that Kubernetes, Serverless, and the new cloud functionalities are bringing to our field. After that, I would argue that we are moving slowly into a developer-centric approach and examine what does that mean for a DevOps engineer.
