Meeting with customers and partners, especially those who are on the edge of innovation, is always thought-provoking. Recently, in meetings with Communications Service Providers, the discussion often turns to the current limitation of Network Function Virtualization in addressing some of their long-term architectural concerns, I’ve often gotten into the debate that started with a simple question – “What About Micro-services architectures?”It might have been framed as “Cloud Native” or “Containers”, but really is the same core question regardless of terminology. The intrinsic question that I think is being asked – how do we simplify and isolate network functions, and reduce/reuse/centralize the valuable flow and state information contained within each network function?
What Are Microservices?
Before providing my perspective here, let’s level set on micro-services architectures. In the interest of keeping the blog short, I will direct you to a 2015 blog by EMC entitled “Five Things You Need to Know About Microservices”. The context in the blog is focused around an e-commerce application, but the same logic applies to any software function.
The blog calls out is a few things:
Applying Microservices to Network Functions
Applying the same design logic of microservices for enterprise applications to network functions requires us to first define some of those microservices. Today, a Virtual Network Function (VNF) is tightly integrated software application consisting of a data plane for bit processing, a control plane that programs the data plane based on events/information received, control logic, a database for storing state information, and a message bus for communicating between services. Those APIs are either closed (vendor-proprietary), or non-existent (boundary between software function is not exposed externally between services). This architecture has allowed networking vendors to continue to differentiate their product offerings across a number of parameters:
And further differentiate their companies across another two:
Such a model has persisted for the entire history of networking, both in the enterprise Local Area Network (LAN) and in the Wide Area Network (WAN), and has stretched across fixed and mobile networks from DSL and cable to 3G, 4G, and even the pending 5G architectures.
Going forward, with a microservices approach, we see that many of the core functions of a VNF may get disaggregated, with the potential that many of these disaggregation functions are commoditized in open source, turning what were once differentiators in a composed network architecture into infrastructure services in a composable network architecture model.
What microservices can we expect to become infrastructure services in the long run?
Not only does this microservices framework allow for disaggregation, it also allows for re-aggregation in new and exciting ways. Much like service function chaining allows network functions to be arbitrarily arranged in series, such Superservices allow services to functionally chained together in parallel. As such, a packet can be taken off the wire one time, replicated across a set of services (firewall, IPS, DPI, etc.), and analyzed against their individual rules (or control logic). If the packet does not meet one or more of the rules associated with the individual service, a packet handling decision (I.e., Drop) can be made.
I won’t go so far as to say that this architectural model is either imminent or ubiquitous. In fact, there is still considerable maturing of container networking that needs to happen. Further, not all network functions will fit neatly into the prescribed architecture, and we will find that network functions that leverage pieces of this infrastructure services framework while keeping other, more differentiated componentry, integrated.
The implication to the network function vendor community are as important to those facing the CSPs themselves (discussed in the next section). As a means of competing in an increasingly-disaggregated market, the levers of differentiation get smaller:
The net result is that product and corporate differentiation in network functions are largely limited to:
Historically, features get commoditized as the industry adopts them, so this is not sustainable. Maybe the only sustainability is feature velocity, meaning that pace of innovation, and ability to operationalize that innovation, is the only differentiator left?
The Industry Quandary
If you are a vendor who embraces disaggregation in all facets, the challenge is daunting – Can we build an architecture for communications service providers that is truly open, scalable and able to adapt as this future world unfolds. Can those communications service providers take the building blocks of the solution and swap them out as needed rather than getting a completely and tightly locked in vertical solution.
If you are a CSP who embraces disaggregation as a means to optimize around next-generation service delivery models, the challenge is even more daunting: Do I jump to a virtualized version of my network function (i.e. router, firewall, etc.) or perhaps do I wait a little longer until those functions are disaggregated into the infrastructure?
How Should The Industry React?
If we have learned one thing in the constantly-changing world of network communications, its that foundational paradigm shifts such as the one above seldom happen in real-time. Instead, they go through iterations all objectively targeting the ideal end architectural state. Perhaps the answer is to begin this journey with an eye on the end goal.
I think there are three things we, as an industry, and especially the CSP, can do now to prepare:
[i] Historically, features get commoditized as the industry adopts them and as standards organizations create specifications, so this is not sustainable.
|Update your feed preferences|