Is There a Deeper Meaning To Cisco’s Exablaze Deal?

It may be that Cisco still has more to show us in their network transformation.  Their Acacia announcement, followed by Silicon One, was IMHO a big step toward a new model of networking.  It just could be that their Exablaze deal was another.

Exablaze is a company specializing in low-latency networking, meaning building networks that have a very small transit delay in packet-handling.  The company is best-known for its applications in the financial industry, both as a part of a high-frequency trading platform and in specialized applications relating to the mass distribution of financial data.

It’s not unreasonable to think that Cisco might have acquired Exablaze simply for its position in the financial industry, or to mark territory on an area where arch-rival Arista is strong.  However, Cisco already sells to that market, and while their own products aren’t as specialized to financial-industry requirements, it’s a bit unusual for Cisco to buy something that would compete with its own products.  There are a couple of quotes in the Cisco blog (a short one; most of the substance is in the areas I quote below) announcing the deal that could be indicative of a broader role, perhaps even a deeper one.

The first quote is “Network capacity and speed are today’s bread and butter for data intensive, highly transactional-based businesses requiring optimized bandwidth performance in industries and market segments like high-frequency trading (HFT), financial services, high-performance computing, and emerging AI/ML clusters.”  HFT, obviously, is a current opportunity, along with financial services in general.  High-performance computing (HPC) has been around a while, and so it’s fair to wonder whether Cisco’s mention of the space is an indicator that it’s going to grow.  Obviously, that would be the case with “AI/ML clusters”.

You can almost draw a curve from HFT to AI/ML clusters, growing as you move across the technologies to reflect the heady expectations for each.  In every case, we have current needs, but the question is whether any of them, even HFT, would be enough to make Cisco do an M&A at this critical point.  Is Cisco trying to buy some revenue?  Remember that Wall Street saw the Acacia deal as simply a way of getting better profits on the optical interfaces Cisco was already using.  I think the Cisco Silicon One announcement proved that was a shortsighted view.  I think it is here too.

The second quote is “Integrating Exablaze’s innovative products and technology into the Cisco portfolio will give our customers the latest field programmable gate array (FPGA) technology providing them with the flexibility and programmability they require.”  To me, this says that the FPGA technology, at least as much as Exablaze’s current products, are the justification for the deal.  That, of course, raises the question of what Cisco might be intending to do with the stuff, and I want to look at some possibilities here, as a part of a general “what-will-they-do-with-Exablaze” exploration.

One obvious Exablaze target is to add low-latency smarts to network interface cards in the Cisco product line.  Remember that Amazon’s Nitro model of cloud hosting proposed offloading a lot of I/O and network functionality to the interfaces.  Exablaze cards offer exceptionally low latency, which is critical for cloud applications, as we’ll get to in a minute.  Cisco could add this kind of capability to its own servers, make it available (as it already is, from Exablaze) to other server vendors, and get a bit of street cred in the cloud server space.  This mission would be logical, given that interface cards don’t directly compete with any of Cisco’s own products.

It’s also worthy to note that routers and switches typically use interface cards too.  Might Cisco be looking at enhancing its own products with custom interfaces, again for the purpose of lowering latency in handling?  Such a move could give Cisco an edge, and if you combine a low-latency network card with the low-latency Silicon One chip, you might have a whole new class of network device.

The second, and related, target area could be edge computing.  Remember that the only real reason to site hosting near the edge is to reduce latency; otherwise you’d be better off creating deeper data centers with larger resource pools.  It seems likely to me that if we do uncover commercially viable edge computing applications, the “edge” will actually be a couple of layers of hosting, likely including something on premises and moving deeper as the value of collective pools increases.  This kind of structure could benefit from edge devices with low-latency interfaces, and also from edge switching based on low-latency technology.

The edge, of course, is really just a piece of the cloud, and there we find what might be the most interesting of possible Cisco missions for Exablaze.  If we examine a cloud-native application or service, we’d find it consists of a bunch of distributed, scalable, resilient microservices, deployed via Kubernetes as containers and linked with a service mesh technology like Istio.  The implementation of Istio is typical; there is a “sidecar” process that represents the connectivity management piece, and the real microservices are clients of that sidecar set.  This is a lot like the separation of control and data plane that I talked about in yesterday’s blog.

Istio and other service meshes have a fairly significant latency associated with them because of the handling of the packets.  Could Cisco use Exablaze technology to create 1) an accelerated sidecar process, 2) an accelerated hosting platform for microservices, and/or 3) an accelerated network mesh that would deliver microservice workflows with much lower latency?  That would be the first true architecture to support service mesh and cloud-native, and it could be very big indeed.

A cloud data center is today very similar to a kind of upsized corporate data center.  If we truly transition to cloud-native, the models might well diverge, and then be conceptually reunited at the software level via things like Kubernetes and service mesh.  That would fit my thinking that the cloud isn’t an alternative hosting mechanism, but an alternative application model that happens to preference a whole new set of hosting options, including the edge.

Data centers are the drivers of enterprise networking policy, and also (obviously) the engine of growth in carrier cloud applications.  Clearly, Cisco knows that, but it’s not clear how deep their understanding is.  Does Cisco see Exablaze as a little, nice, rounding out of a product strategy for a key vertical, or do they see it as the start of a broader transformation of application model?  A lot will depend on the answer to that one.