Skip to content

Some Market Thoughts on the Broadcom SDKLT

Broadcom, to much fanfare, has announced a new open source API that can be used to program and manage their Tomahawk set of chips. As a general refresher, the Tomahawk chip series is the small buffer, moderate forwarding table size hardware network switching platform on which a wide array of 1RU (and some chassis) routers (often called switches, but this is just a bad habit of the networking world) used in large scale data centers. In fact, I cannot think of a single large scale data center operating today that does not somehow involve some version of the Tomahawk chip set.

What does this all mean? While I will probably end up running a number of posts on SDKLT over time, I want to start with just some general observations about the meaning of this move on the part of Broadcom for the overall network engineering world.

This is a strong validation of a bifurcation in the market between disaggregation and hyperconvergence in the networking world. Back when the CCDE was designed and developed, there was a strong sense among the folks working on the certification that design and operations were splitting. This trend is still ongoing, probably ultimately resulting in two related, but different disciplines. In more recent years, there is a clear trend towards the end of the appliance driven networking model. The market is moving away from the appliance model (buy a box, rack it, turn it on, configure it, and —maybe— automate it), to a model where you either buy an entire vertically integrated system, or you buy various software and hardware bits, then put everything together.

Will this happen overnight? No. Will there be some network operators who try to linger in the old model for as long as possible? Yes. Is the old model a real comfort zone for many folks who work in the networking world? A nice, warm blanket in which to wrap yourself (oh, I don’t know IS-IS, but I know all the latest gear from my favorite big vendor)? Yes.

But this world is done. Kaput. Get used to it.

There will still be a place for custom hardware and appliances, but that place will shrink until it holds steady. Appliances will not die, any more than the PC is going to die any time soon (contrary to all expectations for the last, oh, twenty years or so). The real result might be a much larger overall market, but a market where appliance driven networking will play a significant, but not dominating, role.

This is not the end of vendors. I have seen some commentary in the community bewailing or celebrating the end of the big networking gear vendor. Pft—ain’t gonna happen. What this does do, however, is push big vendors into positioning themselves more strongly as software companies. This falls into the general lines of the disaggregated/hyperconverged coloring book just above. While software first is not going to work in every corner of the networking world, it will work in enough that the ongoing disaggregation between software and hardware is going to change the shape of how vendors must do business.

This is not the end of network engineering, nor network engineers. In 1986’ish, I started working on a new fiber backbone for a USAF base. We were looking at Cabletron boxes for the distribution frames (or core touch points), and either Banyan Vines or Novell Netware for the network operating system. Either one, whichever we chose, combined with the Cabletron’s ability to accept line cards from a wide array of vendors, was going to end the networking wars. We would be able to build any network we wanted, any time, without any real configuration. The end of network engineering was nigh.

Fast forward just shy of ten’ish years, just before I started at Cisco. I was working in the advanced technology group of a large “enterprise shop.” We were going to deploy this thing called IP “like turning on a water faucet.” Then we were going to build an internal ‘web on top of it, and turn off Novell Netware. Then we would have the network to end all networks, and we wouldn’t need heavy duty network engineers any longer. An administrator could run it all.

Is all of this starting to sound familiar? You can laugh because I’m old. That’s okay, because I also have some perspective. 🙂 My experience is this—network engineering has become more complex, not less. I’m constantly tilting at the windmill of network complexity because I have seen this increasing complexity eat engineers in real time.

No, Broadcom opening their chip API is not going to end network engineering. It might end it as we know it, but that has already happened so many times in the last twenty-odd years that this event should almost pass without remark. Is this healthy for humans? I am bothered by this question (hence my taking on a PhD in philosophy). But the question does not fall within the domain of this blog, so I will spare you…

Overall, then… Some interesting changes ahead—changes you should have anticipated. Changes which are going to require all of us, including me, to be a little more serious about acquiring new skills. Some things will remain the same, as well. But the biggest change is going to be on the vendor front, where software is the “new normal” in much of the network.

Scroll To Top