So-called NaaS-lite options already exist. They allow customers to establish ad-hoc virtual private network (VPN) connections using a cloud consumption model. End users define the different points of the VPN through a self-service portal; the VPN itself is managed by the NaaS provider. For all its benefits, however, this approach provides only limited usability to next-generation applications looking to take advantage of programmable networks.
One of the primary advantages of cloud-based delivery is that cloud-aware applications are able to elastically use the underlying infrastructure. Today, from a programmatic perspective, both storage and compute are completely elastic. From a network view, work still needs to be done. This is where NFV and SDN come into play. Without getting into the debate of a network overlay versus a program interface to the physical network, the concept of allowing the application to control the infrastructure is universal.
NaaS lets users provision and control services
From a private data center vantage point, applications should be able to provision services such as load balancers and specific security profiles. It's that extension beyond the data center that SDN becomes a much more interesting solution. In true NaaS deployments, the customer can provision and control network services that have traditionally been bound by the legacy service-level agreements offered by traditional telecoms. Future NaaS offerings will potentially have an extremely fast access port into your provider's cloud. To that end, this access port will serve as an extension of your data center. Within this framework, the application will make calls to the provider to set up and tear down multiple point-to-point network connections as needed.
This capability will go beyond what we see in today's VPN-based NaaS. In their future state, applications will be able to consume specific wide-area network-based services for the duration of time required by the application's load. For example, a video stream service could burst from a guaranteed rate of 1 Gbps to 10 Gbps during a special event such as a town hall. Not only would the bandwidth increase, but the application could request end-to-end quality of service throughout the cloud network just for the duration of the broadcast. Post-broadcast, the circuits could be torn down or regulated to a lessor service.
The modified consumption-based service is accompanied by a measured cost model. This way, the future NaaS will walk hand and hand with cloud and compute in scaling applications. Yes, challenges exist, and chief among them is the need for enterprises to embrace SDN and NFV.
Service providers have own set of NaaS challenges
That said, NFV is passing the whiteboard stage and entering the early adopter stage. Web 2.0 companies such as Google and Facebook already have these services on their private networks. In the enterprise, vendors such as VMware and Cisco are making inroads to persuade IT to roll out their individual versions of SDN.
When it comes to new networking techniques, the more difficult challenge will be service providers. Dynamic NaaS is a much different service and revenue model than what exists today. Service providers not only will need to embrace SDN but also the tools to manage the unpredictable nature of services being consumed. In addition, providers will be challenged to develop a cost model that enterprise customers will be willing to bear. Uncontrolled use of metered network applications could result in sticker shock if server instances aren't effectively monitored.
Overall, I believe these challenges can be overcome. But enterprises will have to take the first step.