White Paper Bringing DevOps to Service Provider Networks & Scoping New Operational Platform Requirements for SDN & NFV Prepared by Caroline Chappell Practice Leader, Cloud & NFV, Heavy Reading www.heavyreading.com on behalf of www.blueplanet.com May 2016
Introduction The transformation of network operations is long overdue, but communications service providers (CSPs) have avoided it for fear of disturbing mission-critical operations support systems (OSSs). In the early days of network virtualization, CSPs were adamant that they wanted to achieve NFV without affecting their existing operational systems. However, it is becoming increasingly clear that traditional OSSs will not be capable of managing virtualized networks for a variety of reasons. The majority of CSPs in a recent Heavy Reading survey on the future of OSS are exploring new operational approaches that draw on cloud technologies as these are well-aligned with the goals of network virtualization. CSPs want to become operationally more agile and able to manage the virtualized network in near real time. This means becoming self-sufficient in the design and deployment of new customer-facing services since CSPs can no longer afford the crippling cost and time-consuming nature of engaging professional services organizations in these activities. Self-sufficiency implies using a model-driven and DevOpsstyle operational approach, which minimizes the need to develop custom code and standard IT tools such as Business Processing Modeling and Notation (BPMN) and Topology and Orchestration Specification for Cloud Applications (TOSCA) for building reusable, "micro" workflows, rather than complex per-service workflows and scripts. This combination of technologies can reduce service delivery times from weeks and months to hours and minutes. Agility is achieved in the IT cloud environment through the microservices-based software design pattern, which enables applications to be developed, enhanced and deployed much faster than through traditional methods. An operational platform built out of microservices provides significantly more flexibility than monolithic OSS. Microservice components can be composed in different ways to address different management use cases and their loosely coupled, API-driven nature means that existing components can easily be upgraded and replaced and new ones added. Open source-based microservices are proliferating and such a platform allows operators and suppliers to take advantage of the pace of market innovation. Multi-domain service orchestration is emerging as a key operational requirement for the virtualized network and is an example of a system that can be built from microservices-based platform components. NFV and SDN introduce new domains that must be managed in addition to physical network elements that continue to be managed by traditional OSS. CSPs want a means of managing the lifecycle of customer-facing services across all these domains using a single centralized, modeldriven layer of orchestration. Multi-domain service orchestration is key to rapid service deployment and supports CSP self-sufficiency in service management. This paper discusses the requirements for network operations transformation and outlines the benefits of new technology approaches that, when combined in an operational platform, satisfy the novel management needs of a virtualized network. Operations Must Embrace Technology Change Drivers for Network Operations Transformation The list of drivers for network virtualization are a familiar litany: greater business agility, faster service delivery times, accelerated service innovation and new revenue HEAVY READING MAY 2016 WHITE PAPER BRINGING DEVOPS TO SERVICE PROVIDER NETWORKS 2
generation. However, while NFV and SDN introduce more agility into the way network elements are deployed and configured, this is not the end of the story. Arguably the most valuable contribution NFV and SDN are making to the telecom industry is as catalysts for much-needed operational change. There is widespread market acceptance that network virtualization will not yield the benefits touted for it unless CSPs overhaul the way they manage their networks. In the physical network, operations are manually intensive and expensive. Adapting them for new services and/or the introduction of new network elements and technologies is a painfully slow process. Even without the spur of network virtualization, operational transformation is long overdue. NFV and SDN make the need for change more urgent while simultaneously making it easier to achieve. This is because they turn the network into software-based abstractions that can be managed and manipulated programmatically rather than physically. Traditional OSS Is Being Disrupted CSPs already well down the track with NFV and SDN proofs of concepts (PoCs), trials and implementation understand that traditional OSS will not adequately support the operational needs of a virtualized network. Only 20 percent of CSP respondents surveyed by Heavy Reading (see Figure 1) expect to continue to use their existing B/OSS to manage NFV, and many of these respondents are only doing so to get started with NFV and ensure the buy-in of their operational staff for the time being. Figure 1: What Is Your Company s B/OSS Strategy for NFV? Source: Heavy Reading 2015 OSS and MANO Survey, n=103 Most respondents recognize that traditional OSSs were not designed to handle the near-real-time speed of change NFV and SDN bring. For example, as customers order services on demand, virtualized network functions are dynamically created, scaled, reconfigured and terminated at a velocity unimagined in the traditional, physical HEAVY READING MAY 2016 WHITE PAPER BRINGING DEVOPS TO SERVICE PROVIDER NETWORKS 3
network. Traditional OSSs do automate management processes, but in a hard-coded, inflexible way. Even small code changes are expensive and time-consuming to achieve, and they typically require the services of the OSS vendor or a systems integrator. Many traditional OSSs stop short of automating the lifecycle management of network elements, handing over to manual operational processes at this point. Manual processes do not scale in the virtualized network environment. Finally, traditional OSSs are usually deployed in a siloed way, with different sets of systems and processes looking after different layers of the network. Managing a customer-facing service end to end, across all the network layers and domains it touches, is a highly complex activity. The new speed of fulfillment enabled by NFV and SDN requires services to be deployed and managed using a single set of automated processes end to end. Modernizing Network Operations Means New Technology Adoption If CSPs are to implement NFV and SDN successfully, network operations must take advantage of what has been described as a "perfect storm" of new technologies associated with virtualization and the cloud. There are three technologies in particular that are coming together to transform network operations: DevOps-style modeling approaches that enable CSPs to be self-sufficient when making changes to operational processes and systems; that is, they should not have to write customized, proprietary code or enlist the help of a third-party professional services organization. Next-generation virtualization technology and its associated application design pattern, microservices, which allow operational systems to be designed and deployed as small, discrete, loosely coupled components that can be composed in agile ways to meet new operational requirements. Increasingly, microservices-based components are being delivered as open source code. Orchestration technology that provides a high level of abstraction across multiple layers of the network, "stitching together" domain-specific operations so that customer-facing services can be managed consistently and centrally end to end. These technologies will underpin a new operational platform for the virtualized network. A platform is not an external, monolithic system or a suite of management applications, like a traditional OSS. Instead, it provides an open and easily extended set of operational capabilities that can plug and play with each other and with other cloud-based software, and out of which appropriate management functionality can be built. New Operational Platform Requirements Self-Sufficiency in Service Delivery Thanks to the online ordering experience everyone is familiar with from the cloud, CSPs are coming under intense pressure to deliver their communications and connectivity services in the same way. Customers want to be able to go to an online portal, configure the service that they need through a graphical user interface and have the service automatically activated and available within a matter of minutes or, at the very latest, within hours. HEAVY READING MAY 2016 WHITE PAPER BRINGING DEVOPS TO SERVICE PROVIDER NETWORKS 4
In this scenario, there is no time to ask the IT department or the OSS vendor's professional services organization to write new code that will create and manage the service the approach many operators take today. Not only are CSPs drowning in a sea of service-specific workflows and scripts, they are also spending large amounts of money to create and change them every time they want to launch a new customer-facing service or modify an existing one. This is an unsustainable state of affairs even in the traditional network, and does not translate into the near-realtime NFV environment. CSPs need to become self-sufficient in service delivery, able to turn up and change services themselves very quickly without recourse to third parties. This requirement is driving the need for a model-driven operational platform where services can be modeled at an abstract level as a set of logical capabilities that any instances of physical and/or virtual network elements could satisfy at runtime (see Figure 2). Configuring devices to support new services becomes a matter of configuring models and since this can be carried out programmatically, it can also be automated. As a result of automation, service provisioning becomes a fast and low-cost process, aligned with the DevOps timescales experienced in the cloud. Figure 2: Model-Driven Service Delivery Source: Ciena Blue Planet Even in a model-driven platform, there can be a need to create workflows, although these are likely to be "micro workflows" that are less complex and more reusable than the service-specific workflows built on a per-customer basis by professional services organizations. In the spirit of self-sufficiency, network operations staff will want to be able to define these workflows themselves. It is helpful if the operational platform supports standard IT tools, such as BPMN tools and TOSCA, for this activity. The use of such tools facilitates the alignment between network and IT organizations, since both start to "speak the same language." This alignment is a major goal of operators pushing towards network virtualization and a DevOps way of working. HEAVY READING MAY 2016 WHITE PAPER BRINGING DEVOPS TO SERVICE PROVIDER NETWORKS 5
Microservices & Open Source Technology Cloud applications developers have pioneered the concept of microservices, where applications are constructed from small, loosely coupled components that are fast to develop, scale independently and gracefully, and enable continuous feature enhancement without breaking the entire application. Microservices can also be deployed very quickly using the next-generation virtualization technology: containers. Monolithic systems architectures with lots of internal dependencies and tightly coupled capabilities are very difficult to change and have proven difficult to execute in a cloud environment. They also require the heavy machinery of virtual machines (VMs) and hypervisors. Network functions are beginning to be virtualized using a microservices approach. So, too, are the open source technologies populating the virtualization and VIM components of an NFV infrastructure (NFVI). The software development world is moving toward microservices-based "cloud native" application development and a vision of being able to compose microservices together in flexible ways to provide the application functionality needed by a specific user(s) in a particular context. It makes sense for an operational platform for the virtualized network to be designed similarly. In this way, network management functionality can also participate in the cloud and microservices evolution. Network operations teams want to benefit from the speed and agility of microservices-based development, which allows rapid integration of new open source capabilities. At the moment, an open, microservicesbased operational platform might contain "plug and playable" open source system components, such as distributed real-time event processing systems, distributed high availability databases, load balancers, deployment, configuration, monitoring and logging tools, Web interfaces or SDN controllers. In future, it might also accommodate core OSS capabilities from third-party or open source contributors. The loosely coupled, open API-driven nature of microservices encourages such extensibility. Multi-Domain Service Orchestration Network virtualization is creating new potential silos as CSPs implement domain-specific SDN controllers in the WAN and data center and add one or more NFV management and orchestration stacks in different parts of the network, for example, to support a virtual CPE use case and/or a virtual Evolved Packet Core or VoLTE. At the same time, CSPs still need to manage their physical networks using traditional OSS. As we have seen, traditional OSS have limitations that make them unsuitable for managing virtualized network domains. Yet customer-facing services need to be delivered end to end across all of these silos, both the existing and the new. The market has recognized the requirement for a multi-domain service orchestration capability for fulfilling services, regardless of whether the network element that supports it is physical, and managed by a traditional OSS or SDN controller, or virtual, and managed by an NFV orchestrator/sdn solution. The multi-domain service orchestrator is an example of management functionality that can be built out of the microservices components within a new operational platform. Multi-domain service orchestration should be model driven, enabling services to be managed and manipulated end to end, from a central point and at a high level of abstraction. It binds services to network elements in specific network domains at runtime for maximum agility and flexibility. It has end-to-end visibility of the way services are mapped to domains but allows each domain to manage itself autonomously to reduce management complexity and functional duplication. HEAVY READING MAY 2016 WHITE PAPER BRINGING DEVOPS TO SERVICE PROVIDER NETWORKS 6
Figure 3: Multi-Domain Service Orchestration Source: Ciena Blue Planet Conclusion Network virtualization is a catalyst for operational transformation. The challenges of traditional OSSs are well known, but CSPs have been reluctant to resolve them due to the mission-critical nature of such systems and the complexities involved. Since traditional OSSs are not agile enough to manage the virtualized network, CSPs are compelled to look for a new operational approach. It makes sense for a new operational platform to adopt the technologies used to drive automation and agility in the cloud. These technologies include model-driven techniques that support a DevOps model and enable CSPs to become self-sufficient in service delivery and microservices software development. Developing operational platform functions as a set of microservices that can be composed together via open APIs gives CSPs enormous flexibility, allows them to add new features more quickly, and enables them to take advantage of an extensible platform capable of leveraging open source-based components. Operational platform function can be used to compose a multi-domain service orchestrator a key capability for delivering services across the extended network domains resulting from the introduction of SDN and NFV. CSPs urgently need a single, common point for managing services end to end across physical and virtual network infrastructure and the many different management silos they present. CSPs that adopt a model-driven, microservices-based operational platform are preparing themselves to meet the future challenges of a virtualized network while still supporting their legacy OSS and the traditional network. Such a DevOps-style operational platform has an important role to play in helping CSPs migrate nondisruptively to a future operations mode while taking advantage of the technologies that are making cloud providers agile and highly competitive. HEAVY READING MAY 2016 WHITE PAPER BRINGING DEVOPS TO SERVICE PROVIDER NETWORKS 7
About Ciena Blue Planet Network operators are transforming to more open, programmable and automated networks to meet the evolving needs of end customers, who have grown increasingly accustomed to the agility and flexibility provided by the cloud. This transformation starts with software. Ciena's Blue Planet is an extensible network virtualization and service orchestration platform that simplifies the creation, automation and delivery of services from end to end across physical and virtual domains. In doing so, it provides an unprecedented degree of DevOps-style self-service programmability, allowing network operators to take control of their networks, add resources and quickly create and deploy new services at the speed their business demands. HEAVY READING MAY 2016 WHITE PAPER BRINGING DEVOPS TO SERVICE PROVIDER NETWORKS 8