Network services are essentially bit pipes, meaning they move information around. Despite this basic mission, they do include other features to facilitate user identification and traffic steering, management, security, etc. Most of the debate about the network of the future is really focused not on the bit-pushing part of services but on these added features, and we're now seeing two competing approaches for them: one in the cloud and the other in the network.
What wins may determine the direction of New IP technology.
The cloud has, from the first, been a model for hosting applications or pieces of applications like microservices on a pool of abstract server resources, like virtual machines or containers. While cloud computing started with basic virtual machine hardware (infrastructure-as-a-service or IaaS) it's been evolving more toward a platform-as-a-service (PaaS) model, where application-useful features are bundled with the hardware to create a platform to facilitate development and deployment.
The PaaS model's dominant characteristic is a set of application program interfaces (APIs) that let applications use simple requests to do complicated things. Some cloud offerings like Microsoft's Azure offer a PaaS API set that is so comprehensive you can use it to write complete applications, and others like Amazon AWS offer special services such as caching or workflow management to supplement traditional IaaS models. These APIs inject some of the cloud's capabilities into the development of applications, making a "cloud application" more than just something running in the cloud.
The Question of APIs
PaaS features APIs that let applications use simple requests to do complicated things.
Network features are very similar to applications, meaning that a switch or router or firewall could be deployed as a software instance in a cloud. Features are implemented using traditional software development practices, connected with each other and with user endpoints using cloud-like virtual connections -- it's a lot like a cloud on the surface.
SDN and NFV: changing the landscape
Deeper down, though, the differences are clear. Networks are built from devices, and new network technologies like software-defined networking (SDN) or network functions virtualization (NFV) seem to virtualize the devices rather than the features. Neither SDN nor NFV specifications include a PaaS-like set of APIs that are designed to facilitate the development of new features.
The obvious reason not to include PaaS-like APIs into SDN or NFV specifications is that the service features already developed couldn't be expected to use APIs that didn't exist when they were written. That hasn't stopped the cloud's evolution toward adding features with APIs, though, and PaaS APIs can be critical even for existing functions/features.
Amazon has about 50 APIs defined to extend its cloud offering beyond IaaS, and all of them represent things that traditional application software developers would expect to be part of their operating system and middleware toolkits. What Amazon has done is created a cloud-enhancing version of these tools. In all cases, it lets the AWS developer build an app that runs better in the cloud, which is important if the cloud is to evolve. It's especially critical in the area of application lifecycle management (ALM), the science of deploying and maintaining the applications your business needs.
The shape of services
Services have lifecycles too, and just as cloud ALM must consider the implications of elastic virtual resource pools, so should service features and functions deployed for SDN and NFV. There are interfaces through which SDN or NFV service management could be exercised (SDN's fabled northbound interfaces and NFV's Virtual Network Function Manager), but both specifications have a common weakness; they define a simple management toolkit that pushes complicated issues across to the feature/function developer.
The contrast between the cloud and SDN/NFV raises two important questions. First, should features/functions for network services be treated like cloud applications, meaning they should be supported by a PaaS framework of APIs that offer the cloud version of basic middleware services? Second, should vendors or network operators be responsible for defining these PaaS or should there be some industry standard?
The answer to the first question seems obvious to me. If cloud computing is just a hosted form of virtualization it can't penetrate IT budgets nearly as far as it would if cloud-specific benefits could be written into applications. That's why Amazon and others are adding PaaS and APIs. It would seem the same thing would be true for SDN and NFV; we need to exploit the special benefits of virtual hosting and agile deployment and operations, and doing that means exposing those benefits to developers in the form of APIs.
The second question is more difficult. Applications written to use specific APIs won't run without them, which means a vendor-specific or operator-specific strategy to build a PaaS would generate features/functions that would not be portable without customization for each network they were used in. On the other hand, lack of a PaaS-supported toolkit to add enhanced cloud-centric features to SDN and NFV would tend to freeze both technologies into a mold of simply emulating current devices and constrain benefits and deployments.
We have rich PaaS developing in the cloud, and we are starting to see vendors offer PaaS platforms to enhance both SDN and NFV. Neither of the latter has really taken off, and if we can accelerate SDN/NFV PaaS, we might accelerate the New IP.
— Tom Nolle, President, Founder, and Principal Analyst, CIMI Corp.
. Follow him on Twitter @CIMICorp
. Special to The New IP