Cisco has been a powerhouse in networking for decades, so when CEO Robbins says something at a big Cisco event, you have to pay attention. Most of the Cisco Live event seemed to focus on partnerships and opening of APIs for its Digital Network Architecture and intent-based networking initiatives, but there was a parallel move that I think might be more significant in the long term. It’s embodied in a quote by the Cisco CEO.
What Robbins said was that “We have to think differently about how we build networks”. Interestingly, the focus of Cisco Live seemed to be cloud networking, containers, and Kubernetes orchestration for hybrid clouds. It’s hard to escape the conclusion that somehow cloud and containers frame the “different” way Cisco (and presumably the industry) need to think. How, exactly?
There are two ways that Robbins’ statement could be taken. One is that the cloud and containers will play a role in building the network itself. The second is that the cloud and containers will somehow redefine network requirements in a very significant way, enough to change network services and practices. You could find truth in both statements, and Cisco may be admitting to both truths, but each would have a different impact on the industry.
We already have various initiatives, formal standards and open-source projects included, to use hosted features in networks instead of custom devices. NFV, which I’m sure all my readers know is something I don’t think will fully realize its potential, has been focused mostly on virtual CPE missions that are usually dependent on premises hosting of functions in universal, open, devices. In that mission, the difference between containers and VMs would be smaller, and frankly a totally different approach based on an embedded operating system would be even smarter.
Another mission for hosting of functions is linked with things like 5G, IMS/EPC, CDN, and so forth. All these are multi-tenant service elements and therefore would be easier to deploy and manage if they were treated simply as cloud applications, without any NFV veneer. In these missions, containers could indeed be useful if the functions weren’t too performance-centric. My personal view is that hosting in virtual machines creates too high an overhead to be optimum; container hosting would be more efficient and thus offer better price points and profits.
Despite the fact that container hosting in the cloud could well play a role in building future networks, I’m not convinced that’s what Robbins was talking about. First off, Cisco hardly benefits from a transition to hosting open features on an open platform. Second, I don’t think that the change is profound enough to say that you’re going to “think differently” about network-building. Fundamental shifts in how you build something usually come from the missions you’re supporting, which is the second of our possible meanings.
My conclusion is that Robbins is talking about the revolution in service requirements created by the cloud age. There is no question that virtualization in any form disconnects resources from features by introducing an intermediary abstraction. That’s what it’s supposed to do. There shouldn’t have been any question that the virtualization process, undertaken to generate agility and flexibility, would have an impact on the connectivity requirements. A component instance in the cloud, if it’s redeployed, is somewhere other than where it started. Its address was assigned to its original location. We have to make addressing dynamic in order to prevent the complexity in making network connections to agile components work from killing operations efficiency.
This thought seems to fit the partnership with Google on using Kubernetes orchestration in a hybrid cloud (consisting of private clouds and Google’s cloud, of course). Hybrid clouds (and multi-cloud) are places where routine redeployment and scaling can mess up connectivity because of the intrinsic conflict in IP addresses between what something is and where it is.
I think that Cisco’s cloud-and-containers strategy is related to a number of market truths. One is that in the public cloud service space, Microsoft is the player to beat when it comes to direct cloud service sales to enterprises. Amazon does really well in cloud services to startups and also as a provider of cloud resources to network operators, but because Microsoft has a foot in many data centers, it has been able to grow its base among the enterprises. Google, now decisively behind in the cloud overall, needs to catch up, and orchestration tools like Kubernetes can facilitate adoption of Google’s cloud.
Another market truth is that this can benefit Cisco too. Rival VMware made their own announcements, advancing their Virtual Cloud Networking story. If Cisco can use the Google deal to leverage hybrid cloud symbiosis with Google’s cloud to pull through their own private cloud solutions to enterprises. Google has been improving its “package platform” solutions for cloud computing steadily, adding new software and options. A hybrid cloud network model might counter VMware and make Cisco’s DNA the de facto leader in a more virtualization-friendly networking model.
That, of course, begs the question of what such a model would look like, and then the question of how it might be implemented. I’ve long been a supporter of the idea that the service network of the future would be a service-layer overlay, built as a virtual layer on top of current L2/L3 technology. This model was first suggested by a vendor (as far as I can recall) back about a decade ago when Huawei promoted its idea of a “Next-Generation Service Overlay Network” or NGSON at a meeting of the IPsphere Forum. That model was subsequently taken to the IEEE for standardization work, and never really got much traction. Today, overlay networks are based on things like SDN or SD-WAN.
The mechanics of a service-overlay network are well understood. You have an underlayment network service that’s connective—it touches the endpoint sites you need to provide service in. At each site, there’s a function (a hosted one or a device) that processes an additional header. It’s a destination for the underlay network, and it creates a hub from which overlay connectivity is then extended.
The question that Cisco’s remarks raise is whether, given the presumptive role of the cloud and containers in driving different network thinking, there’s more to it than this service-overlay-101 trivia. While there are benefits to simple overlay networks, the specific mission of supporting the kind of agility that virtualization and cloud computing bring needs more support than that. Basic-think, meaning connectivity-driven service overlays, don’t move the ball enough.
I’ve suggested that “logical networking” is what’s needed, and I’ve defined in other blogs (and in a CIMI Corporation report HERE) what that would mean. Could it be that Cisco intends to augment DNA to include the essential logical-network features? Perhaps, but it’s not Cisco’s style to present a revolutionary solution to something, just to present a revolutionary set of claims in an extravagant PR rollout, then ease into the actual delivery. Cisco likes to be a “fast follower”.
It might be time for fast-follower moves, though. As I’ve already noted, VMware’s Virtual Cloud Network already has the very mission that Robbins talked about, and certainly represents a different way of thinking about networking. Cisco has long been wary of VMware, and it can’t afford to let a new battlefront open in the networking space with VMware leading the charge. Since VMware left a lot on the table in its announcement (it went only somewhat beyond the basic overlay connectivity features we’ve had all along), Cisco could do a lot here by adding only a little.
So could a lot of other players. HPE, who competes with both Cisco and Dell in the server space, has no overlay model it can call its own, and doesn’t make virtualization-friendly networking a fixture of their positioning. The MEF, who proposes to define a service overlay layer (SD-WAN) in its MEF 3.0 model, could take the steps necessary to make at least a credible start to that initiative. Juniper could do something with its Contrail SDN solution, and any of several SD-WAN vendors could lock down the critical elements of the virtualization-friendly overlay service before Cisco gets around to the details (then, perhaps, get themselves bought, even by Cisco).
Positioning for a virtualization-and-cloud-centric future overlay service network has been tentative at best, up to now, but there does seem to be momentum developing. A big player like Cisco, prepared to do the heavy lifting in the market, could definitely move the ball. Based on what seems more a partnership focus, I don’t think Cisco will go all-out at this, unless they decide that the market is on the edge of becoming critical and they need to overhang it a bit. If Cisco had to develop the market in the first place, they’d be the one making it critical, so doing nothing would be easier. That puts things back in the court of Cisco competitors, and in particular VMware.
The Virtual Cloud Network story is absolutely critical for VMware, and Robbins’ comment wasn’t much more than a nice PR spin for Cisco. VMware cannot afford having it turn out to be something Cisco really takes seriously, unless VMware goes further, faster. Of course, the faster VMware runs, the faster Cisco runs as well. We’ve created market races, and markets, with less than that. Maybe we’ll do that with logical networking too.