There are two primary reasons why hyperscalers have taken over the mantle of leadership in networking:
Hyperscalers have disrupted all of IT
Telco is not a growth market for infrastructure suppliers (Note: 1)
Given this leadership, it is natural for all network managers to ask the question, should I run my network the same way Google does? The short answer is, not every company is Google. The longer answer is, hyperscalers are driving industry trends, which requires every manager to examine how they approach networking, and if their suppliers and operations groups are aligned with those trends.
IT Disruption
Discussed previously, the two primary axis of disruption by hyperscalers: customer experience and operations excellence. Relevant to this discussion is the issue of operations excellence, though clearly they are entangled.
The 30,000-foot view of hyperscaler architecture: simple IT units (storage, compute, networking) combined with highly capable operations software. It is easier to hyperscale if you keep the units you are scaling simple, repeatable, and consistent. Less variation to deal with in the operations software.
Figure 1. Hyperscaler architectures take capability out of the network and put into operations systems.
It is important to note that hyperscalers can do this successfully because they have both the operations capacity and the operations capability. This is core to their business. Born-in-the-cloud capabilities combined with the operations capacity, as they grew, to make these architectures work.
Figure 2. Hyperscalers have a high-level of operations capacity and capability compared to other networking segments.
But I Am Not a Hyperscaler?
Correct. Most network managers do not have access to the operations capacity, and perhaps even the capabilities, of a hyperscaler. Smart people. Know a bunch about networks. But the whole born-in-the cloud operations thing is another trick on a different dimension. Pack up your bags and go home?
For some network managers the answer is sign a managed SD-WAN/SASE contract, let someone else run the network. There are bigger fish to fry for the company they work at. That is one way to adopt the controller/controller-like trend in networking.
For others, still responsible for an underlay network, the answer may lay in leveraging a controller provided by a supplier. Most network managers are not going to build their own controller. Adopting a controller (and associated analytics/automation) may not get the network operations up to the capacity and capability of a hyperscaler, but it may add value, and it may put the network on a course to aligning with industry trends.
Figure 3. Moving to a new operations coordinates by leveraging technology.
Will The Transition Be Fast, Slow, or Never?
While the hyperscaler approach has disrupted all of IT and is pushing many aspects of networking in that direction, that does not guarantee a fast or inevitable transition everywhere in networking. Not everyone can build and maintain a controller. For supplied controllers, there is a period of uncertainty followed by broader adoption.
Figure 4. Uncertainty and Information
Significant changes create significant uncertainty. As Information Theory has taught us, uncertainty is reduced by information. It is the same with the adoption of innovation. Proof of concept, word of mouth from trusted influencers, press accounts of successful deployments, etc. This is all information that accelerates adoption as innovation crosses the chasm to mainstream adoption.
SD-WAN appears to have good momentum at this point.
How SASE will play out is not yet clear, though we could all speculate on various M&A potentials (the “Chessboard”).
Network managers adopting controllers? Not clear.
My intuition is that controllers are not yet being installed broadly by network managers. Some have for sure, including some large telcos with significant operations capacity. I suspect there are still some large chunks of uncertainty that have to be dispelled. If you disagree, please make a comment. I am interested in feedback.
Buckets of Uncertainty
The IP Networking ecosystem has been largely in a range of ambivalent to hostile, during its history, with respect to centralized approaches to network management. To some extent, IP routing exists today because of that. Would the Internet exist today, as we know it, bootstrapped by so many small network operators / operations groups and Enterprises, if an operations team had to manually configure every route directly into a router or via a management system? In the days when IBM’s SNA ruled the enterprise landscape, each route change required that a software program be compiled, linked, and loaded into the network equipment. That is about as far from autonomous topology discovery as you can get. The existing level of autonomous behavior in IP networks have made them what they are today.
Perceptively, “relying” on controllers is a big change, which, as stated above, generates significant uncertainty.
The two big areas of uncertainty that I feel have to be tackled are:
Does the controller paradigm deliver better outcomes than the current way of doing things.
How mature is the controller paradigm.
Both of these topics are articles in their own right. I touched briefly on some of this in the article: Segment Routing Solution Criteria. The net from those articles is that there are some cases today where a global view provides advantage. There will be a stronger case when Controllers are ingesting, at high rates, information not currently in the control plane, and doing something value-added with that information. These are the conversations network managers should be having with suppliers, and these are the conversations that I feel will accelerate the adoption of controllers, more broadly, than entities that already have significant operations capacity.
Conclusion
To paraphrase an old saying, controller suppliers have to meet customers/prospects where they are. Different network managers have access to different operations capacities and capabilities. The best solutions will accelerate controller adoption by filling those gaps, to a level that is sufficient for the mission/goals of the customer’s network. This will happen over time, in a paradigm that can be best be described, IMO, as augmented routing.
Note 1: This hopefully not controversial statement could do with some unpacking, but would have been a distraction for this article. The bottom line is the biggest, densest routers are built today for hyperscalers, and many SPs cannot consume that much capacity.