From Gatekeepers to Service Providers: Reimagining DevOps Relationship with Developers

Most of us, if not all of us, are service providers. It doesn’t matter what position we are in. Each person in an organization renders service onto the organisation, even the CEO and board of directors. Perhaps the only ones who are not service providers are the investors but perhaps they too render their service onto someone or something else. We begin with the notion of service providers because it is a crucial factor in the relationship between DevOps and developers. 

‍

The Relationship between DevOps and Developers

The relationship between DevOps and developers is as delicate and complicated as it is crucial for the whole organization. Delicate because any friction causes setbacks in development. Complicated because it spans across many domains of knowledge and various requirements. And crucial for the whole organisation because if it’s not optimal, developers don’t deliver quality releases on time.

Luckily, the core of the relationship between DevOps and developers is technological so handling challenges and adaptations is technological in nature. There are ways, purely technological ones, to reduce the pressure DevOps face on the one hand, and on the other hand remove obstacles from the developers’ way and let them become independent in their work. 

‍

DevOps Are Service Providers but on a Different Scale

DevOps is developer operations abbreviated and it’s easy to see from this terminology that DevOps are the exclusive service providers for developers and should gear themselves accordingly. However, it appears that acting as service providers doesn’t come easy to DevOps due to the scale and complexity of what’s required from them as service providers. As a result, a lot of friction and dissonance exist between DevOps and developers in many organizations. To solve the friction and dissonance we need to understand what type of service providers DevOps are, what’s the scale of their work, and how they can improve communication and operations to make their work, and the developers’ work faster, easier and more efficient.

‍

Understanding the Role of DevOps as Service Providers

Most service providers usually provide their services within well-defined scopes. Developers develop, analysts analyze, QA verify and so on. It’s true that these can also have their own internal customers like team members that require assistance. However, in such cases the service or assistance are still within the scope and on a relatively small scale.

DevOps is a different story. Not only do DevOps have their own work cut out for them, they also support a lot of internal customers, and do so on a much larger scale and within a wider scope. DevOps assist RND people (and others such as analysts and sales engineers) in a wide variety of contexts:

• Assisting in setting up local environments
• Granting roles and permissions to internal and external systems
• Troubleshooting issues with databases, microservices and deployments 
• Provisioning resources on demand 
• Consulting on scale and security

The problem here is that DevOps are a lot times unprepared and unequipped for it. Neither in terms of understanding who the customer is, what they need, and how to give it to them with resources and restrictions in mind, nor in terms of how to do it in scale.

DevOps usually come into the job with a different mindset. A DevOps engineer probably sees themselves responsible for the development and maintenance of mainly the following:

• Infra - Cloud, different environments, 
• Monitoring, logging and alerting systems
• CI/CD infra

Most DevOps will agree that it’s ok to add to this list ongoing support for developers and other stakeholders over a wide variety of contexts, systems, frameworks, and platforms,

However, it’s this very same wide variety of domains that DevOps support that prevents them from providing good service. When DevOps are unable to provide this service it creates a lot of friction and dissonance between DevOps and developers.

‍

The Dissonance Between DevOps and Developers

There’s no shortage of dissonance and conflict between DevOps and developers. Let’s look at some real life examples.

What DevOps might say:

• Developers don’t do the bare minimum to solve issues themselves before turning to DevOps
• Developers requirements from DevOps is always the path of least resistance
• Developers don’t develop with security and scale in mind

On the other hand, developers may want to counter argue:

• DevOps are not responsive enough neither in terms of time to resolution nor deliverables 
• DevOps impede development and velocity through requirements and bureaucracy 
• DevOps don’t develop with developers in mind to assist them and facilitate their work

It’s easy to see the dissonance when these complaints are put side by side and one after another. Putting this conflict into structure reveals the disconnect and distance between what one side needs and what the other side is capable of providing. Since DevOps have their own duties to fulfill, adding to that extensive support adds pressure. This pressure could make DevOps compromise on the service they give because they are short on time and resources. So they expect developers to be self-sufficient and efficient when asking for support. What DevOps see as inefficiency in developers stems from the fact the developers are the most pressured entity in the organisation because they develop the product. When developers come across issues that prevent them from working they too are short on time and resources and need someone to assist them in a timely manner.

This is reality nowadays in many organizations. Both developers and DevOps are short on time and resources and when the former approaches the latter, the latter needs to halt their work and assist or the development will suffer setbacks. The goal is to change this reality and realign DevOps and developers towards better collaboration.

Realigning DevOps with Developers

