Service providers have been talking a lot about software-defined networking (SDN) and network functions virtualization (NFV), but right alongside talk of how these new technologies will alter network architectures is how DevOps will change the way service providers develop and launch services. The reason? The need for competitive business innovation agility amidst pressure from over-the-top (OTT) providers.
OTT revenue cannibalization is providing the incentive for DevOps
Research firm Ovum estimated that telcos around the world missed out on nearly $33 billion in SMS income from WhatsApp, LINE, WeChat, et al. in 2013, and predicted that the loss would balloon to $54 billion by 2016. In the face of this onslaught, service providers are looking for greater business innovation agility because their slow-moving, waterfall-based service development, testing, and deployment rhythms are far too slow to be competitive with these hyperscale/hyper-agile competitors.
Building a DevOps practice in telecom engineering means culture change and infrastructure evolution. The culture change needs to come from the top down. A great example of this is the much-quoted AT&T Domain 2.0 white paper that acknowledges the need for DevOps thusly:
“There remains much to do before this vision [Domain 2.0] can be implemented, including pivots from networking craft to software engineering, and from carrier operations models to cloud “DevOps” models. We also see an important pivot to embrace agile development in preference to existing waterfall models.”
A key phrase in this quote is the reference to cloud DevOps models, which points to the technological evolution that must accompany culture change. Progressive telecoms that are leaning forward into DevOps are changing the way their very R&D, QA, and preproduction infrastructure is operated to cloud platform management models. The chief need for telecoms is to have infrastructure orchestration and automation that can address the billions of dollars of legacy hardware, as well as the new virtualized and API-enabled infrastructure.
How about your network engineering organization? Is it moving in a cloud-enabled, DevOps direction? I’d love to hear your thoughts and comments.