DevOps aims to unify the processes within a company’s IT team. In more traditional approaches IT teams were split into development and operations teams. Everyone who has worked in this setup has witnessed late time changes to software development projects, due to a lack of early collaboration between development and operations teams.
This is one of the main points DevOps processes, tools and foremost culture is addressing. In simple terms DevOps is aiming to improve the collaboration between development and operation teams. A third factor which should be considered as a first class citizen is security. By adding security teams to the process, DevSecOps is born.
Working in silos is a topic which is not only addressed in DevOps approaches. It is a trend throughout the last decade across all industries and professions. Scrum, SAFe etc., they are all trying to break silos within companies and foster more direct collaboration across teams to be more flexible to change and deliver better quality products in ever decreasing time. Already Charles Darwin stated: “It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.” Breaking up the silos between Dev and Ops leads to a shift in responsibilities. For example debugging a problem in production due to a software bug, should be conducted by the person who is responsible for that part of the software. In this example it is the developer. In the end it does not mean that this person has to do everything on his own, but the initial tooling should be available to get the person in the position to have access in a secure way to the data necessary to understand the problem and pull other experts into the process if there is need for it. Operations experts are in charge of the underlying infrastructure and only in collaboration with developers conduct the day to day tasks, which before was the sole responsibility of an operations team.
When we look at the different aspects of DevOps I like to break them up into culture, methodology/processes and tools. In the following sections we will look at the different aspects from a high level. Each of the topics will be elaborated on in subsequent DevOps articles. This article should only give a high level overview of the topic.
Culture is nothing to change from one day to the other, but more a long term process. Many projects and teams exactly fail to be more successful with DevOps or DevSecOps approaches, because they are not changing their culture. Starting with processes and tools will fail to address the most critical components to success.
Samuel Beckett
DevOps works best if the companies live in a culture where innovation is key and self responsibility is in the DNA of the company. The IT landscape is ever changing and keeping up is a challenge in itself. DevOps increases the responsibilities of every human involved which also makes it more susceptible to fail if a blame culture is lived within it. Good DevOps practices include “you build it, you own it” and “fail fast”. When looking at the statements it becomes clear that DevOps is part of Agile Practices and was developed because of the principles which make Agile successful.
When looking from a culture perspective with DevOps as well as DevSecOps the most important point contributing to success is that the boundaries between the different traits are lowered and that the product is seen as a whole. It is all about delivering value and for that collaboration is needed. From a team perspective I see a lot of merit in building cross functional teams who own their work from ideation through development to operations. Of course it is important that the teams are equipped by other teams with the tools necessary to excel. It is not about redefining the wheel in every project, but to build on top of proven best practices and have the freedom of innovation when there are strong reasons from a value perspective to deviate from the baseline.
DevOps and DevSecOps are clearly grouped within agile Software development. When picking up where we have stopped in the culture section, developing best practices across cross-functional teams, automation is a key factor. All processes and methodologies in DevOps are aiming to automate as much as possible to reduce the risk of human error and defining for product development teams processes which improve their quality as well as speed up the process of innovation. It is not all about speed, but as often seen in projects even the ability to realize new ideas is something which is often not possible.
When looking at job descriptions more often we find the role of DevOps engineers who are responsible for implementing automation and tools within a company. The role in itself is not a solution to success. DevOps engineers need to be tightly integrated into the product development teams to work based on actual limitations seen across teams. It is vital that DevOps Engineers are not considered a Silo in itself. A point which seems obvious but can be seen to be quickly forgotten.
The DevOps lifecycle defines the different stages in software development. All the stages should be tightly integrated and a frictionless workflow throughout the stage should be possible. It can also be described as “continuous everything”, also often described as the 6 or 7 C’s of DevOps. Even though continuous everything showed not to be the end here. For example in monitoring, even more advanced is proactive monitoring. It is not enough to continuously monitor your system, if the reaction to a failure is conducted too late. In an even more ideal scenario the system realizes that there are indications of failure and reacts automatically to prevent this failure to happen, e.g. by scaling out.
There are endless tools out there which are categorized as DevOps tools helping to carve the way to more productive IT teams. Don’t get too entangled in tooling. Tools are just the means to solve a challenge you are facing. The landscape is becoming broader and broader. Just take a look at CNCF landscape alone as an example. First think about culture and processes and then choose the right tools for your business and its goals. The right tools for one company might not necessarily fit your situation! In our projects we come across different ToolStacks which all have their pros and cons and are chosen because of the specific needs of the individual projects or company needs. Strong competitors which have proven to be valuable in multiple projects, like Terraform, HashiCorp Vault, Jira, Gitlab, Prometheus, Grafana can build the foundation of your DevOps Toolchain and be extended with specific tools for your requirements.
The number of methodologies, the cultural change in companies and a large, broad selection of tools affirm the benefits of DevOps immensely. Therefore, the question does not appear to be whether DevOps but how and, above all, when DevOps can finally be applied and deployed to lead to measurable success.
We evaluate the DevOps progress in a company with our DevOps maturity model, which is centred around the aspects of the article, culture, process and tools. It documents the process towards a more successful IT team focused on product development and value creation for the business. At demicon, we can support you in all areas of DevOps. With our deep knowledge in the Atlassian toolchain, Agile Development and our d-3.cloud unit focused on DevOps-based operations in the cloud, we have clearly acquired the expertise to support on the cultural level, the process side as well as with architectures and implementations. Let us work together to shape, accelerate and ultimately lead the way to success on your DevOps journey.