January 8, 2018, Originally published on LinkedIn
If Network Function Virtualization (NFV) is a proverbial “moonshot” to enable Communication Service Providers to transform into more competitive and agile Digital Service Providers, we should take a page out of NASA’s book, or, better yet, from @Google X, which is described as a “moonshot factory”
https://spectrum.ieee.org/automaton/robotics/artificial-intelligence/astro-teller-captain-of-moonshots-at-x
Astro Teller of X recommends that ambitious projects tackle the hard problems first. This is sound advice, but we all know that most organizations are tactical. They make lots of expedient decisions for narrow scopes without recognizing that they may be moving further and further away from their high-level strategic objectives as the sum of those prior decisions constrains them. Hitting the wall always comes as a surprise because everyone’s heads were down and they couldn’t see it coming.
Incrementing a solution from simple, low-level, well understood problems (interfaces and components) to complex, high-level, poorly understood problems (complex, adaptive, distributed systems), is at best aspirational.
David Lloyd George, former Prime Minister of England
It’s why many in Telecom are now wondering how you get to zero-touch automation from a tightly-coupled, bloated, static middleware stack where every new problem is addressed by yet another project/component compounding accidental complexity of the overall solution.
While automating a closed, siloed domain is easy and has been done for decades (Google, Facebook, etc. would be examples of extreme automation based on ‘walled gardens’), the Operator environment is an “open-world” problem. The scope of a zero-touch automation system has to accommodate heterogeneous multi-vendor VNFs, arbitrary service compositions and diverse deployment targets and technologies, which are part of the Operator’s increasingly distributed and federated environment.
Through this lens you can see that Zero-touch automation isn’t really an NFV problem per se, or an orchestration or policy problem for that matter, it’s a dynamic interoperability problem, which despite the proliferation of standards and open-source, has not been addressed.
The whole point of zero-touch is ‘hands-free’ operations. By definition, if you have to manually code, integrate, configure everything in advance – you are not zero-touch! The zero-touch automation system has to take responsibility for finding and binding the right elements, on the right environment with the right configuration – its automating interoperability to realize contextually-motivated “intent-based” services. This is non-trivial, in fact – its unprecedented.
It requires a high-level machine-readable model to provide domain semantics so such a system can interpret events as they happen to automate real-time decision-making so it can optimize lifecycle management with such confidence that it can be left to run largely autonomously. The zero-touch automation system must enforce polices to maintain SLAs, balance and prioritize utilization of resources, and address faults and failures.
The model itself, can’t be static and hierarchical as is the conventional approach, otherwise the overall solution will be hard to change. To be agile, the model has to anticipate change of any element of the solution and evolution of industry standards that define the domain.
Of course, the implementation of the zero-touch automation system matters too. It must be highly-scalable, performant, and resilient as a Virtualized Carrier still requires Carrier-Grade solutions.
EnterpriseWeb was motivated by these grand Computer Science and Distributed Systems Engineering challenges and we tackled the hard problems first.
