Get the fundamentals of DevOps right — then worry about tools
Today DevOps is the key trend in modern software development. However, even specialists frequently do not have a full understanding of what is hidden behind this term. Most often, DevOps is understood as the methodology of software development and operation, the fundamental idea of which is focusing on communication, cooperation, and integration between development and operational teams, but DevOps is primarily culture and only then practical activity.
Definition of DevOps
DevOps (Development and Operations) is a package of practices aimed at the interaction between development and technical support specialists. DevOps, based on the close interdependence of software development and operation, targets at helping companies to quickly create and update software services.
With DevOps techniques, the process of product development and optimization is faster than with traditional software and infrastructure management processes. Thanks to this speed, companies can improve customer service and operate more effectively in the industry.
How to implement DevOps?
To ensure that DevOps practices will not turn into useless rituals, a proper cultural context is a must. That means that DevOps does not begin with the introduction of tools, but is mostly related to the development of corporate culture and improving team communication.
The DevOps philosophy does not say what exactly needs to be done in a particular case but merely suggests accepting new values and ignoring the old approaches. Implementing DevOps can be a hard process for the company if it doesn’t pay attention to the necessary details and doesn’t make a good preparation for its departments. There are a few essential tips for companies to consider when deploying DevOps.
- Improving communication
All team members should have a good idea of how specialists of other teams work. Programmers should see how system administrators will deploy and operate the application and vice versa, engineers should transmit information to developers about how the application works in a production environment. This will help to create empathy between workers and significantly improve the climate in the company.
- Encouraging horizontal movement of employees between teams
Excellent practice in the work with DevOps is having permanent representatives of the development structure in a team of engineers or vice versa. The company should constantly search and record practices that improve communication between departments.
- Lifelong learning
The useful part of training is a constructive analysis of problem situations. It is very beneficial to establish a tradition of periodic meetings at which each member of the team could voice and discuss their problems without fear of public sanctions. Any failure or problem should lead to an open, friendly discussion and become a source of improvement in teamwork. A failure in the system should be seen as an opportunity to improve the process, and not as a reason to punish someone. When employees perceive failures as opportunities for improvement, they will take more responsibility, reasonably take risks, and constantly improve the system. It is important to create a space where employees can feel open and exchange experiences and ideas. This way of learning, incidentally, is well implemented when there are informal ways of disseminating knowledge.
- Tools introduction
Cultural development involves constant experimentation with new tools. For example, a developer can learn a new language or framework, even if at the moment the company doesn’t need it. Here understanding the fundamental foundations of software development is much more important than having extensive experience in assembling systems from third-party developers. DevOps tools for continuous integration and configuration management must automate the most problematic and important business operations. Engineer and developer specialists should be given a variety of options for choosing tools by themselves, and that will increase their involvement and will help them to take more responsibility. The task of the leader is to provide these resources in order to achieve the quantitative and qualitative criteria of DevOps.
- Improving the monitoring system
The feedback on a monitoring system is the basis for improving key indicators of stability and productivity. The company should periodically check whether the data that is required is actually being collected and if it is used for its intended purpose.
It is impossible to move towards a goal if the company cannot test progress. For evaluating the success of the implementation of the DevOps culture and the efficiency of the IT systems operation, the focus of the company should be aimed at the quantitative and qualitative criteria of DevOps.
Quantitative criteria in DevOps include numerical indicators of performing processes in IT departments and the stability of systems. Qualitative criteria are the prevalence of certain practices in the work of the teams. DevOps criteria for evaluating the implementation are:
- Deployment frequency
Practices such as continuous integration, configuration management, and automatized testing allow companies to make frequent releases, and consequently receive feedback from users quickly. The business can instantly make changes and test marketing hypotheses immediately after the idea appears. Because of continuous integration, information flows are accelerated within the company and IT teams receive information about failures and errors in advance. If the company can make a release several times a day, while reducing the number of errors, then most likely it is on the right track to deploy DevOps.
- Lead time for changes
How much time should it take to implement a business idea and release it as a product change? How much does it cost to implement the changes that one line of code describes? DevOps practices help to minimize the time to implement new features, making changes cheap, and therefore fast and frequent.
- The mean-time to recover
Practice shows that the number of failures does not reflect the real reliability of systems as failures have always been and will always occur when changing processes. More important here is how these failures affect business performance. According to studies, when a failure happens in the system, 80% of the recovery time is spent on identifying the change that led to the failure, and only 20% is on its actual elimination. DevOps suggests reducing recovery time by speeding up the search for problematic changes. For DevOps, it’s important not to rule out crashes, but to minimize their impact. That is why it is important to measure and record the recovery time after a failure.
- Change fail rate
Thanks to an increase in the frequency of releases and an overall improvement in control over the system, DevOps can significantly increase the share of successful changes by reducing the proportion of releases with errors that lead to crashes. High-performance indicators can be achieved in different ways. DevOps supporters have summarized practices that allow the company to effectively achieve quantitative criteria and have identified quality criteria that give the opportunity to test the performance of the company.
Versioning allows the company to get a single source of information about changes so it is quickly and accurately determine the cause of a problem and roll back to a stable state of the system in case of incidents after making changes. With the help of a version control system, code management has become commonplace. That means that versioning also contributes to the development of collaboration between teams as internal change control.
Studying the experience of leading companies showed that productivity noticeably suffers if the request for change requires external coordination because any external expert assessment is more expensive than internal control (peer review). Obviously, if the quality control of the code (and the infrastructure for DevOps is also the code) takes place in the team, then the performance will increase. Researchers have noticed that external control not only reduces the productivity of processes but also taints the number of failures (change fail rate) and does not affect the time to recover from a failure at all. However, effective internal control is not possible without an appropriate corporate culture, mutual respect, and trust.
- Proactive monitoring
Teams using proactive monitoring can identify problems earlier, which increases employee responsibility. Obviously, when a developer learns about failures from customers or users, both productivity and stability will suffer.
- The corporate culture of trust
High IT processes and overall company performance cannot be achieved without trust between team members. A corporate culture of trust is the basis of the productivity, while bureaucratic (based on rules and regulations) or power (based on fear and submission) adversely affects the performance of the company as a whole.
The confrontation between developers and system engineers, which is a consequence of differing psychological attitudes, leads to a decrease in the productivity of IT processes. And vice versa, close cooperation between different divisions, based on common values, leads to an improvement in quantitative performance indicators and positively affects the overall performance of the company.
DevOps allows the company to find the answer to the question of how to transfer the core values of the company from business to IT and vice versa. The keyword here is communication. There are a lot of communications, where the initiator should be the DevOps engineer. Because DevOps is a first of all a philosophy, and only then engineering knowledge. If the organization accepts the idea that it is a culture and communication that underlies DevOps and precedes all practices and tools, then it will be clear how to implement DevOps in a particular company.