I saw an interesting article on the HPE/Aruba “Software-Defined Branch” concept, and it raises yet again a question we’ve grappled with in tech for decades. The model is an expansion of the classic-of-today SD-WAN, but it’s an expansion in that other pieces are added/integrated to form a package. Is this the right path for SD-WAN? Do you create a winning strategy by applying a technology to a niche set of needs, or by generalizing to support the broad market trends?
There are a number of industry trends that are combining to create the need for a “service network” that’s a whole new higher layer of networking, not Level 4 of the OSI model, but rather a kind of super-Level-3 approach. “Super” in the sense of being “above”, and also in the sense of being “better than”. SD-WAN and some SDN products have been gradually morphing into this sort of mission, and I think that’s also what a software-defined branch should be.
There’s a natural connection between SD-WAN and branch networking, because an increasing number of branch or secondary business locations cannot be connected directly to a corporate VPN based on MPLS, either because it would be too costly or because the service isn’t available in the areas needed. SD-WAN supplements VPN connectivity using the Internet. It’s good that software-defined branches can do that, but it’s table stakes. My readers know that I favor a “logical networking” model as a superset of SD-WAN, SDN, and also branch networking, and it’s that standard I have to apply to Aruba.
The tag line for the story is that “Aruba’s Software-Defined Branch (SD-Branch) solution is designed to help customers modernize branch networks for evolving cloud, IoT and mobility requirements.” In terms of logical networking, this is kind of a “see your three bucks and raise you one” thinking. Branch networking is creating problems for enterprises, as I’ve noted, which is the first dollar. Cloud computing demands a whole new dimension of application component agility, so that’s the second dollar. Mobility creates agility on the user side, which is dollar number three, and the raise is IoT. What more can you ask? The story says that this “marks a significant advancement beyond pure-play SD-WAN offerings”, and it certainly marks a significantly different positioning and packaging.
What Aruba is doing is melding cloud-hosted management with a combination of SD-WAN and other features, including wireless, by packaging multiple elements for co-located installation. The goal is to create a service demarcation for branch locations, one that offers enterprises all the local communications-related features they need in a single piece, and then blends it with management.
Pulling a bunch of stuff into a single package isn’t exactly a strategic revolution. It’s clear that we’re evolving to a new model of “service network” or “network-as-a-service”, so is it coincidental that HPE/Aruba is moving after competitors like VMware/Dell and Cisco have already made announcements in the same logical networking space? Hardly likely.
I’m not knocking HPE/Aruba for providing more advanced branch connectivity. Where I get a little uncomfortable is in the “marks a significant advancement beyond pure-play SD-WAN offerings” statement. As I noted in my “stages of SD-WAN” blog, the SD-WAN space is evolving quickly, and the state of the art for SD-WAN is actually well ahead of the Aruba stuff. This is particularly clear when you look at the specific point the Aruba story makes about support for the cloud.
For years, cloud computing to the enterprise was hosted server consolidation. You needed to have the ability to access an application hosted in the cloud, so you need a convenient way of linking that application to the corporate VPN. Cloud support equals software SD-WAN client, in other words.
The problem is that hosted server consolidation isn’t where it’s at. The cloud is now the hybrid cloud, the multi-cloud, the elastic cloud, the failover cloud, the event cloud, and more. You need more than application awareness in the sense of being able to recognize certain IP addresses and ports so you can prioritize traffic. You need the logical network layer to be truly independent, mapping to physical connectivity only to the extent needed to deliver logical paths to a physical network service access point.
Independent logical networking means that you know who every user is, what every application is, what components make it up, how to follow components that are redeployed or scaled, how to decide who’s allowed to access what. This knowledge exists not at the IP VPN or Internet level, but in the logical overlay network. That means that the cloud’s agility, the user’s mobility, and everyone’s security is not an integrated function but an intrinsic element of the logical network. I don’t have to make a logical network secure; it is secure by how it’s defined. It’s mobile and agile for the same reason.
SD-WAN is a central piece, a valuable and even critical piece, of the Aruba story, but it’s not what it should be in terms of features. SD-WAN in its futuristic logical-network form should be the heart of the story, the thing from which everything else extends. If a network has to be retrospectively be made aware of users and applications then it’s not a user or application network, and that’s where we are going, with SD-WAN, SDN, cloud networking, branch networking, and everything else.
I don’t think Aruba is going to stop its software-defined branch evolution with this announcement, but I wish they’d built a more solid foundation before they jump into the IoT story. What exactly does IoT demand from a branch network? Wireless? That’s hardly enough to make something an IoT story, but I really don’t see much that could be said about “real” IoT requirements like event-handling. Do they propose to use traffic prioritization to improve latency? Not enough, in my view.
I think the competitive announcements in this space almost surely caused Aruba and HPE to rush things a bit, responding quickly initiatives from rivals. That’s too bad, because as I’ve said in the past, neither VMware nor Cisco really nailed down the key value propositions either. There was an opportunity here to leapfrog competitors, and HPE/Aruba didn’t take it.