A constant theme in my surfing lessons this summer was the importance of understanding rip currents (water from incoming waves exiting a beach) and what to do if caught in one. An olympic swimmer can’t beat the speed of a rip current: fight the current and you will drown. By contrast an expert surfer (not me) will use a rip current to rapidly move to a good surf location; a non expert should swim tangentially to escape its grip. This felt like a good analogy for the way Telcos are currently tackling NFV and the cloud. Telcos in continuing to focus on platform high availability are fighting against the rip current of cloud. They need to work with the cloud to achieve the benefits of network virtualization.
The challenge of fighting, rather than working with cloud, was highlighted for me in a recent webinar by Windriver with BT on the challenges of vCPE and Openstack. The six challenges identified are all very real, but their positioning in terms of the need for the cloud (Openstack) to become ‘carrier grade’ and enable 5 9s felt like a missed opportunity for new thinking. The focus on a distinct ‘carrier need’ framed the question to inevitably create an answer that is a ‘virtualized’ replica of existing hardware based networks.
Three behaviours seem to characterize this carrier fight against the cloud:
- The desire to reuse and maintain a function rather than recognising that the cloud removes the barriers to tearing down and rebuilding function on demand.
- The desire to maintain static dependencies between functions rather than recognising that in the cloud dependencies will change as independent functions change, scale and fail. Function dependency management needs to be built into the ongoing service lifecycle not just at time of initial fulfilment or based on static definitions.
- The desire to centralize control. Centralizing anything creates single points of failure and scaling bottlenecks in a distributed cloud system. Everything in a cloud service has to be capable of distribution and redistribution in response to failure rather than tying this to an underlying high availability platform.
That is not to say that current cloud platforms are necessarily fully ‘fit for purpose’ in a geographically distributed cloud, based as they are on a big data centre heritage. However, rather than shaping these problems as a specific carrier need they should be shaped as general needs that any geographically distributed cloud should handle.
Looking at two of the challenges identified in the webinar could these be possibly tackled these in a different way?
Challenge 1 -Binding virtual network interface cards to the virtual network function
This is a dependency management problem between the VNF and vNIC. Openstack exhibits non-deterministic behaviour in naming vNIC ports but also the VNFs have been hard coded to require specific names and port order. Recognising this as a dependency problem we could look for each function, be it VNF or vNIC, to be capable of exposing their edge or boundary and for the orchestration to be capable of maintaining the binding of these.
Challenge 2 – Service chain modification
Insertion of a new function into a service chain takes too long and interrupts service. The cloud provides an easy ability to create new functions on demand. Rather than trying to make Openstack enable hot wiring a new function into an existing chain we could instead pre-create a new service chain and switch over when ready via a proxy. As an interesting aside the use case given in the webinar is for insertion of a load balancer. Possibly the load balancer and its brother the reverse proxy should be seen less as an additional sold capability but rather as an inherent capability in the service chain to enable its horizontal scalability and change.
Adopting this changed approach require a view of orchestration beyond simply implementing a service cascading from an initial order. For this to work it requires orchestration of each function throughout its service lifecycle with many of the features currently in separated OSS being integrated and encapsulated with the VNF.