DevOps changes the way organizations deliver software. However, a DevOps adoption sometimes adds subconscious boundaries to the organization.
For instance, who owns infrastructure now? Are developers able to create infrastructure resources on-demand? Or do they need to raise a ticket? How about CI/CD? The answers to these questions have an impact on the ability to accelerate deployments.
To avoid impacting our ability to deliver software faster, we need to do something. Developers might never want to have to be on-call, but they need feedback. Operations might want to never allow anyone else to manage infrastructure. Security folks might stop a release because they found a vulnerability. There’s always going to be someone owing parts of the system, but how teams collaborate is crucial.
So, how can we start to break the invisible fence between groups created by DevOps and navigate DevOps conflicts? Let’s see.
Traditional Barrier Between Teams
Traditional team topologies have a clear view of who owns what. Operations folks are the ones in charge of infrastructure, and developers are responsible for the application code. When developers finish their code and push their changes to the main repository, it’s time to throw the ball to operations.
Why has this been the traditional way of working? Is it because developers don’t care?
Usually, the reason for this behavior is because operations teams own infrastructure. Developers don’t have access to those resources. And sometimes, this isn’t about a lack of trust in the developers. Some organizations need to have a clear boundary between teams.
But working in this manner is ineffective.
It’s been more than 10 years now that we’ve been battling these traditional barriers between developers and operations. DevOps is helping us to foster a culture of collaboration.
Practices like infrastructure as code (IaC) are helping operators to provision infrastructure in minutes. Teams are now focusing on automating as much as possible. We have the cloud, containers, Kubernetes, Jenkins, and a lot of other tools to automate specific tasks.
But these new changes are creating a new set of conflicts, and sometimes they’re not visible.
A New Wave of Conflicts Within DevOps
Let’s start with the most evident: infrastructure.
Infrastructure has traditionally been for operations folks. But now, with IaC, there’s nothing that prevents developers from collaborating. And this could make operations folks nervous (and developers as well, to some extent).
A way to navigate through this conflict is to protect the master branch and allow developers to create pull requests. Operations folks will continue owning infrastructure, as nothing will be merged until they review it. And developers can collaborate and have a better understanding of the whole system architecture.
Another conflict is within CI/CD pipelines.
After developers push their codes, the pipeline initiates. Operations folks or a new DevOps team usually own this piece of the puzzle. But that could create a capacity problem in the team, slowing the delivery pipeline for developers.
One solution to this conflict is to work CI and CD separately. Let developers own the CI part, and operations folks the CD part. You could use the same pull-request model to allow developers to collaborate in the CD part. Developers might focus on shipping an artifact, and operations on deploying the same artifact to the different environments.
What I’m trying to do by using these two examples is to provide you with an idea of why collaboration is critical. DevOps was born because of the conflicts between operations and development teams. So we need to be careful not to fall into the same trap again.
Collaboration is critical; remember that.
Now, as a general recommendation to solve most collaboration conflicts, you can focus on instrumentation and self-service. Let me explain why.
Increase Feedback With Instrumentation
When you incorporate instrumentation in your application code since the very beginning, you increase your chances of having a pleasant troubleshooting experience. You can understand what’s happening, how the different parts of the system are collaborating, and spot the problem easier.
But the need for having instrumentation is also because developers don’t want or can’t have access to servers in production. Therefore, operations folks can provide a way for developers to have the same visibility that they’d have if they could access production resources.
But instrumentation doesn’t apply only to application code.
According to the DORA report, if you want to be part of the elite performance group, you need to have feedback on key metrics. These metrics are the frequency of deployments, time to delivery, time to recovery, and the failure rate. You can get these numbers by instrumenting your CI/CD pipelines.
Every time the pipeline triggers, you emit metrics. You get feedback. Therefore, you can improve where it matters.
Instrumentation helps you know if you need to stop the pipeline and fix bugs. You can get better insights if the pull-request model for IaC is helping the team or not. You can run experiments with different team topologies and analyze the impact based on feedback.
Facilitate Self-Service Operations
Even though when we talk about DevOps, we talk a lot about automation, the focus has always been on getting rid of manual labor and reducing the toil per the SRE model.
But what about extending that solution to create self-service operations?
We live in a world driven by APIs communication. More and more people are talking about having everything in a Git repository. CI/CD tools are evolving to allow you to define the pipeline with YAML.
One solution for navigating DevOps conflicts is to focus on how teams can collaborate more with a self-service model.
What if developers need a new environment? Instead of raising a ticket to operations, operators can provide developers with a tool to do it.
If you’re in the cloud, and your concern is that you don’t want to overspend, configure budgets or restrict permissions. What if developers want to run a performance test? They can change the specs of the environment with certain limitations that everyone agreed on previously.
When you start providing things like infrastructure or CI/CD pipelines as self-service, you need to have guardrails. These guardrails—such as setting limits and validations on how users will interact with the tools—are what will prevent things from going wrong.
For example, AWS can set IAM boundaries to prevent users from doing more things that they’re supposed to do. You can include security scans to avoid developers using container images with vulnerabilities. Or you can even configure automatic roll-backs when a recent deploy is causing problems.
By having a self-service operations mindset, at some point, the “who owns what” will be shared between the whole team.
A Shared Responsibility Model
Solving conflicts in DevOps shouldn’t be a matter of asking who owns what.
DevOps fosters collaboration, and ownership is a shared responsibility model. It’s everyone’s responsibility to ship better software faster.
Developers don’t have to “fire and forget” their code. Operations, security, business, and other teams will get involved in every phase of the delivery pipeline. Not everyone will have the same skills nor tasks, but collaboration is crucial.
It’s tough to talk about ownership in DevOps in only one post, especially because every organization has its own challenges and conflicts. I’ve always thought that changing culture is the most challenging task for an organization. Yet we tend to focus on the tools or processes, rather than on how people collaborate.
Navigate successfully through any new conflict DevOps might create with a mindset of collaboration. And always make informed decisions based on feedback.
