Both traditional and new telecommunications service providers swept up in the gathering wave of transformation driven by software-defined networking and network functions virtualization are reshaping their world view and themselves to focus more on agility and flexibility. Rebuilding systems around SDN and NFV will change providers' relationships to operations that are more automated and integrated, to infrastructure that uses more generic hardware scaled more flexibly, and to new service development deployed faster and more easily. The evolution can also change providers' relationships with their enterprise customers.
One of the cornerstones of the SDN and NFV transformation is the shift in next-generation infrastructure integration models from proprietary systems to open, public network APIs that tie components together. In a software-defined network, for example, Open Flow's APIs link controllers and data plane devices. In the NFV infrastructure, various open APIs can link virtual network functions managers up to NFV orchestrators or down to virtual infrastructure managers.
Enterprise XaaS mindset promotes use of open network API
Driven by the rise of SD-WAN, private cloud, SDN -- especially in data centers -- and DevOps, a similar wave of change is building in enterprise networks, although not as quickly as on the service-provider side. In enterprises, an appetite for and a reliance on open APIs for integration is on the rise. IT increasingly thinks of anything in the technology environment as a service. This anything-as-a-service mindset can be either in the traditional front-end sense of being outward-facing and consumed by humans or by some outside entity, or in the back-end sense of being consumed by other internal services.
In this new paradigm, telecommunications services are considered just another set of services. So, the new IT pro thinks: Where are the APIs?
Luckily for service providers, changing the fundamental basis of their own infrastructure from hardware to software makes it radically easier to expose service APIs to customers. Once they have converted their own internal systems to an API economy of services that can be provided and consumed, adding a set of APIs to expose them to enterprises largely becomes a matter of addressing four issues:
- Deciding what APIs to expose;
- Finding the right billing metrics and rates;
- Building in capacity monitoring and planning; and
- Making sure the interactions are secure.
Exposed network APIs should include rich monitoring functionality and actual service-modifying features. If a service has any option for dynamically adjusting characteristics like the speed of the connection or the traffic management behaviors associated with it, the network API around that service should provide for programmatic manipulation of those same characteristics.
Monitoring the frequency and duration of changes in service behavior will become an important part of capacity management and may become billing metrics for the API services themselves, in addition to more conventional metrics like the number of calls made or the volume of data transferred through API calls.
Exposed network APIs offer enterprises more network control
Providers will need to implement API gateways with rich security functionality, including distributed denial-of-service protection at the service level, encryption offload, authentication, usage monitoring and audit. Access to usage and audit records should also have customer-facing APIs.
Given such flexibility, enterprises could manage their own networks in new ways and with greater flexibility and responsiveness. For example, after witnessing spikes in demand for a service with an in-house customer portal and both internal and infrastructure-as-a-service-based back-end components, they could ramp up their bandwidth on both the internet link and the port on the provider's cloud exchange through which the internal and cloud-based service components interact. The result would be happier customers, more money for providers and less involvement of service-provider staff at any stage.
Customers to become service development partners
Ideally, by observing and assisting with enterprise consumption of the available network APIs and services, providers will be able to harness customers as a service development engine and turn what they build for themselves into prepackaged offerings for others. In this way, the SDN and NFV transformation offers additional top-line benefits. It not only makes service development easier for providers directly, it brings a degree of crowdsourcing to service development, as well. In this way, SDN and NFV cannot only change the relationship of provider to infrastructure, they can transform the nature of the customer relationship into something more like partnership.
Business case and standards affect providers' SDN and NFV plans
SDN helps keep up with automation demands, DevOps
How NFV and SD-WAN can cut costs, simplify networks