A View From the Road: Micro-Services Architectures and the Impact on the Status Quo

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:

• This is not a new conversation. Microservices were on the hype curve since 2015 when the world started to discover how organizations such as Apple, Google, Facebook, Netflix and others managed to iterate and innovate with speed and agility.
• The foundational principle of microservices is disaggregation. Rather than referring to the disaggregation of hardware and software (NFV), or the disaggregation of control and data plane (Software-Defined Networking), this disaggregation specifically targets the software stacks themselves.
• The goal to unlock value in a large application, like a network function, is to disaggregate it into a set of composable services. Those services can expose a set of APIs to applications or other services.
• Disaggregating software stacks has an innate impact on operations. Companies that have embraced and leverage microservices architectures require changes to operational processes and technical skill sets – most notably an increased ability to develop (or script) applications to take advantage of these new APIs. DevOps, and Continuous Integration / Continuous Development (CI/CD) principles are intrinsically linked to microservices conversations and processes ensuring stable development test and delivery.
• The net result of this effort is accelerated innovation, improved manageability, increased resiliency, and higher scalability.

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:

1. Performance
2. Scale
3. Latency
4. Feature differentiation
5. Ease of operations

And further differentiate their companies across another two:

1. Velocity of feature development
2. Services and support

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?

• Integrated Databases give way to Database as a Service
• Integrated Data planes become shared Data Planes
• Message Bus as a service (MBaaS)

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:

• Performance differentiation goes away (since software functions leverage a shared data plane)
• Scale goes away (since the infrastructure offers database services)
• Latency may go away (MBaaS)

The net result is that product and corporate differentiation in network functions are largely limited to:

1. Differentiated feature sets in the control plane[i].
2. Feature velocity
3. Ease of operationalization

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:

1. Truly understand this changing world – even if they don’t do the integration themselves, CSP need to really understand it so that they get the architecture right.
2. Be able to swap in new, highly-pluggable blocks to the solution easily, even if they get a software integrator to help pull in a new part to the solution their operational processes need to be able to quickly take this new block and put it into production.
3. Start adapting operational processes towards DevOps, most specifically incorporating a Continuous Integration / Continuous Development (CI/CD) process for network operations, with an end-goal of eliminating the periodic, lengthy maintenance windows in favor of an ongoing rollout of new functionality.

[i] Historically, features get commoditized as the industry adopts them and as standards organizations create specifications, so this is not sustainable.