Editor's note: This is the second part of a series examining the role network as a service can play in enterprise environments. Part one discussed how NaaS looks in action.
A recent survey
Certainly, there's hype in any technology area, but a big part of the cynicism reflected here can be attributed to the fact that it's often difficult to determine the target value proposition for a new networking concept. It's even more important to determine when a new technology is not the best thing to consider. And that's true of Network as a Service (NaaS).
NaaS is a vision of networking in which connectivity requirements are created ad hoc rather than provisioned in advance. That's a departure from traditional networking, where an admin would install an application on the company's network and that app would inherit that network's connectivity and behavior.
In a NaaS future, the application itself would specify its connectivity and performance requirements and these would be provided when needed. It's this past-future difference that offers the best clues on when NaaS isn't the best choice.
To make NaaS workable, two things are needed. First, it requires a specific notion of a "service" as a dynamic relationship between users and applications and networks. Second, it needs a mechanism for creating such a relationship on demand. In some cases, both will be found, but today it's probably more common to find that neither exists, and that's an indication that NaaS will be hard to validate.
NaaS requires dynamic network services
In NaaS terms, a "service" has to be something that occurs more often than, say, when a company adds an office location or server farm. There are two ways in which more dynamic network services emerge today. The first comes from network operations processes where virtual network communities are defined to hold groups of users or resources. The second is when applications or IT software request network connectivity directly.
Some companies will establish virtual networks or "sub-networks" to separate secure applications, partition company resources from Web servers or respond to things like videoconferences. These services are almost always managed by network operations and thus can be identified by checking with the operations center to see what regular changes to network configuration are made. Where changes happen rarely, there are likely few dynamic services being created at the network level.
Application-level service awareness can be harder to detect. A good way to start is to ask yourself this question: "Do my applications or my application deployment practices have an understanding of their connectivity needs?"
For example, is a particular application responsible for identifying its users or are user-to-application connections created or facilitated through deployment or integration tools? To "order" NaaS in any form, it's necessary to be able to define the connectivity goals being requested. Many companies have no application-specific network connection or deployment processes and thus would have no way of knowing what a given application requires.
Finding service awareness is key
There are two ways of finding "service awareness" in applications and deployment: find the deployment tools and find the network management interfaces. Companies that are either deploying nor planning to deploy private cloud computing -- along with those that regularly move applications or virtual machines as part of a virtual operating environment -- are likely to have the tools needed to specify their applications' network service needs.
In addition, those that use DevOps tools (Chef, Juju, etc.) or proprietary application tools can check to see if these control network changes as well as IT resources. If they do, they're at least potentially able to use NaaS.
The second question to ask regarding NaaS' value: "How dynamic are my applications?"
If there are few changes made to application connectivity due to changes in resource needs, user access or even seasonal variability in workload, there is little value to having dynamic network services.
A few key indicators for dynamic applications are the use of load-balancing (which implies dynamic changes in workload and thus in network needs), regular configuration changes in the network and frequent changes in server assignments to rebalance work or applications that have highly variable rates of use. If none of these is present, then the value of NaaS is diminished.
Exploiting the value of NaaS
The final question to ask is this: "Can I take advantage of NaaS in any specific way?"
Even where it may be possible to create a dynamic network service, is there a value to doing so? NaaS value can be indirect -- it facilitates security or simplifies operations -- or it can be direct, in that it is linked to the price paid for network connection.
Operational benefits gained by partitioning networks by application or service can be significant, but this kind of partitioning can also make it more difficult to build integrated applications that combine data from multiple sources or to build unified communications applications.
It's important to draw out any proposed application or service network structure and show where and how interconnection with users and with other application components can be provided. If everything can be worked out, then assigning quality of service (QoS) to specific applications or services may be easier with a NaaS approach.
More Network as a Service resources
SDN vs. overlay networks: What's the difference?
Cloud API questions answered
Can Virtual Extensible LAN solve the VLAN problem?
Service providers are already offering limited NaaS offerings in the form of virtual local area networks or virtual private networks, but, in most cases, pricing favors longer-term contracts. To that end, building services by combining multiple NaaS offerings may result in much higher prices.
For now, it may be smarter to test the NaaS waters with internal segmentation of networks based on NaaS principles, particularly cloud-based virtual network services. After operator services mature and experience is gained in managing and exploiting NaaS, it may be time to consider a broader NaaS commitment.
This was first published in May 2013