Bridging the gap between developers and operators

Bridging the gap between developers and operators

Robert Ericksen explains how Kyndryl can help businesses access the benefits of a DevOps approach

Alex Smith |

Traditionally, the relationship between developers and operators has been a fractious one.

While a development team is always looking to push forward new capabilities and releases to meet the demands of the market quickly, the operations department is aiming to ensure that solutions remain stable and available. While one side wants to ensure constant change, the other wants to stay the same. 

This natural conflict is what DevOps, a combination of practices and tools accompanied by a mindset shift, is designed to resolve. By bringing together the two sides of development and operations, a DevOps team aims to avoid bottlenecks that can reduce a client’s agility and responsiveness. 

“What we’re trying to do is to streamline that relationship,” says Robert Erickson, director of managed multi-cloud platform at Kyndryl. “DevOps is a culture of collaboration and communication that is applied consistently. Teams have the right tools and the right understanding of the process from the beginning, and the key is to make sure there’s visibility and traceability through the production pipeline.” 

As Eriksen explains, this mindset can be expanded even further to encompass the ever-pressing need to ensure organisation-wide security in what is known as DevSecOps. 

“DevSecOps takes the approach one step further by adding security” says Eriksen. “It’s about a change in mindset, infusing a security perspective throughout the pipeline. When we build user stories, for example, do they conform to security measures? Have we added the right security features in our coding? Once we’ve finished a release, are there any vulnerabilities we can learn from and fix in the next cycle? There’s tooling along the way, but it’s primarily a philosophy.” 

However, while DevOps and DevSecOps processes can be implemented very effectively at the scale of a small team, managing production across a large organisation can pose very different, more complex challenges. 

“DevOps starts with small teams of very passionate people,” says Ericksen. “But as you scale up from 13 people to 600 people globally across many different regions, you start to expose some problems. For example, a team with higher priority may block another team from using a resource, without the latter ever understanding why. If there’s ever any doubt about when something’s going to be available, then my customers are all going to question if they should move on to a competitor.” 

To help address the problems caused by trying to implement a DevOps approach at scale, Kyndryl has created a solution that facilitates better communication and collaboration. 

“Kyndryl built a solution called DevOps Intelligence, which is a set of tools and practices for DevOps and DevSecOps at scale,” says Ericksen. “They allow us to see across multiple pipelines and understand multiple impacts, so that leadership can have full visibility. Firstly, small teams can use a variety of tools, including Microsoft Teams, to communicate with each other in real time. Secondly, we gave them visibility through a DevOps Intelligence operating centre, which informs teams of problems in the pipelines so that they can be resolved.” 

Ericksen identifies four different approaches or ‘topologies’ that organisations can take in partnership with Kyndryl to achieve DevOps at scale. 

1. The shared operations topology. For organisations that don’t have a DevOps process, Kyndryl will provide an advisory set of capabilities to help understand and educate them on DevOps and DevSecOps processes.  

2. The DevOps-as-a-service topology. Customers that just require a team to implement DevOps can outsource that role to a dedicated team at Kyndryl, who will build a pipeline for handing productions on to operations. This allows the customer to begin the cultural shift required for DevOps by retraining all of their developers overnight. 

3. The advocacy topology. In this approach, the customer creates the DevOps team as a kernel. As they pass developments through the pipeline, their teams are being trained, so that they can gradually be expanded to absorb the existing development process. 

4. The site reliability engineering (SRE) topology. A DevOps pipeline is put in place, and the team is infused with SRE experience. By pairing up a developer who is great at user experience but knows nothing about software defined networks, for example, with an SRE engineer who can speak the language of a developer, businesses can create applications designed for those environments from its inception. 

“We ourselves went through a massive transformation, and have some tales from the trenches as we went through the process of implementing DevOps processes,” says Erickson. “We have a deep, intrinsic knowledge of how to help our customers go through that process too.”  

This article was originally published in the Summer 2022 issue of Technology Record. To get future issues delivered directly to your inbox, sign up for a free subscription.

Subscribe to the Technology Record newsletter

  • ©2024 Tudor Rose. All Rights Reserved. Technology Record is published by Tudor Rose with the support and guidance of Microsoft.