In our earlier article, "The Role of DevOps in Digital Transformation", we delved into the essence and advantages of the DevOps approach. Its implementation in the organisation helps to speed up and increase the efficiency of the deployment process and improve the overall reliability of the deployment of new software products using an agile development process. Today, we'll explore potential pitfalls linked to integrating DevOps processes into the organisational structure and how to tackle these challenges. The fundamental aim of transitioning to the DevOps methodology is to streamline the entire process in the long run, mitigating additional costs tied to planning, organisation, and implementation.

A Strategic Plan is a Key

At the beginning of every successful change, a high-quality and well-thought-out strategic plan is essential. It is, therefore, necessary to determine its form and content, as well as appoint the implementation team. The strategic plan is then closely linked with project planning. Project planning is one of the key steps for successfully implementing DevOps in an organisation.

First, you need to define the expected results. For example, if we want to start with a smaller microservice application, we can perfectly debug the entire process on the first service, from code submission, through automatic tests, and deployment to monitoring of vital functions and notification of possible errors.

Once the entire process is described in detail, it is important to determine the time required for the entire activity, the deadline for submitting the final form, and the procedure for adding additional applications. This kind of planning helps to find recurring patterns in both deployment and testing, and thus allows you to create certain templates. Some of these templates can then be used repeatedly for automation using various tools.

Who is Who? Defined Team Roles Are a Must

An important part of the plan is also the description of individual roles in the team. During every implementation of such processes, there should be at least one person who really knows the given application, i.e., a representative of the developers. In the same way, a counterpart from the operative side, one who keeps the application alive in the production environment or takes care of its monitoring, should also be engaged. Last but not least, the team should also include someone who is responsible for the infrastructure so that the whole process goes smoothly and the delivery time is not extended while waiting for various technical bills and clearances. For the successful functioning of everything described above, it is necessary to have an agreement with the management of the organisation. Perhaps this remark may seem superfluous, but practice repeatedly shows otherwise. The management of the company must be very well acquainted with the procedures and functioning of the DevOps team and must provide cooperation and support to this team.

The DevOps Culture, Step by Step

How does a DevOps culture come to be in an organisation? It simply needs to be created based on several factors. These are time, project type, organisation size, team size and of course the budget. Here again we come back to the importance of the organisation's management and its role in implementing a DevOps culture. At the very beginning of the efforts to introduce DevOps procedures, it is most important to discuss with management what benefits this will bring for end users, development and support teams, for the company culture and, last but not least, for the results of the entire team. The arrangement of technical and personnel matters naturally follows only with the support of management, which needs to be convinced that it is doing the right thing. It is also necessary to discuss the financial and time aspects for the implementation of the processes, so that the newly created DevOps team has the space to work effectively and undisturbed.

Of course, before putting the newly created team to work, it is necessary to provide thorough training on DevOps methodology, or to hire a specialist who can help with this. It is a complex process and some implementation errors could hence be caught unnecessarily late. On the other hand, the team is expected to be able to learn new things and not return to the old ways.

Communication is Crucial

Although it may sound trivial, high-quality tools for communication should not be underestimated. The newly formed DevOps team must be able to communicate effectively both internally and with other parts of the entire organisation. Effective tools do not include email, as that is primarily used for more formal communication. Instead, tools such as Slack, MS Teams or Discord are excellent options for team communication. These platforms can be used by the DevOps team to automatically share errors and complications in the process with other members of the organisation. Recently, it has also become possible to use implemented chatbots, which can find out the status of their deployment within the communication tool, to determine the status of backends across test environments, and so on.

Automation

Mathematics incorporates the infinity symbol when dealing with ever-ending processes, and it's no coincidence that this symbol is also relevant in DevOps. Anything that repeats more than once should be automated, seamlessly becoming a part of ongoing processes. Where can we apply the automation process? Let's begin with infrastructure, for instance.

With Terraform templates, we can specify the amount and location of the computing power we require, identify the components to run, and define rules for the expansion or reduction of our infrastructure. This entire process can be automated, eliminating the need for manual commands from the operator. Instead, the infrastructure adapts itself once changes are applied to the document. Tools like GitLab or Azure DevOps are handy for making such modifications, though nowadays there are also numerous other options available.

The same approach can be used to deploy monitoring tools, documentation, or any other component from the DevOps toolkit. It might sound straightforward, but there are pitfalls to be mindful of. All automation demands ongoing maintenance to ensure resilience against future updates. To achieve robust automation, utilising templates is beneficial. The more the applications align with the programming language used, the fewer resources are required for expanding and maintaining the templates.

Better Safe than Sorry

Without well-established metrics, we're essentially operating in the dark, making it challenging to maintain, monitor, or enhance anything solely based on assumptions. Comprehensive tools like Datadog, Dynatrace, or Splunk cater to such needs. With the help of operators within the infrastructure, these tools can seamlessly load the entire application, logs, and their background—provided they have the necessary access authorisations. Unfortunately, in certain organisations like banks, providing such forms of access may not be feasible. On the flip side, other organisations actively seek such authorisations, as these provide a comprehensive overview of all activities in one centralised location.

If using these standalone tools isn't an option and there's a need to tailor the tool more closely to the organisation's requirements, the ELK stack is a viable alternative, with the added option of integrating Grafana.

SRE

Nevertheless, even the finest tool requires an experienced specialist to wield it effectively. This position is called SRE (Site Reliability Engineer), a role that seamlessly blends elements of software engineering and IT infrastructure operations. The individual in this position bears the responsibility of guaranteeing the reliability, scalability, and availability of systems and services for users.

The Site Reliability Engineer is dedicated to troubleshooting issues associated with system performance, stability, and scalability. Their primary objective is to minimise downtime and uphold the constant availability and efficiency of systems. Incident management is also an integral facet of this role.

Conclusion

After reading this article, you might be thinking, "Alright, I'll get to it. I'll plan the DevOps implementation, get the green light from management, enlist Franta from development and Vašek from operations, whip up a few scripts and a pipeline, monitor some stuff, and voila – we're a DevOps organisation!"

It's a tempting thought, but the reality is, DevOps is a highly intricate process that can't be neatly wrapped up so easily. Making DevOps work in an organisation demands a meticulous and responsible approach to each component, regardless of the organisation's size. After all, the entire process chain is only as robust as its weakest link. However, don't be disheartened: with a clear vision and enough determination, implementing DevOps is definitely achievable!