The role of DevOps in IT - expert opinions


    Image of the site tricentis.com

    Existing realities literally require software development to further reduce project execution time: from the emergence of an idea to the release of a finished product. With an enviable frequency, customers are asked to implement the project “yesterday” so that someone else does not copy it “today”. And, of course, the budget to do the impossible, as always, is limited.

    The developers have no choice but to again and again engage in process optimization, experiment, try new methodologies. In especially “neglected” cases, temporary reserves are searched in literally every department, and not only force developers to print faster.

    It turns out that testers, managers, and analysts, and the implementation department can work faster. All that remains is to figure out how to achieve this.

    The methodologies of flexible and rapid, and sometimes extreme, development come to the rescue. This really allows you to partially solve this problem.


    Image of quora.com

    The Agile model provides for the fruitful interaction of development and testing departments in accordance with common goals, general rules and general performance criteria.
    Agile went public in 2001.
    Agile development comes down to a series of short cycles called iterations, which usually last two to three weeks. Each iteration by itself looks like a software project in miniature and includes all the tasks necessary to produce a mini-gain in functionality: planning, requirements analysis, design, programming, testing and documentation. At the end of each iteration, the team reevaluates the development priorities.

    It is understood that a “flexible” software project is ready for release at the end of each iteration. However, in practice this does not always happen and not as fast as customers now want.

    In addition, development is slowed down due to the fact that the various departments involved in the creation of software do not have common tools and there is no opportunity to share the knowledge gained.

    Each of the units performsown tasks and uses different criteria for evaluating the effectiveness of his work. For developers, this is the speed of writing and the number of functions implemented in the program code, for testers, the number of errors detected, for the operation department, the stability of the systems and the minimum number of incidents. Such a model of work often leads to a conflict of interests: the first ones try to write code as quickly as possible and submit it for verification, the second ones are ready to check and test for as long as possible to identify all the bugs, and the third one hardly accepts the code, since any changes entail potential risks to the entire IT infrastructure.

    It also turned out that the operations department is another weak link that remains “beyond the scope” of the Agile model.



    In 2009, the creators of DevOps inspired the general public with hope for a brighter future.

    This is how the noble goals of DevOps are formulated:
    DevOps (development and operations) is a software development methodology aimed at actively interacting and integrating development specialists and information technology service specialists. It is based on the idea of ​​the close interdependence of software development and operation, and is aimed at helping organizations quickly create and update software products and services.

    It is worth noting that Agile is not a prerequisite for the implementation of DevOps.

    Clyde Logue, the founder of StreamStep, puts it this way: “Agile played an important role in developing to restore confidence in the business, but he inadvertently left IT Operations behind. DevOps is a way to restore trust in the entire IT organization as a whole. ”

    The DevOps Cookbook and The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win describe the underlying principles by which all DevOps patterns can be obtained using the Three Way approach:
    The First Way emphasizes the performance of the entire system as a whole, as opposed to the performance of an individual link or department.

    The focus is on all the value stream business flows that are included in IT.

    The second way is to create a feedback loop going from right to left. The goal of almost any process improvement initiative is to reduce and strengthen feedback so that necessary amendments can be implemented continuously.

    The third way is to create a culture that affects two things: constant experimentation, which requires taking risks and learning from successes and failures, and understanding that repetition and practice are prerequisites for mastery.

    According to many customers, the value of the described approach lies in the fact that it allows you to get a complete picture of the development model - with the participation of absolutely all interested parties, with clearly defined processes and integration mechanisms.

    We asked experts to answer a few questions to find out how things are going with DevOps in the Russian-speaking world.



    Evgeny Ogloblin, DevOps companies from the largest Russian three:

    1. Which companies are suitable for DevOps?

    It seems to me that enough by anyone. Large - because it will accelerate the development, testing and releases of products, small - because everyone will be involved in the process, there will be some kind of interchangeability of employees.

    2. How deep is the understanding of DevOps in the Russian-speaking community?

    We still have a lot of "classic admins" who are not interested in the product at all. They have FreeBSD 8 or CentOS 5, everything works and does not ask for food. Hence, nothing needs to be invented.

    Plus, the automation associated with DevOps means a lot of work, often with new technologies, sometimes not even known to people.

    To my mind, no one has been able to explain what DevOps is so far - any company has its own subtleties, legacy and the like. In the general case, everyone agrees that this is automation, standardization and a more active participation of the operations department in development, but there are not so many of these “all” if you count as a percentage of the total number of IT people.

    3. What are the benefits of DevOps?

    In the event of successful implementation of DevOps, companies in the future can count on:

    • automation (reducing the risks of human error)
    • accelerate and simplify development and release processes
    • receiving quick feedback from users (metrics, monitoring)
    • PROFIT !!!

    4. What are the disadvantages of DevOps?

    A lot of work needs to be done.

    We must not forget about the current best practices of previous generations - it’s easy to do this in a sea of ​​new technologies.

    For various reasons, DevOps may not be suitable for a team trying to implement a subject.

    DevOps is not a silver bullet (but a pity).

    5. How widespread is DevOps in the CIS / Russia?

    In the leading companies in the IT market, it has spread widely. Although, as usual, there are exceptions. But living companies are increasingly realizing the need for modern methodologies.


    Evgeny Potapov, CEO of ITSumma:

    1 Which companies are suitable for DevOps?

    There are several meanings of the term, several layers of understanding what DevOps is.

    If we are talking about a culture of interaction between development and operation, where programmers understand how systems work and have system administration skills, and administrators understand the principles of development, then this is undoubtedly necessary for any company, since such close contact ensures ease of interaction and speed of solving problems that often lie on the border of these areas.

    If we are talking about a set of specific practices related to virtualization, containerization, automation of infrastructure management, then the most important thing is that the company (and most importantly the project itself) must reach a size at which the overhead for organizing these practices will be lower than overhead of managing infrastructure without them.

    2 How deep is the understanding of DevOps in the Russian-speaking community?

    In our 21st century, the differences between communities in different countries are not as strong as you might think. Yes, we are somewhat behind the time when new technologies began to be used, compared, first of all, with the companies of the Valley, but this is a matter of months, not years.

    3 What are the benefits of DevOps?

    Simplification of communication between specialists leads to faster interaction.

    The classic problem disappears, where programmers blame the server for everything, and administrators answer that the code creates the problem.

    Both the creation of new functionality and the resolution of old problems are accelerated.

    Automation, however, eliminates the eternal routine and chaos in IT projects.

    4 What are the disadvantages of DevOps?

    The main problem that we are now seeing is not so much connected with the DevOps methodology itself as with increased attention and hype around any new technology or practice, when they are applied not out of necessity, but out of interest in the technology itself.

    Often the overhead costs of implementing and supporting automation practices are such that they do not even accelerate, but slow down, the processes within the company.

    Yes - being able to frequently update the project code is really important, but how often does a small project need to be able to upload code daily, dozens of times a day?

    At the same time, the human and monetary costs of maintaining this opportunity are quite large.

    5 How widespread has DevOps been in the CIS / Russia?

    There are developed communities of DevOps specialists, meetings are held, excellent books are published:



    The authors of DevOps Cookbook and The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win highlight the following business benefits of DevOps:


    • quick market entry (shorter cycle times and faster deployment);
    • quality improvement (increased availability, fewer crashes, and so on);
    • increase in organizational effectiveness (more time is spent on activities related to increasing the value of the product and the amount of functionality).

    PS
    Perhaps the next step in optimizing team development will be the introduction of telepathic communication between employees of all departments and even with customers.

    Also popular now: