Is DevOps in an identity crisis? [Interview]

Source:-gotechdaily.com

The definition of DevOps is controversial among hobbyists and experienced engineers alike. Ironically, DevOps should actually bring order to the chaotic environment of IT software development.

In DevOps Paradox, DevOps expert Viktor Farcic talks to other industry colleagues who reveal their perspectives on the trend and what it means to them. In this article, you’ll learn what some prominent members of the DevOps community are saying about DevOps. The quotes in this article come straight from the book.

How should we integrate DevOps into our organizations when we don’t even know what it is? Let’s hear Viktor’s thoughts on what DevOps is and what trends and future aspects are:

What is DevOps and why do we need it?

What is DevOps and why do we need it? What is the most important thing that DevOps helps us? What factors are driving DevOps development?

Viktor Farcic: Almost everyone gives a different answer to the question “What is DevOps?” – there is a big discrepancy between the idea and the implementation. In my opinion, the main goal of DevOps is to enable self-sufficient, product-oriented teams that are able to take complete control of their products. This is in stark contrast to the way many companies work today.

Typically, an application lifecycle is split across multiple teams. Business analysts define requirements, architects work on guidelines and frameworks, developers write code, testers are responsible for validation, operators provide new releases, and so on. The problem is that each of these groups belongs to different departments and has different and often opposing goals. Instead of focusing the collaboration on a common goal, different teams (departments) look for their own short-sighted interests. DevOps tries to remove the organization based on the type of tasks performed and to combine all of the expertise required for the entire life cycle of an application in a single team that reports to a single person. It forces us to work together and builds empathy.

Is DevOps a process? Or a number of technologies? How do you assess this area of ​​your debate?

Viktor: DevOps is neither. In contrast to some agile frameworks (e.g. Scrum), no prescribed process has to be followed. Likewise, there is no technology that we can adapt to transform ourselves into “DevOps” teams. It’s just an idea that developers, operators and everyone else have to work together instead of being isolated in different silos. That doesn’t mean that technology is not important. it is, but often for reasons other than obvious.

Every new technology is developed by a group of people who have worked together in the development. As such, it always reflects the processes of those who are involved. On the other hand, these processes are a result of the culture of the people who follow it. In other words, every technology is the result of certain processes that emerge from the culture of the team that worked on it. Although we use an end result, it is a product of a process created in a particular culture. If we use technology that does not fit our own processes and culture, the best results will be sub-optimal. So we have to either use technologies that fit our processes and culture, or use them to change them. You can’t work without the other.

All in all, DevOps is an idea, not much more. It is up to us to find out which processes and technologies help us to achieve this.

What does a DevOps engineer do? Is it a real job role at all?
What are the core tasks of DevOps Engineers in terms of development and infrastructure?

Viktor: I don’t think there is such a thing as a “DevOps Engineer”. The term was invented by people who were unwilling to apply the changes that DevOps is leading to. Most of the time, a “DevOps Engineer” is just another name for someone who works in shared services, operations, infrastructures or in the department that was first renamed DevOps.

Do you think DevOps is experiencing an identity crisis?

Viktor: DevOps was never defined as a process. For example, Agile has some implementations that tell people what to do. Among other things, we have Scrum, which clearly defines what needs to be done. We could even argue that Scrum violates the spirit of Agile as a set of practices to be followed, but this is a conversation for a different time.

What matters is that no one has defined the process behind DevOps. There are no steps that need to be followed daily or weekly. It’s just an idea that we should work together and not throw things over the walls of the department. The way there is therefore open to interpretation. Therefore, DevOps never had a clear identity, so there can be no identity crisis. It’s just an idea, and it’s up to each of us to figure out how to make it happen.

The biggest challenges in DevOps today

What are the biggest challenges at DevOps right now?

Viktor: DevOps is currently mostly misunderstood. Most of the time, companies simply rename a department. In some companies, shared services become DevOps teams. In other cases, it is infrastructure, operations, or another department. It’s like a race and the first division that changed its name to “DevOps” was a winner. Changing the name logically means nothing and does not lead to any noticeable improvement.

The main challenges relate to people and culture. DevOps is not easy because it questions the current organizational structure, restructures the power within an organization and questions the need for many departments to exist. Therefore, middle management is often against it because it is perceived as a risk to their position. At the same time, people who have spent many years doing the same thing again and again feel their credibility jeopardized if the structure that has enabled them to climb the career ladder is removed.

Congratulations on the release of DevOps Paradox. Could you talk a little bit about the idea behind it and what you hope to achieve?

Viktor: I attended a lot of conferences and found that planned talks are not the main reason. I learned what I heard, but the main reason I continue to attend is “corridor talks”. Conferences are a great opportunity for me to find interesting people and to have great discussions. In contrast to planned talks, these talks are not structured. I am not preparing a list of questions for the next person I will meet between conversations or at a party. Instead, we would only be talking about a random thing that happens to be interesting.

I wanted to bring these kinds of conversations to people who can’t travel around the world and who can be moths in a different conference in a different country. So I had no real goals for this book other than talking to people about any subject as long as it was DevOps related. Since DevOps can be anything that has to do with software development, one can say that the scope of the book is as broad as possible. My real goal was to have conversations with people. I have not prepared any questions in advance. Instead, I only brought people together that I would like to speak to when I met them at a conference. Some of the people I interviewed are my friends, others I met for the first time. Some work for large companies, others for startups. Some have worked in the software industry for many years, others are young, up-and-coming experts. I wanted to make sure that the book contained as many different opinions as possible.