Friends, in conjunction with the DevOps Basics – October 2017 Practical Course, which started in a few days’ time, we have prepared an interesting reading in which we answer the two questions – what is and what is not DevOps.
What is DevOps ?
DevOps (a shortened combination of “Development” and “Operations” – the two main types of activities in the production and maintenance of a product or system) is a flexible methodology and practice that aims to unify software development and software operations. The main feature of DevOps is to support the process of automation and compliance with every step in the software development process – from integration, testing and marketing to infrastructure management.
What is not DevOps ?
DevOps is not “NoOps”.
As I mentioned above, one of DevOps’s main goals is automation. However, the automation process is part of the development process. its deployment leads to a decrease in IT Operations-a. apparently DevOps “Dev” slowly but surely displaces “Ops”. This is true in part and partly not. What does that mean? If we metaphorically say that the process of developing a software product is a whole, composed of the two complementary parts “Development” and “Operations,” in the DevOps case, it is seen as an evil creation of the “Development” part by which the developers can take the functions of IT operators. The truth is that IT operators are increasingly leaning on DevOps because of its benefits as a flexible methodology. This is necessary because the principles, processes and practices around which the classical method of IT operations is built is not in a rhythm with what is needed for success. On the one hand, business (as a whole) and developers need more flexibility, as the business climate is becoming more dynamic, but on the other hand, people working in IT operations (such as system or network administrators) whose work is based more rigid principles, which slows down the entire maintenance process of a system, and so on. There is a discrepancy in the pace of the two main parts. To avoid this, IT operators realize that there is no way for some of the processes to be automated, either that operators need to start developing the necessary automation themselves, or that developers start writing a “operations” code, or both.
It is not (just) about tools
When we talk about implementing DevOps, it’s not just about implementing a set of tools. One of the erroneous beliefs about DevOps is that reliance on this methodology is to “overwhelm” the theory and proceed to the practical implementation of a set of tools, but without taking into account the principles around which this methodology is built, which in fact leads to the realization of a peculiar anti-model of DevOps. For example, a process of automation is just a power exercise, but unconscious automation can cause as much damage as thought can bring benefits.
It is not (just) culture
Many people claim that DevOps is just a culture, and the word (DevOps) can not be applied strictly to a principle or practice, but that is a misconception. Flexible methodologies have not helped thousands of Dev stores, stopping their “culture” development that exhorts you to embrace your colleagues at work, and DevOps is no exception.
It’s not (just) about “Devs” and “Ops”
As mentioned above, when we talk about DevOps, it’s possible to read or hear comments such as “What about system or network administrators?” or “Why are you throwing us away?”. The fact is that while the DevOps process leads to a mix of obligations to a certain extent, it certainly does not lead to exclusion of certain types of specialists. Even vice versa – all participants in the creation and maintenance of a product or system need to collaborate from the start – both developers and operators of different types, and even people who are engaged in business modeling, marketing, or direct sales.
There are different types of work and sides in development. Just because someone has not received a special invitation (for example, “Do not forget about icons designers!”) Does not mean they are not included. Generally, flexible methodologies focus on the biz + dev collaboration, while the DevOps focus on (logically) “dev + ops,” but the end result of DevOps is that everyone is cooperating. In this sense, DevOps is a big step forward in terms of the discipline being involved in the general culture of flexible methodologies, including all the different activities in an organization, rather than their separation or disposal from the production process.
It is not (just) a profession name
There are cases where an existing ops team gets the naming “The DevOps Team” (not just “DevOps Team” and “DevOps Team”, ie they refer to this group of people as a separate unit with separate assignments and specialization) . In other cases, someone may change the name of their specialty to “DevOps Engineer”. No. All this is wrong. The concept of DevOps is in the principles and the resulting reorganization of the production process of a product or system. That is, if you do not perceive and apply the principles of DevOps that require change at a common system level, not just inside a small group somewhere in that system, you will not get satisfactory results.
Of course, this does not mean that there are no people who are more or less specialized in applying DevOps. In this line of thought, it is not entirely unreasonable to place such “titles” in terms of distinguishing the specifics of DevOps thinking, the advantages of automation, the high degree of collaboration between all the units, and the DevOps characteristic of other flexible methodologies.
DevOps is not “everything”
We reach the other extreme. Sometimes people who are “inward” in DevOps make spectacular conclusions that DevOps is relevant to everything and everywhere. Because DevOps adds to the general structure of a product or system a fairly abstract and flexible thinking, and there is scope for such a type of collaboration in an organization, yet you can restructure an entire organization or business process is not DevOps on its own yours. Yes, DevOps can be a collaborative and flexible enterprise culture, but DevOps focuses primarily on how the Operations Unit is involved in the entire production process. There are people who come out of DevOps’ focus and turn it into a super-wired version of Lean, Agile or simply “let’s all be friends and love.” This is damaging as the downsizing down the hierarchy of the labor process will eventually end up with a huge amount of resources and resources for operational integration, while at the same time a large part of your staff resource will shift to other tasks rather than to specific problem.
Even then, there will be a number of unresolved issues around software delivery or service support, and above all about turning them into fast, reliable and protected or, in short, “competitive” products.
So if someone wants to apply their knowledge of DevOps to a wider organization level in their company – that’s good, but it has to be taken into account that DevOps is designed and includes mostly people dealing with the technical practice, looking for a way to improve the efficiency of their work, not a way to get someone else’s job done. In this line of thinking, flexible methodologies mainly refer to flexible software development, while at the same time there are methodologies that are more comprehensive and emphasize the application of flexibility to larger organizations and more directions of a software development workflow.
In conclusion, we can summarize that DevOps can best be described as “Flexible Software Delivery and Operations“.
If the DevOps theme seems to be interesting, hurry up and join the upcoming training “DevOps Basics – October 2017“, which starts in a few days of