What is DevOps all about?
The question “What is DevOps all about?” has been discussed for quite some time. How can DevOps be correctly defined and categorized if it changes constantly? In fact, if you look at a random LinkedIn Search, there are more functions being crammed into DevOps than any other roles right now.
The first years of DevOps had one truth to it: the entire DevOps movement was to break down silos between development, operations and everything else in-between to enhance software development and release processes.
But nowadays it has become more slow but steady the “new normal”. Typified by tools such as Jenkins and Puppet, the demands of companies for some degree of stability in their enormously complex systems have led to standardization, which makes companies think more about rationalizing their current application portfolio.
We see a lot of change, but the core technologies for build/test/deploy are taken care of in a few products by the same number of suppliers. That’s good news for adopting these ways of working, but some can argue it’s bad for innovation.
In my opinion, this means that skills become more or less portable within DevOps teams and organizations, which wasn’t happening for a long while. The more people who use one of the other, the better for the pool of available resources and employee mobility, treated both people and supporting tools such as standardized scripting.
I have gone through the IT portfolio portfolio of a service provider (not to mention by name ;-)) that does not traditionally make DevOps possible. The company’s offer included DevOps, including Jenkins, Jira, and XL Deploy, which made me happy. It meant that the company evolved to use mainstream tools for a specialized market.
It has been a long time since these devices were considered “uncertain”; Now, for a service provider to include them as proof that the series is beyond the problems of customers, it just shows how far we have come.
But to mention: there is still a long way to go. The user community is currently growing, and many DevOps tools are still incompatible with each other and are chosen per service or company without a clear market leader. But slowly we get there. The point is that, for many companies, while common standardization is ongoing, it is all new.
Now, with things like Serverless around the corner, we have to make more traction. Serverless has been gaining ground in recent years as an approach to infrastructure management. I recently had the opportunity to work with AWS Lambda and Azure Functions and have to say that I’m sold to the technology. I believe there will be a natural fusion of DevOps in Serverless. In Serverless, the promise of DevOps will really shine and thrive. I see a future in which DevOps will once again transform into a real primary role.
DevOps is a culture and is promoted as a process rather than a role. Unfortunately, the reality is not so idealistic that DevOps was turned into a function and description across the entire spectrum of companies.
The more things the community tries to cram into DevOps, the more responsibilities inevitably appear on job descriptions. While I enjoy being the jacks of all trades, I feel that we are setting many current and aspiring DevOps practitioners up for failure. At this point, someone who goes to DevOps and asks me what they need to know actually gets an answer from “Learn coding in X, Y, Z” instead of “You have to learn X, but get some from X.1, X.2, and some A too, and while you’re busy, there’s Y … “
So if you don’t know the mentioned tools yet, don’t worry; there will be an opportunity to learn while they are being rolled out within a organization.
