Walking around in some companies, I’ve seen a lot being talked about DevOps. Even people who had no idea what it was, more often than I would like. For this fact – people don’t know what it is exactly – the concept eventually became confused and sometimes distorted.
Thinking about it after seeing here what DevOps is in fact, we now list a number of things that DevOps is not. Of course there is no academic literature that conceptualizes and defines accurately (not that I know), so the following are just based on my experience and my studies.
Of course, These ideas can and should be questioned. Actually, I’m waiting of it. Let’s see the list:
It’ not a job position
I intentionally put this item at first, because it is what bothers me more when I see. DevOps came, people recognized its benefits, perceived their need, but did not know how to ask for it.
Many misleading definitions have emerged and with it emerges a lot of job positions for DevOps analysts and engineers. If neither the people directly involved with IT clearly understand what Devops is, imagine HR analysts that in most companies do not receive good definitions and explanations necessary for the opening of new positions.
If there was a job position of “DevOps engineer”, the requirements for it easily occupy about 10 pages! In this job, the person should have skills, knowledge and experience of the entire life cycle of a software! Definitely DevOps is not a new kind of job position.
It’s not a stage in the application life cycle
Some people think that the DevOps begins on continuous integration and ends the operation. This is a very simplistic view of what it is and what we can get with DevOps.
An example: good software requirements (specified before the development starts) will cause a better understood, developed, tested, integrated, delivered, managed and fixes software. Again we are talking about the entire software life cycle.
Not involves only developers and operators
One thing causes the other. As explained in the previous section, all the people involved with the software can practice DevOps.
And when I speak “all the people”, I am including managers, directors and CIO. The idea must be purchased by all! Mainly by sponsors! It is very easy to distort the DevOps, not testing all the features, or not using proper tools in production. It is up to the team leaders, managers, etc. support and also demand that culture persists!
It is not easy adoption
Absolutely not! Devops involves break of paradigms. Change in model thinking. New processes. New attitude toward to the tasks of other team members.
Of course you can adopt DevOps in one thing or another. In a specific stage of development or even only on the team operation process. But a full and really effective adoption will affect the way people work. And there will certainly be resistance from those who do not like of changes and get out of your own comfort zone.
It is not the fusion of two teams of the IT
Devops is not a new business sector. It don’t put developers to take care of the operation. And don’t put system administrators to create source code.
People stay with their jobs. Just how to do their tasks, how to think about the software that changes. Devops does not eliminate the need for operation and much less for developers.
What happens in many cases is the opposite: the emergence of job positions of release managers, continuous integration engineers, etc.
Devops is not for free
You can’t think you will get DevOps without investment. It requires tools, investment of time in the development of new processes and investment in training. You need people with good knowledge. Any attempt to change without planning and budget duly approved by who pay the bills, it’s nothing but dream.
Devops reduces costs, and improves agility, reduces development and lead time, improves product quality, reduces rework, increase assertiveness. But to have it all, you have to spend some money first and be willing to put some people in the cause
This is not only fast deliveries
From what we read and hear out there (especially the Internet), we can easily find that DevOps is just about continuous integration, continuous delivery, releases in rapid cycles. But is not just that. In fact, we can have DevOps being practiced without even have daily or even weekly deliveries, although this is one of the greatest achievements of this culture.
Many companies do not support such rapid iterations in practice – I would say most of the companies do not support. Someones there are bureaucratic processes beyond the IT scope. Often there are also legal restrictions. Some software have limitations of the business about the frequency that it can be changed.
But even with this restrictions, we can still have software configuration management, continuous integration, participation of the operation in the development, specification of nonfunctional requirements appropriate to the operation and continuous and efficient monitoring.
More important than know exactly what DevOps is or is not, it is to understand the concept and what benefit it brings, what we can achieve, where we can use it to accelerate the development and what tools use to ensure a stable operation with easy recovery.