Many people recognize the phrase “e pluribus unum”, normally translated as something like “from many, one”. It’s the motto of the US, but it’s also a kind of de facto motto for buyers of technology. They need one data center, one network, and they’d like to make it from pieces supplied by many. Or would they?
Historically, buyers have indeed wanted multiple suppliers for most anything technological. It “keeps vendors honest”, it “guarantees we get the best price”, it “lets us get best-of-breed technology”, and so forth. You’ve no doubt heard it all, and more. Recently, though, buyers have been increasingly concerned about the cost of the “pluribus” strategy. While there are still enterprises who believe the old adages of multiple sources, I’ve noted several times that recent data from enterprises says that many harbor doubts. What’s going to happen?
The first factor we have to consider is why enterprises want multiple suppliers to begin with. For devices, 81% of enterprises list “cost savings” as their first reason, “need specialized features not all vendors offer” is cited by 66%, and “conform to past deployment practices” (meaning making modernization decisions based on the vendor/device being replaced) is listed by 61% (more than one answer was accepted, obviously). What’s really interesting is that almost all (98%) of enterprises say that these reasons are less compelling today than in the past, and they expect them to be even less important in the future.
Integration issues are the primary driver of increased skepticism over the cost advantage of multiple vendors, but enterprises also tell me that playing one vendor against another is less likely generate discounts today than in the past. The integration side is really two pieces—the cost of deploying and managing disparate vendors is increasing as vendor management tools get better and multi-vendor tools fail to keep pace, and finger-pointing between vendors has been elevated to an art, making every issue an exercise in fault isolation and forcing vendors to admit/accept responsibility. One enterprise said that they’d had two roughly contemporaneous but unrelated network issues, one involving two vendors’ equipment and one involving a single vendor. The former took 3 days to fully resolve and the latter took 7 hours. How much cost savings is needed to overcome that sort of difference?
Specialized features, meaning feature differentiation, is also getting harder to find. Both network devices and computing tools tend to be standardized to a degree (interfaces for networks and APIs for computing), and market competition has honed every vendor’s offerings to a common requirement set. Enterprises say that management and security features are the major areas where feature differences still exist. In “minor product areas”, the category in which enterprises put things like SD-WAN, there are sometimes “significant” differences between vendor offerings, but these products are difficult to mix in a network because the architectures are rarely fully compatible.
For network services, things are at least a bit more straightforward. The top reason why enterprises say they use multiple providers is simple geographic coverage, cited by over 95% of users. Cost is the next-most-common reason, cited by 74%, and reliability is cited by 61%. These numbers have stayed largely constant over the last 30 years, and enterprises aren’t reporting the kinds of integration problems and management problems with multiple service providers that they have with equipment.
There is an exception to this, and a growing one, and that exception is in VPN extension services based on (yes, again) SD-WAN. About a quarter of enterprises say that they have some sites connected to their VPNs via an SD-WAN service, currently most often from an MSP but sometimes from one of their major service providers. If we look at this subset of VPN users, we find that 31% of them have had integration and management issues relating to their extended VPN, where only 6% of enterprises overall say they’ve had issues with service integration. The unified VPN, consisting of MPLS services from a main provider and SD-WAN services from a secondary provider, is said to be more complicated to manage and to generate finger-pointing in problem resolution.
If we sum up what enterprises are saying, we find that multi-vendor, multi-source networking has supporters, but that in all areas there is a growing sense that the old “pluribus” approach may not be serving network users as well as it has in the past. If you ask users what the source of the problems is, the answer you get most often (92% of the time) is management. To these users, that includes visibility, the ability to see the network as a whole and then drill down to the parts, and problem isolation and resolution, which exploits visibility through reconfiguration and repair.
The desire by vendors and even service providers to differentiate their products/services has tended to focus both groups on two things, ancillary features beyond the “baseline” standardized stuff, to raise value and management features that reduce opex and so reduce TCO. Both these things are impacting multi-vendor, multi-provider, models of networking by making integration more difficult and expensive. Where the two combine, which happens in SD-WAN, we have a greater-than-average risk associated with mixing product and service sources, and user comments prove that.
Users believe that vendor-specific management tools are better than generic management tools; 83% told me that, but roughly a quarter of these said that they still would “prefer” a generic management product because they were fearing a kind of management lock-in. Even this group doesn’t believe that generic management will catch up with vendor-specific management, and that’s even without considering any special “ancillary features” like SD-WAN.
One question raised by all of this is how it might impact future enhanced features and services, and a part of that is dependent on how vendors react to the situation. Enterprises say that some vendors are more effective in addressing these challenges than others. Cisco is usually rated as using management to discourage competitive vendors’ introduction into networks. Competitive vendors are said to be looking at “autonomous zones” (to quote one netops professional) where a technology-specific or geographic piece of a network is managed as a kind of virtual device, resolving all its issues internally and reporting itself to a higher-level management system as needed. Those buyers who have tried this approach seem to like it, and even believe that it’s really the way that future management systems could be integrated to benefit users, without sacrificing vendor-specific benefits. Get specific in those autonomous zones and be generic between them.
All of this points to an intent-modeled management approach, because what intent models do logically is to divide functionality into sub-areas that can be managed internally and independently and report failures they can’t fix to a higher-level process that can presumably remediate. I think the market overall is slowly evolving in that direction, but I also believe that this model is seen by many vendors as a threat to their dominance because it dilutes the value of management differentiation. We’ll have to watch the space to see what develops, because users for sure are watching.