To realign DevOps with developers is not an easy task. The dissonance is not found in disagreement and differences. The dissonance is found in the fact that it’s not easy to change this reality and realign DevOps and developers towards better collaboration. It’s not enough to just tell DevOps that they are service providers and should do what they can to support developers in their day-to-day operations. It’s not enough to tell developers to approach DevOps like a customer requiring a service. 

What’s lacking here is not verbal agreement but a well-defined, well-implemented framework of methodologies to help the two sides communicate and collaborate clearly and efficiently. Moreover, the DevOps mindset must incorporate the idea that to provide services on a large scale, you need tools and you need to know what the customer needs, how and when. For DevOps, to provide services is to alleviate the pressure coming from developer needs and improve delivery. Let’s explore some ideas for improvement. 

Communication Tools

Most companies use some form of ChatOps such as Slack or Teams. A dedicated channel for requests from developers is the first step. However, if there’s no structured way to submit requests for support or resources, it can become unmanageable and unwieldy really quickly. Many requests can come in at once and each of them might be related to something different. To tackle this issue, it’s possible to install a request bot or request form in the dedicated channel. The request bot or form allows developers to submit requests in an orderly manner. It also allows DevOps to manage requests by queue and with more info and context to begin with. The form or bot should gather the following from the requester:

• The nature of the problem - is it a request for support, general question, request for resources
• What’s the environment in question - is it local, dev, or production
• The request itself - does the developer need to set up a new service, are they having issues with a service, do they need more permissions for internal and external systems
  
  • If it’s a service - what is the name of the service and are its dependencies (storage, docker repos, git repos, databases) 
  • If it’s a request for resources - quantitative measures such as CPU and memory and justification for adding resources
  • If it’s more permissions - justification for permissions 
• What steps were taken to try and troubleshoot - were applicable
• Any additional information that might be relevant - logs, metrics, documentation

With the above in mind, now it’s time to see what can be automated or made self-serve to facilitate developer work by way of delegating and enabling. 

Facilitating Developer Work

Most customers would prefer to do things themselves. Especially developers who always work in fast-paced environments and within time constraints. We’ve started with communication tools and now want to :

• Gather info and analyze
• Discover areas that are constant pain points for developers
• Automate or delegate where possible
• Rinse and repeat 

This way DevOps can automate repetitive tasks such as granting permissions or provisioning resources. DevOps must also think about protecting their own customers and not be too permissive. Clear boundaries need to be defined when permissions or resources are asked because, like we said, DevOps are usually adamant when it comes to security and scale.

Beyond turning repetitive tasks to self-serve, DevOps should also strive towards making developers’ work as easy as possible. For a developer, an easier way to work could include:

• Work - do everything on their own without needing anyone’s help
• Develop - disposable dev environments that are quick to set up
• CI/CD - easy to configure, easy to deploy, easy to revert
• Panic time - clean, well-scoped, logs and metrics that are easy to search

At this point we are almost three quarters of the way in. Now all that’s left is to make sure that customers are well-aware of what’s at their disposal. DevOps can and should plan for building a body of knowledge to assist and educate developers on how to make the best of what’s offered to them by DevOps.

Summarize, Refine, Document, Educate

Once proper communication and procedures are in place to facilitate developer work, the body of knowledge should be assembled. Everything that doesn’t fall under automated requests and better troubleshooting and debugging tools, should go into the body of knowledge. 

The body of knowledge consists of the following:

• Documentation
• How-Tos
• FAQ
• Workshops 

Composing and maintaining a body of knowledge is probably one of the most challenging things DevOps can do. It’s easy for DevOps to configure automations but most don’t know how to write in a clear concise manner. In addition, most customers don’t really bother to read the docs and if they do they just skim through. Even if developers do make use of documentation and workshops, knowledge is changing fast and there’s a need to adjust and update the body of knowledge accordingly. To tackle this challenge DevOps can encourage developers to take an active part in maintaining the body knowledge. An engaged customer is most likely a self-sufficient one. Perhaps the most important aspect of imparting knowledge is workshops. Not only is it easier to learn and understand by doing rather than reading, it also brings DevOps and developers closer together and strengthens their relationship. 

‍

DevOps is as Service Maintaining Relationships at Scale

The first step towards improving the collaboration between DevOps and developers is understanding its scale. The scale is massive enough to put strain on the relationship and like most scale issues, systems and procedures can be put in place and iteratively revised and improved to handle it. 

DevOps must acknowledge that they are service providers at scale. Being service providers at scale, they must understand their resources, capabilities and limitations in assisting developers, and put a system or procedure in place to handle it for them. DevOps must empower developers and delegate more responsibilities to them, therefore relieving pressure off of themselves while giving developers more agency. Only when DevOps follow this set of principles, will they be able to finally emerge as they have always meant to have been, service providers at scale.