When looking at the virtualization landscape in its broader sense I can’t help seeing that the real problem is agility or rather lack of it.
Take a look at SDN, whose main premise is to separate control from the data plane and thereby achieve high agility for its users. Same thing for NFV: abstract the software from the hardware and then combine and deploy software functions at will for high agility. So the operators, at least the bigger ones who have the least agility, are investing megabucks to deliver on the twin promises of SDN and NFV. What’s frustrating for them is that they are doing so lamentably slowly and in a decidedly non-agile manner.
In a sense it’s not so surprising. In effect, the operators are trying to re-engineer 15 years of painstakingly built managed services processes in a very short period of time. And they are doing so using a combination of new operational and management techniques, new albeit commonly available hardware, re-packaged software and co-opting their existing set of waterfall processes and organisational silos. This is like pressing on the accelerator with the handbrake on. Some, e.g. Verizon and belatedly AT&T, are trying to loosen the rigid structure of their organisations to create a more agile decision-making process and a Devops culture where network specialists and IT folk combine to break down internal barriers and loosen their internal disk-brakes.
It’s when we take a look at the arrival of SD-WAN that we see the real impact of lack of agility. SD-WAN vendors position their wares to enterprises with self-select portals, centralised policy control and the ability to take advantage of cheaper Internet links to deal with all the Cloud-based, Internet services that are swamping their traditional operator-provided WAN connections. This puts control and thus agility in the hands of the enterprises and this is precisely what they want.
The response of the operators to SD-WAN however is telling. As opposed to SDN and NFV, where they are re-engineering their processes with open APIs to (slowly) deliver on the promise of virtualization, they have taken a very different tack with SD-WAN. For the most part, they have:
- selected proprietary software technology with closed APIs
- accepted the use of proprietary appliances (the antithesis of NFV), at least initially
- deployed the aforesaid technologies from young and untested companies, prone as we have seen to takeover (e.g. Viptela, VeloCloud).
This seems bizarre at first glance but agility is the explanation. SD-WAN seems to offer a fast path to agility and the operators are prepared to abandon their normally conservative vendor and technology selection process to get a piece of the agility action. Sure, they are kicking the SD-WAN vendors to minimise the risk of vendor lock-in, particularly by insisting they unbundle their software and run it as a VNF. This so they can at least add other network functions to run alongside SD-WAN on their choice of white-box (e.g. Colt).
Two big questions remain though.
Will co-opting SD-WAN technology allow the operators to compete effectively with do-it-yourself enterprises and system integrators who can also distribute connectivity risk across multiple lines from different operators?
The real conundrum though is how to tackle the price problem. What is the package of MPLS plus Internet connectivity that can deliver additional value to enterprises at an affordable price?
Tackling these linked problems is going to be critical for success. It seems the handbrake will also have to be released in the Marketing departments of the operators.
