Standards have had a profound impact on the evolution of networking. TCP/IP, BGP, HTTP, SMTP — all of these have enabled the creation of the Internet, content hyperlinking, and personal communication. In recent years, it seems standards have had a diminishing impact, specifically when created by a diverse group of industry players. Due to a maze of conflicting commercial interests and protection of market positions, standards take forever to form, and often fall short on accelerating the markets they aim to serve.
NFV: Standards Development Gone Wrong
A good example to look at is network functions virtualization (NFV). NFV was supposed to revolutionize the way service providers deliver networking and security capabilities to end customers. By virtualizing routers, firewalls, SD-WAN, and WAN optimization appliances as virtual network functions (VNF), agility and responsiveness to customer needs would improve and costs would drop. This vision, however, required the introduction of a common management and orchestration layer that abstracted the underlying VNFs and eliminated proprietary policy engines.
This is where the standardization work got stuck in a conflict of interests. Eliminating policy management at the appliance level would diminish the value of a VNF’s brand. It would be easy to swap VNFs for competitive offerings, at the customer’s or service provider’s will. VNF vendors have no intention of letting that happen. As a result, NFV orchestration works at a high level, managing the virtual appliance itself, while a proprietary policy interface is required for granular VNF management.
This development
undermined the business case for service providers. While service providers benefited from appliance virtualization, they still needed to deliver the specific VNF brands the customers wanted and the expert staff to support these brands’ proprietary management. The result? NFV rollouts slowed to a crawl, and in 2018, four years after the first NFV pilots, most service providers had not rolled out the NFV platforms, as they struggled to justify further investments.
What solutions do service providers have to the NFV challenge?
One option is for service providers to try and force VNF vendors to move to a microservices architecture, which breaks the appliance form factor and the need for proprietary management. To drive this transition, service providers can refuse to work with certain vendors or threaten to move to smaller vendors if the incumbents will not comply.
Another option is to create a common management infrastructure using existing APIs in incumbent products. This can mask the complexity of everyday management but could make troubleshooting more difficult in case the underlying VNFs falter. This approach also depends on the goodwill of the incumbent vendors managing and evolving their APIs.
A third option is to acquire VNF vendors and integrate their solutions into the NFV offering. This is not a trivial task and requires substantial engineering effort and time. Moreover, this approach would put service providers in direct competition with strong software and hardware companies on features and functions that aren't a provider’s core competency.
Ultimately, service providers are integration experts. They aren't specializing in product development in domains like networking and security and are therefore dependent on their product OEMs. Even as they move to new platforms like SDN, they merely repackage proprietary products in new ways. This is why the industry remains in a deadlock of conflicting interests that no standard work can help resolve.
A New Frontier: The Software-Defined Carrier
The ultimate answer to the NFV challenge is the convergence of service providers and product OEMs into a new entity: the software-defined carrier (SDC).
To understand what the SDC is, it’s best to look at other categories that went through the same transformation. Take servers and hosting, for example. It used to be that product companies built servers, and hosting companies racked those servers in data centers and provided a set of services around them (power, cooling, connectivity, monitoring, etc). The customers were responsible for the integration of the offering, choosing the servers, getting them hosted, and then maintaining the operating systems and application software that run on them.
Then Amazon Web Services stepped into this environment. It offered a simple, converged platform that erased the demarcation lines between the product (servers) and the service (managed hosting). The industry had shifted. One could argue, at the time, for the value of server brands (like HP and Dell) versus do-it-yourself compute. We now know that this had no material relevance to customers. Furthermore, freed from the chains of proprietary components and integration efforts, AWS’s feature delivery and pace of innovation created an unmatched platform for scalable, agile, on-demand computing. “Choose and integrate” suddenly looked like an archaic approach of the past, with little business relevance.
The SDC is the beginning of the same transition for secure networking. Instead of worrying about myriad components, complex integration, conflicting commercial interests, and rising costs, the SDC starts from a clean slate, building a new type of service provider that is powered by its own cloud software platform. This platform is designed from the ground up as a set of distributed multitenant microservices that can deliver enterprise-grade connectivity and security at a lower cost.
How can this platform match decades-old product and services brands? The answer is that the SDC only needs to deliver the capabilities customers need today to achieve parity. It has the benefits of hindsight -- no need to rebuild esoteric capabilities, or deal with the mountains of bugs fixes and patches that came along the way. And, the cloud platform accelerates feature delivery to a weekly or monthly schedule, a rate simply not possible for product companies and service organizations that move at a glacial pace with annual product release cycles.
The SDC is the AWS of Networking and Security
AWS started by servicing a small niche within enterprises: the developers. Fast forward a decade and a half and the federal government and major enterprises are running production workloads on AWS.
The SDC is starting by serving mid-market enterprises that clamor for the simplicity, self-service, and rapid evolution compared with legacy carriers and piles of point solutions. The trajectory is unmistakable. If the AWS life cycle and lessons learned are the guide, the value of the SDC will be continuously realized by ever larger enterprises. At the end of the day, simple, fast, and affordable always beat expensive complexity.
