With all the advantages of DevOps, this approach, which is especially popular now, to organizing software development and operation processes, is not without its drawbacks. Today we will talk about when it is better to do without devops and how to implement it if it is not very suitable, but you really want to. We will also tell you why DevOps is not a panacea and what problems await you after its implementation.
When devops is not needed
At first glance, it might seem that the barrier-free organization of the development and operation of applications is suitable for any IT company. However, this is not quite true. First of all, it is believed that small businesses and startups can do without DevOps, because testing, deployment and support of small projects can be performed manually, without using complex automation tools (as well as expensive specialists who know how to work with them).
In addition, sometimes it is not necessary to implement DevOps in a “heavy enterprise”, despite the fact that this approach was originally invented to solve the problems of the corporate IT world. In particular, for “monolithic” applications, when all program functions are implemented in a single structured space of interconnected files and packages, DevOps in its pure form is not needed. Despite the growing popularity of microservices architecture, not all software solutions support it. For example, many, especially long-existing, financial systems (in banks, processing services) are organized according to the “monolith” principle, which they are only now gradually beginning to “saw” into microservices. It is in this vein that they look closely at integrated DevOps concepts. Indeed, in the “monolith” updates are not so frequent and it is quite within the power of one specialist to cope with the release of several assemblies every 2-4 weeks, without involving complex automation tools. And if the system consists of many separate modules that are constantly updated with different regularities, an already automated solution will be required to deliver the finished product to work.
You should also remember about the organizational side of the issue: in the corporate world, there is a clear division of labor. Developers and operators have separate departments, bosses and salaries, tied to different performance metrics that are not tied to each other. Therefore, DevOps cannot be implemented until the activities are coordinated and business processes and financial funds are not built around a common result.
Finally, DevOps involves not only using new tools and redesigning processes, but also changing the corporate culture itself. If employees or management ignore the principles and values of the approach, it is not worth wasting time and resources trying to adapt it. In particular, the experience of Mango Telecom shows that, despite the support of Agile principles, it is not so easy to implement DevOps in a Scrum team, because employees cannot / do not want to be distracted by innovations when it is necessary to keep within the sprint. In addition, to automate the existing process, documentation is needed, the value of which is not very high in agile methodologies, and therefore its completeness and quality may not correspond to the required level of relevance.
Implementation success depends on the environment. How to implement DevOps if it doesn’t work, but you really want to Nevertheless, even heavyweight mastodons (banks, oil and gas industry, mechanical engineering, and other industries) are tempted by the benefits that Agile in general and DevOps in particular promise. Therefore, the question of implementation does not sound like “To be or not to be?”, But “How to do it well, quickly, simply and not too expensive?”
Like any idea, DevOps cannot be implemented in its pure form – in practice, every company tries to take the best from this approach, adapting it to its own specifics and gradually introducing it into use. For example, as did the “Center for Financial Technologies” – a domestic company with several offices distributed throughout the country, which develops software for the financial sector
The gradual introduction of devops can be reduced to the following steps:
Be clear about the tasks you want to accomplish with DevOps, such as ensuring that 100 workable builds are released daily, creating a deployment pipeline, and so on;
Discuss the solution with the team (developers, testers, administrators, technical support) to identify the most problematic areas in the processes and choose which automation tools should be implemented first of all.
Ensure employees understand and accept CALMS – the 5 core principles of DevOps: culture, automation, lean, measurement, and communication. Reorganize business processes and organization of teams around the product, rather than by functional division.
Automate the part of IT processes that is most needed and suitable for this, for example, testing or preparing environments on the server for a working solution. Define metrics to measure the success of automated processes.