The network engineering world has long emphasized the longevity of the hardware we buy; I have sat through many vendor presentations where the salesman says “this feature set makes our product future proof! You can buy with confidence knowing this product will not need to be replaced for another ten years…” Over at the Networking Nerd, Tom has an article posted supporting this view of networking equipment, entitled Network Longevity: Think Car, not iPhone.

It seems, to me, that these concepts of longevity have the entire situation precisely backward. These ideas of “car length longevity” and “future proof hardware” are looking at the network from the perspective of an appliance, rather than from the perspective as a set of services. Let me put this in a little bit of context by considering two specific examples.

In terms of cars, I have owned four in the last 31 years. I owned a Jeep Wrangler for 13 years, a second Jeep Wrangler for eight years, and a third Jeep Wrangler for nine years. I have recently switched to a Jeep Cherokee, which I’ve just about reached my first year driving.

What if I bought network equipment like I buy cars? What sort of router was available nine years ago? That is 2008. I was still working at Cisco, and my lab, if I remember right, was made up of 7200’s and 2600’s. Younger engineers probably look at those model numbers and see completely different equipment than what I actually had; I doubt many readers of this blog ever deployed 7200’s of the kind I had in my lab in their networks. Do I really want to run a network today on 9-year-old hardware? I don’t see how the answer to that question can be “yes.” Why?

First, do you really know what hardware capacity you will need in ten years? Really? I doubt your business leaders can tell you what products they will be creating in ten years beyond a general description, nor can they tell you how large the company will be, who their competitors will be, or what shifts might occur in the competitive landscape.

Hardware vendors try to get around this by building big chassis boxes and selling blades that will slide into them. But does this model really work? The Cisco 7500 was the current chassis box 9 years ago, I think—even if you could get blades for it today, would it meet your needs? Would you really want to pay the power and cooling for an old 7500 for 9 years because you didn’t know if you would need one or seven slots nine years ago?

Building a hardware platform for ten years of service in a world where two years is too far to predict is like rearranging the chairs on the Titanic. It’s entertaining, perhaps, but it’s pretty pointless entertainment.

Second, why are we not taking the lessons of the compute and storage worlds into our thinking, and learning to scale out, rather than scaling up? We treat our routers like the server folks of yore—add another blade slot and make it go faster. Scale up makes your network do this—

Do you see those grey areas? They are costing you money. Do you enjoy defenestrating money?

These are symptoms of looking at the network as a bunch of wires and appliances, as hardware with a little side of software thrown in.

What about the software? Well, it may be hard to believe, but pretty much every commercial operating system available for routers today is an updated version of software that was available ten years ago. Some, in fact, are more than twenty years old. We don’t tend to see this because we deploy routers and switches as appliances, which means we treat the software as just another form of hardware. We might deploy ten to fifteen different operating systems in our network without thinking about it—something we would never do in our data centers, or on our desktop computers.

So what this appliance-based way of looking at things emphasizes is this: buy enough hardware to last you ten years, and treat the software a fungible—software is a second tier player that is a simple enabler for the expensive bits, the hardware. The problem with this view of things is it simply ignores reality. We need to reverse our thinking.

Software is the actual core of the network, not hardware.

If you look at the entire networking space from a software centric perspective, you can think a lot differently. It doesn’t matter what hardware you buy; what matters is what software it runs. This is the revolutionizing observation of white box, bright box, and disaggregated networking. Hardware is cheap, software is expensive. Hardware is CAPEX, software is OPEX. Hardware only loosely interacts with business and operations; software interacts with both.

The appliance model, and the idea of buying big iron like a car, is hampering the growth and usefulness of networks in real businesses. It is going to take a change to realize that most of us care much less about hardware than software in our daily lives, and to transfer this thinking to the network engineering realm.

It is time for a new way of looking at the network. A router is not a car, nor it is a cell phone. It is a router, and it deserves its own way of looking at value. The value is in connecting the software to the business, and the hardware to the speeds and feeds. These are separate problems which the appliance model ties into a single “thing.” This makes the appliance world bad for businesses, bad for network design, and bad for network engineers.

It’s time to rethink the way we look at network engineering to build networks that are better for business, to adjust our idea of future proof to mean a software-based system that can be used across many generations of hardware, while hardware becomes a “just in time” component used and recycled as needs must.