I’ve commented in prior blogs that the output of what we call “SDN” or “NFV” would, in a functional sense, but a kind of network-as-a-service or NaaS. NaaS implies that services are created through some API process (the service API) rather than being simply in place as an attribute of cooperative device behaviors. Since you have to set up an SDN or NFV service, it’s fair to characterize that service as “NaaS”, and in theory something designed for NaaS could have both SDN and NFV implications.
It’s been hard to judge just how valuable NaaS could be as a conceptual unifier of SDN and NFV because it’s not presented that way. That may be changing; Anuta Networks seems to be articulating a general NaaS approach to SDN and NFV. It’s a bit rough at this point, but you can see the direction things might take.
If you wanted to idealize an NaaS model you’d start with the notion of an abstraction, a model that represents the functionality and properties of the service. Building these abstractions might require a tool. Another NaaS tool would then convert that abstraction into a set of resource commitments through the process you’d normally call “orchestration”. Finally, the abstraction would describe (and by reference commit) management resources to engage with the service during the lifecycle to support operations processes.
The Anuta approach mirrors this NaaS framework. The NCX architecture has a controller and agent element that cooperate to push centrally defined models/policies/parameters to places where network behavior is created. The models or abstractions are built using a Service Design Engine drag-and-drop interface that lets an architect pull in functional elements and snap connections between them. The architect can then specify the way each element is to be realized on infrastructure, including whether to use virtual or real components and how to set up various vendor devices. The functional elements can represent connection networks (level 2 or 3) and also higher-level components like firewalls.
When you have a functional map of the logical structure of a service, it becomes orderable by a user/customer, and when it’s ordered the Service Orchestration Engine of the NCX architecture will build and connect the functional components. This element operates through a series of low-level “plugins” that adapt the setup recipes to specific vendors and technology options, including whether the element is to be created by parameterizing a real device or by deploying a virtual component. A Service Management Engine then monitors and enforces SLAs and a Capacity Management Engine manages the infrastructure or resource pool.
If you take this approach in the SDN direction, the interesting outcome is that you can build NaaS/SDN services using whatever infrastructure you have (you do need vendor-specific recipes, which I’ll get to). You can also use an SDN controller and OpenFlow and you can use virtual elements, presumably either as vSwitch-like components or NFV virtual network functions. Thus, Anuta is supporting an almost-Cisco-like vision of SDN as something that’s driven from the top, the service layer, and that can then exploit both legacy infrastructure and SDN-specific stuff.
In the NFV direction, it’s easy to see that applications like service chaining fit this model exactly, but it’s harder to say whether the full, broad, generalized goals of function virtualization would fit as well. The issue is how the functional atoms that can be assembled are built in the first place. If I decided I wanted to have a function called “widget” that I could assign to a virtual-hostable element, NFV principles would say that I could define it and sell services based on it. For that to work in the Anuta NaaS model, they’d need a “widget-builder” tool that would define the detailed properties of a new object. The company says they have such a tool for internal use, and it’s very possible this will be made public as they pursue NFV more actively.
Just what Anuta would elect to support in such a widget-builder element might be their biggest question, the doorway to their big opportunity, and not just with NFV. It’s not desirable that a NaaS software vendor be a choke point in introducing services, but if there aren’t tools to build/onboard new elements the service scope will be limited. Obviously Anuta has a complete tool available for internal use, and if they expose all the features and build in some safety checks, they’d enable at least partners and more savvy users to create widgets for composition into NaaS. That would be the smart option in my view but we’ll have to wait to see how Anuta evolves their toolkit.
I think this NaaS-Anuta model demonstrates the value of taking a top-down approach. A “service” is made up of a set of “functions” that are in turn orchestrated into resource commitments. From this perspective it’s easy to see each of those resource commitments as a laundry list of optional directions based on topology and policy, which means that it would naturally support both “coerced functionality” from real network devices and “hosted/virtual functionality” from a software component. This makes mixing legacy and SDN/NFV elements natural and almost automatic, which is how it should be. If our widget tool were to allow operators to onboard legacy service functionality and then compose it, the NaaS concept could even be applied to networks with neither SDN or NFV elements—just to improve operations. Anuta is still weak here; they haven’t announced an explicit model for OSS/BSS integration overall, much less formalized the widget tool.
The NaaS model also has the advantage of being a fit for both enterprises and operators, and being fairly elastic in terms of how big an enterprise you’d have to be to justify it. NFV isn’t exactly a populist notion at this point, and there’s no movement in the standards process to embrace enterprise applications except by accident. NaaS, in contrast, has wide utility but it’s a bit formless today—you need to embrace something specific (like NFV) to realize it, and the specificity then limits the scope of buyer interest. An unfettered NaaS vision creates a larger target market and potentially more benefit to doing orchestration and management right, which could be a step toward making the right kind of orchestration and management features available.
It may be that the challenge for a NaaS-centric view of SDN and NFV has the unusual disadvantage of little media and market traction. Those limited and specific things, SDN and NFV, have grabbed the glory but failed to address the full value proposition. It may also be a challenge for Anuta to present a NaaS vision, for many of the same reasons. The company’s visibility in the media and in our most recent SDN/NFV survey was very limited, and given that it may be at risk should a bigger and more articulate player (Cisco comes to mind) step up and tell the story better.