If software is driving networks and infrastructure, perhaps we need to look more at software architecture in relation to things like the cloud, SDN, and especially NFV. We’re seeing some indication that real thinking is happening, but also some suggestions that further thought is required.
Many of you know that I write regularly for Tech Target on software development and architecture issues. One of the persistent software architecture issues of the last two decades has been componentization, the dividing of applications into components or modules. In that period, the focus has changed from programming languages to facilitate componentized software to the concept of modules linked through network connections, or services. SOA (Service Oriented Architecture) came along about 15 years ago, and today it’s all about “microservices”, meaning even smaller components.
Componentization has also been an issue in NFV from the first. The ISG meeting I attended in April 2013 included a rather testy discussion of “decomposition”, meaning the division of features now provided in monolithic vendor appliances to functional components that could then be “recomposed” into virtual functions. Operators seemed to favor this approach, while most vendors were opposed—quite vocally in some cases.
This political-or-business-level reaction is predictable. The goal of any buyer is to commoditize everything they buy, and the goal of every seller is to differentiate their offerings. The notion that a virtual function set created from decomposed vendor physical functions would allow best-of-breed or open-source substitutions to be made is attractive to operators and repellant to network vendors at this level.
Not all NFV vendors feel that way. The 2013 discussion was led by a vendor whose product was designed to facilitate threading work through network-connected chains or paths. The incumbent network vendors, knowing that anything that opens up their own device logic hurts them, opposed the measure. It’s recently been gaining support again, boosted in part by non-VNF incumbent vendors and in part by NFV ISG participants who see composing microservice-based functions as something that increases NFV’s role and value.
OK, so if I put on my software-architect hat, just how far can microservices or decomposition or whatever you’d like to call it, actually take us?
If we visualize componentized software, we can draw a picture of how an application processes a unit of work (provides a response to a request, transfers something from a port to another) as being a bunch of arrows between component blocks. Each arrow means that one element passes something to another, and this has two impacts that are important.
First, there is no such thing as a zero-time exchange. If, in software, I invoke an external function rather than simply code the implementation in-line, I’ll always introduce a delay that represents the time needed to pass control, the overhead associated with that external function. For functions that are part of the same software package or image, this is a “local” call and the delay is usually very small, usually less than a millisecond. If the function is network-connected, though, then the propagation delay of the network has to be added in.
How much is that? It depends. Across the US, a single-fiber link would introduce about 25 milliseconds of delay. A multi-hop router connection of the same distance would introduce somewhere between 100 and 300 ms, depending on what kind of network (VPN, the Internet) you’re running. The important point is that every arrow in our little component diagram is an exchange that, if network-connected, adds the network delay to the end-to-end delay, the time between input and output.
Suppose we have a service chain of three elements. There are two arrows connecting them, and if both are connected via a network we’d, conservatively, 70ms per arrow, or a total of a 140 ms delay introduced. That’s not extravagant given typical Internet delays. But suppose now that we micro-componentize and generate 20 components and 19 arrows. We’re now talking about a one and one third second delay.
The second issue is that microservices typically mean framing applications not as a linear flow but as a master application that links successively to services provided by components. We now have not only the presumption of accumulated delay, we have the possibility that each master-to-component interaction will generate a round-trip delay because it has to get a response before it moves on. Our 70ms delay then becomes 140 ms per interaction, and we have almost three seconds of total delay.
Some data-plane exchanges are very sensitive to delay. Imagine, for example, a database application whose record-level I/O is separated via a network from the main application. If it does a million I/O operations, the delay accumulated is a million times the round-trip delay.
The point here is that it’s not good software design to segment things so much that introduced delay becomes a major issue. You’d combine the components into a single image to make the data paths internal, but that’s outside the scope of function-hosting as NFV defines it. In fact, to do it would require not only that you segment functions down to a low level, you’d have to enforce a common component structure across all functions or you wouldn’t be able to interchange the pieces. Every deployment is then a software development task, in a sense.
I’m a big fan of microservices, but not in data plane roles. I also have a kind of philosophical problem with the notion of promoting micro-segmentation of VNFs when the NFV software itself wasn’t designed that way and isn’t developing that way. Nor, at present, are the cloud pieces (like OpenStack) that are expected to be used. NFV and cloud software could and should be designed in a microservice-friendly way, so why not start with that?
The notion that current technology can be split into a bunch of interchangeable parts is attractive in the sense that it could reduce the influence of key VNF-centric vendors. If that’s the goal, though, then a sensible project on open source would make a lot more sense. I’ve advocated what I called a “VNFPaaS” model, a model where a library of open functions supports the development, deployment, and management of VNFs. Would this model be backed by VNF providers? Probably not, but they’re not going to back a microsegmentation model either. The fact is that microsegmentation isn’t going to solve any problems because the network-distributed form generates too much delay and the software-integrated form would require my VNFPaaS or every VNF construction would become a development project.
I think we’re losing sight of the ball here. Micro-segmenting VNFs except in specific control and management applications dodges reality. The goal of NFV isn’t to justify itself by tweaking the market to fit its parameters. It’s the other way around; we’re designing NFV here not designing the market. What will make NFV successful is now, as it has always been, proving out a compelling business case. Microservices in NFV and SDN control and management processes, and even in service control plane processes, is logical. In the data plane, I think we’d have to be very careful of our delay budget or we risk major problems instead of major victories.