Did Juniper pay too much for 128 Technology? That’s a question that’s been raised by some financial analysts, by some who hold Juniper stock, and by at least one industry pundit, HERE. It’s not unusual for some to question the value of an acquisition like this, particularly in an industry that’s not been a dazzling success at exploiting the M&A they’ve done. It’s a good thing, in fact, because the best way to prevent failure is to understand that it’s possible.
Since I blogged that the Juniper deal for 128T was a smart one, it’s important that I have a response to criticisms of the deal, not only to justify my view but also to guide the two companies toward the symbiosis that could make the deal a great one for all involved. I’ll do that by looking at the article and dealing with its comments.
To me, the article is questioning three points that justify the deal, and the implication that the justifications aren’t compelling. Let’s look at them, then, first as a list, and then in detail. The first is that the 128T deal is part of Juniper’s desire to be more software-centric. Second, it’s a way of exploiting the SD-WAN market, which has a very high growth rate. Finally, it’s because 128 Technology’s smaller compute footprint makes it an ideal SD-WAN solution.
If anyone out there doubts that networking is getting to be more about software than hardware, they’ve been living in a time warp. AT&T made a public decision to move to white-box-and-software networking a couple years ago. Even the 3GPP standards, never ones to be on the leading edge of technology shifts, embraced a virtual implementation. OpenRAN is software-centric. It would be truly frightening if Juniper didn’t think it needed to think more about software, but the fact is that they’ve been doing that for some time, and so has arch-rival Cisco. I don’t think that they’d use the “we-are-software” argument to justify a deal like this, but let me get back to this point.
OK how about the SD-WAN market, which the piece says is growing at a CAGR of 34%. Could Juniper be jumping onto the 128T bandwagon to get a piece of the action? Actually, Juniper had an SD-WAN solution already, but it certainly wasn’t something that was sweeping the market. The biggest consideration, though, isn’t as much to grab a share of the market, but to track where the market is going.
SD-WAN is a terrible name for a market that’s actually evolving to be something very much more. My own regard for 128 Technology was based on its potential for that “very much more”, which is (and was) “virtual networking”. The majority of SD-WAN products and services don’t do anything more than connect small sites to a company VPN, or perhaps offer some cloud networking. That’s shooting way behind the market-evolution duck at this point.
Networking has never been about sites, it’s always been about people. Companies pay to make workers productive, and because workers are concentrated in workplaces, we networked workplaces. The thing is, the goal was never to make networks about sites or traffic, but to make networks about facilitating relationships, relationships between people, between people and applications, and even between application components. If you read what I’ve said about 128 Technology, that’s what they do, and what they’ve done from the first. That’s their strategic story.
Which leaves us the last point. The article quotes Andy Ory, co-founder and CEO of 128 Technology, saying ““What separates us from every other SD-WAN player in the world is that we have a much, much smaller computational footprint and we leverage the underlay. We don’t instantiate really costly, computationally expensive tunnels.” If this is their true differentiator, it means that 128T offers better plumbing, which might not be a great basis for a deal with Juniper.
It isn’t the true differentiator, in my view. From the very first, well over two years ago, I pushed back on even 128 Technology’s own quotes and stories about “lower overhead” and “no-tunnel” differentiation. The reason is that to take SD-WAN into virtual networking, those aren’t the right drivers. The key to 128 Technology’s value is session awareness, as I’ve said from the very first. There is value to lower tunnel header overhead, and to lower compute overhead in terminating tunnels, but the value is derived because of the limitations that high overhead could impose on session awareness. Without session awareness, those other points are like arguing over plastic or copper pipe in the wastewater plumbing mission.
A session is a relationship, a communications path that carries some kind of value. For enterprise applications, sessions represent information flows that support (in some way) worker productivity. They are why we have applications, why we build networks, because without them we can’t deliver information to information consumers and enhance their productivity, their value. Sessions are, in the OSI model, a “higher layer”, and in the OSI model, we often forget that the lower layers (including Level 2 and 3 where all the attention in networking is focused) are just plumbing to carry sessions.
Every application access is a session. Every video you watch is a session, and so are your Zoom conferences or VoIP calls. Given that sessions are the foundation of network value, you could almost be justified saying that something that was aware of them, could handle packets based on that awareness, had to be better than something that wasn’t, and couldn’t. You don’t have to, though, because there is solid value to both session awareness and session-based handling. If Mist AI is about optimizing, then what better goal to optimize toward than sustaining the combined value of sessions?
The quote that sums up the piece is this: “Raymond James analyst Simon Leopold reflected my thinking, saying the deal was expensive but that Juniper pretty much had to do something to stoke growth in its software story.” I can’t understand that view at all. Most enterprises probably wouldn’t even classify SD-WAN as “software” since they’d get it delivered on a device. In any event, there is no network company on the planet who has a “software story” in a cohesive sense, because there’s no cohesion to network software. Finally, if all you want is software, simply adopt some open-source tool and sing like a bird in front of the media. The whole “software” story for network companies was pushed out by stories, not by network companies. They’re just going with the flow while they work feverishly behind the scenes.
Toward what goal? What network companies are trying to do is to reduce their dependency on proprietary appliances, things like switches and routers. They’re doing that because switches and routers are the target of buyer initiatives to reduce cost and vendor lock-in, in a market that seems to buyers to be demanding higher prices when there’s no compensatory higher value obtained. White-box switches and open-source software are eating what we could call “vanilla” routing and switching, because everything with a static feature set gets commoditized. There is now, and there never has been, any escape from that.
That means what you need is a dynamic feature set. Dynamism, though, has to mean changing in the right direction, not just blowing hype waves out of your PR department. If there is a right direction in networking today, it’s maximizing the application of resources, and the response to problems, based on the revenue associated with what’s being impacted. That’s just another way of saying “session awareness”. If you know what relationships a session is supporting, and if you know what sessions make up a particular assembly of “traffic” that needs handled, you know the value of the traffic and how to trade resources against it. Juniper’s Mist AI platform is all about using AI to manage networking. Wouldn’t adding session-awareness to that be a big step forward for Mist AI, and for Juniper?
The last sentence of the piece is “Long-suffering Juniper investors may now have to look out to 2022 to see the elusive boost in earnings and growth.” If the article is correct, and if Juniper is doing the 128 Technology deal to get a “software story”, they could be right. I’m hoping, and in fact I’m predicting, that the story is really about session awareness. I’m also hoping that Juniper is as insightful about the potential of 128T’s stuff as they could be, need to be. That they might not be is the biggest risk to Juniper’s investors, not the deal.
There’s an alternate story here, another possibility for the ending that the ending; “long-suffering Juniper investors” may now have a credible path to the differentiation that the securities analyst told. One that could lead them to a boost in earnings, growth, and share prices. A path they’re never going to have if they keep hunkering down to defend the box business or mouthing silly platitudes. I’m not saying that this is a slam dunk; Juniper doesn’t have a good record on M&A, and because there are financial analyst mutterings about the price, it’s incumbent on Juniper to deliver some clear value here. But this is the most promising thing Juniper has done so far, period.