Well that survey is out, and I have to say, it is interesting. There will always be a continual change in the definition of “Devops” to an organisation. I will not go through the whole document, but I shall summarise what I think about the points in the executive summary;

This is the survey document link

“Devops” has become a term synonymous to tech at all levels. Everyone speaks the lingo, and buzzwords; to garner attention and also the brightest technicians in the market. Given so, doing “Devops” is like being in the English Premier League; are you the next company out there to buy the best engineers the market can offer and entice them about doing “Devops”?

There are still obstacles of course. From the document, it says “lack of skills”, “legacy infrastructure” and “adjusting corporate culture”. I can probably break it down from my own experience dealing with all above.

I remember when I was switching roles from one space to another, my job title was “devops engineer”. As a “devops engineer”, I am meant to know about infrastructure, code, and distributed systems. Basically a “Jack of all trades”. Sometimes the expectation of being a “devops engineer” is that you are a sponge who can understand everything. In my honest opinion, this expectation will not change.

“Legacy Infrastructure”? Really?! What is legacy? To me it was what is built yesterday, supported through traditional operations and hard to change. I think “legacy” just means “yesterday and I don’t want to touch it anymore, please give me something brand new, and shiny to build”. The honest truth, you will never get a shiny new project and most of the times, you will inherit bad infrastructure, legacy infrastructure to build on, and manage. Use the principals of “Devops” there instead. No complaining.

Adjusting Corporate culture is a tough one. Ive been in many organisations and through many changes. For some companies, changing a culture meant buying, oops hiring “devops engineers”, and everything to do with “devops”. From human capital to toolsets; and sell the idea to the bosses. In my opinion, “devops” is a movement, and its about the small steps in huge organisations to show that it works. It can be a small effort that moves on to bigger things. You have to win the hearts and minds of your engineers so they can pass on small wins to their managers, then continually up the chain. Buying tools and engineers do not change a company, influence does. There is always a fear of job loss, when certain roles become irrelevant, but thats life. We need to evolve. I was a classic operations engineer once, I moved from there to being a SRE/Devops engineer. It was evolution through hard work.

Communication and collaboration is critical in “Devops”. Tools and Personnel make a small difference but communication drives this. Communication and collaboration is what drove the “Devops” movement. NOT a list of tools and team buyouts. How are you doing your “devops”?