The Current State of DevOps
DevOps is getting even more traction compared to five or ten years ago. The initial reason was the experimentation of development teams and organizations to achieve better outcomes and make more impact on their customers, but what does it mean to have a better outcome? What are we trying to measure?
The very short answer is value; but more specifically, the actual value the organization is trying to provide to their customers. The development, operations, security, and other teams work as one team! This team can identify and improve their organization. Common metrics to focus on include: delivery rate, achieved testing coverage in the application code, security vulnerabilities detected, mean time to recovery, and change failure rate.
Company Issues in Adopting DevOps
When you’re moving towards a DevOps model of engineering, there are some classic problems you may encounter. These are commonly found in organizations that are undergoing cultural change, and crop up time and time again in even the most mature and advanced companies.
Defining a Complete CI/CD Pipeline
CI/CD pipelines are the lifeblood of a modern software engineering team. As such, the pipelines become highly specific to the practices of each individual team. While there are tools that can make this automation simpler, the problem is broader than technology. How do you define which steps matter?
Steps To Overcome This Problem
CI/CD is a difficult journey to begin, and it’s made even more complex by the idiosyncrasies of your engineering teams. Manual deployments breed variance and hidden knowledge. The best place to begin with your pipeline is with the engineers. Have the engineers, or operational staff responsible for deployments, map out their process.
This will begin the design for a CI/CD system. It will also give you an idea of the sorts of features that your CI/CD pipeline will need to support, which gives you a much clearer picture of the tool you need.
Bridging the Silos
Silos exist for a number of reasons. Sometimes, individuals find themselves responsible for a broad remit of code. This responsibility leads them to develop a lot of knowledge, very quickly and makes them indispensable to the company. This is great for the individual, but not ideal for the company. DevOps principles advocate the sharing and upskilling of all engineers, and silos are anathema to that.
There is, of course, the more nefarious alternative. A silo has formed out of the political ambition of a handful of staff. This is a more complex situation, because not only are you taking on a training burden, but you’re dismantling someone’s empire.
Steps To Overcome This Problem
If it’s the former, the individuals on which the entire company rests are typically stressed. Your job is to give them some of their free time back, and protect them from the complexities of their coveted knowledge. This often means encouraging them to delegate.
In the case of an empire, you really only have one option. Senior sponsorship will be required to break down the empire that is preventing your DevOps momentum. If your organization is fully behind the DevOps dream, this will be a difficult but not impossible challenge.
Conflicting Strategies
While the organizational leadership may decide to adopt DevOps, depending on the size of your company, you’ll need to sell the benefits to a lot of other people, too. This is a serious challenge. People have been working in a certain way for decades, and you are trying to convince them otherwise.
Steps To Overcome This Problem
There are two key concerns you need to address when you’re training your colleagues. The first is “What exactly is DevOps?”. These can be addressed with workshops that explain the theory and benefits of DevOps. This is an education challenge but there is plenty of DevOps material out there to help ease you into this challenge.
The second concern is more difficult: “Why is DevOps right for us?” To answer this question, you should bring up comparable companies that have also adopted DevOps. This forms the basis for your argument. Afterward, you should point out areas of the organization that are struggling, due to a silo culture. For example, if you have operational teams who are struggling with failing deployments, for which the engineers claim no responsibility, that should form part of your argument. In short, use other companies as evidence that it can be successful and use examples from your company to describe the value it can deliver.
C-Level Understanding DevOps Culture
Your most senior leadership team will define the tone for the company. If they don’t understand DevOps, it’s almost a guarantee that the company will run into trouble soon. After all, these are the individuals in the company who ultimately broker decision-making. Their decisions need to be informed and simple.
Steps To Overcome This Problem
While workshops might work for the bulk of the organization, your C-level executives are probably very busy. Getting their time will be difficult. Instead, preparing material that simplifies the concepts is a good starting point. This gives a basic understanding and, if you put in the correct arguments, should pique their interest.
Service Disruption
When you’re moving to a new ownership model, the typical operational tasks that your organization succeeded at may be disturbed a little. This is perfectly normal, and may take some time for your engineers to get used to. While you’re overcoming this, there may be confusion in the team when running a deployment, or some difficulty when handling an outage.
Steps To Overcome This Problem
Fortunately, there are lots of really great resources available for how to handle typically operational issues in a DevOps workflow. For example, “Site Reliability Engineering” was written by a series of Google SRE’s who intimately understand the engineering burden.
Conclusion
It’s important to listen to the team. Equally, it’s important to share all the needed information. Transparency should work both ways. A company-wide strategy will ensure where it is heading since the goals for all teams are clear. The possibly existing gap between business, development, and operations can close slowly but steadily. The set KPIs are now shared with everyone and know which part of the problem needs to be tackled and improved. Also, communication and delivery must be automated. Automation is more reliable and it can also save us from playing the blame game within the company. At the end of the day, challenges will come along the way and they exist to be overcome. The practices and principles mentioned in this article have already helped various organizations and moving towards DevOps culture has been proved fruitful.