The cultural demands of DevOps

DevOps principles can help communications service providers (CSPs) evolve from a highly architected and reliable, yet fixed environment to new ways of cross-functional collaboration – but only if they are willing to embrace significant cultural change.

DevOps is as much about culture as it is about processes and tools. In an Agile development environment, the cadence of software development is radically different from traditional waterfall methods.

Fixed, sequential processes give way to an iterative style, with the emphasis on frequent, short development phases called sprints, and the regular delivery of functionality and working prototypes on which the business could provide feedback. While this provides significant benefits in development, much of the gain in speed and agility are wasted when testing and deployment are disconnected from the design and development process.

The DevOps movement seeks to extend this agility right through the software lifecycle, by creating shared responsibility for producing working software across development and operations teams. This is enabled by feedback loops at every stage of the lifecycle which allow for continuous improvement, learning and experimentation. The desired result is a continuous flow of value from business to customer.

This is achieved by breaking down the solid wall between development and operations, automating as much as possible of the development-to-deployment continuum and enabling collaboration by all stakeholders in delivering a quality service.

The use of DevOps goes hand in hand with the shift to cloud native platforms, which require modern development architectures. In a cloud native environment, the emphasis is on decomposing an application to a set of granular functions or microservices, which communicate via APIs. Each runs in its own container which can then be deployed into a cloud environment (whether public, private or hybrid).

From a development perspective, each microservice can be built, updated and deployed to its own cadence, removing much of the dependency between individual pieces of the application and enabling the continuous development and delivery process espoused by DevOps.

Containers are then managed by orchestration software that takes care of deployment, scaling and management of the running application, with Kubernetes as the de facto standard. For many CSPs however, the journey to cloud has been slow and problematic.

For new applications such as digital experience and the creation of new lines of business, it makes sense to adopt a cloud native model from the outset. However, for backend functions the business case is less clear. The process involves either modernizing legacy operational and business support systems (OSS/BSS) or simply “lifting and shifting” them to the cloud, but there has not been pressing need for change. Since digital applications and projects have been relatively self-contained, IT has often operated in a two-speed model, and organizations have shied away from undertaking the wider business and IT transformation and modernization that is required to take full advantage of cloud.

Encouragingly, more than 80% of CSP respondents to TM Forum’s fifth annual Digital Transformation Tracker survey in 2021 were either committed to a cloud native approach for all IT workloads, or preferred to take a cloud native approach where possible.

DevOps uptake varies by domain DevOps adoption in telcos varies widely both within individual CSPs and across the industry. For each company, adoption can be classified against three domains:

• Customer-facing digital products and services – newly developed digital products and services are most likely to use cloud native technologies and platforms, and it is here that the uptake of DevOps is greatest. These assets are often developed on a standalone basis, relying on APIs to integrate with other applications and data sources. They are iterative by nature and open to experimentation, so fit well with a DevOps approach.
• In-house IT including OSS and BSS– the migration to cloud environments is underway, with BSS ahead of OSS. These applications are more business critical by nature, and CSPs are more reliant on software vendors to supply the core functionality. DevOps adoption in IT is at an intermediate stage and closely intertwined with the approach of software vendors, most of which are directing and enabling their customers’ migration to cloud and espousing DevOps. Because of this dependence on suppliers, the legacy platforms, particularly for OSS, make it more challenging for CSPs to move forward quickly. The goal is for a cloud native architecture and the use of DevOps processes to power collaboration between software vendors and CSPs to extend existing systems with new functionality and services.
• The network – In the network stack, DevOps has yet to penetrate at any scale. While the transition from hardware- to software-based networks is underway, it is still in its early stages. The predominant culture of network engineering, with an emphasis on linear design to achieve maximum reliability and availability, is less compatible with DevOps practices such as continuous deployment. Furthermore, because CSPs have largely procured their technology rather than built it, there is less opportunity to bridge a gap between development and deployment. The exception is in some Tier 1 CSPs, where convergence between IT and network domains is further advanced, with platform strategies enabling business units (and potentially customers) to build and deploy new services on an integrated software-driven architecture. The strategy here is more akin to that of the hyperscale cloud providers such as Amazon Web Services, Google Cloud Platform and Microsoft Azure, and DevOps plays a much more prominent role in facilitating an end-to-end development/deployment process.