Networking Is Infrastructure – Get Used to It

Jeff Sicuranza left a great comment to one of my blog posts:

Still basically the same old debate from 25 years ago that experienced Network Architects and Engineers understood during technology changes; "Do you architect your network around an application(s) or do you architect your application(s) around your network"

I would change that to “the same meaningless debate”. Networking is infrastructure; it’s time we grow up and get used to it.

What Does It Mean?

As I explained in a few other blog posts:

And now for the “Get Used to It” Part

Let me illustrate this point with an analogy from the highway infrastructure (you could use any other infrastructure you like). Imagine if a car manufacturer (= application developer) would come along saying “I invented this great self-driving car… it only requires a guiding track to be installed on all the roads”.

The response would likely be “and what were you smoking?” even though such an invention would boost the revenues, increase the traffic agility, reduce the number of accidents, and bring world peace (well, maybe not)… and yet the application developers get away with the same approach every single time: we need to deploy this NOW and so you better implement a dozen risky kludges in your network to make it work.

Does That Mean the Network Doesn’t Have to Change?

Of course it has to. The way we manage most networks today is fundamentally broken. TCP/IP stack has severe deficiencies. We’ll need higher speeds at lower price, and maybe it doesn’t make sense to drag garbage invented 40 years ago to support thick coax cable into the world that runs on point-to-point fiber links.

However, we have to evolve networks the way we evolve any other infrastructure:

  • Figure out what makes sense based on laws of physics, not on wishful thinking of people who have no touch with reality or who're trying to make a quick buck;
  • Use engineering principles to transform that into reality (have fun trying to figure out how well they match with the Spaghetti Wall approach favored by the IT industry);
  • Roll out a cost-optimized infrastructure that will satisfy a reasonable majority of the needs of most users.

In other words, stop believing in ground unicorn droppings, and silver bullets that will magically solve your IT problems because the $vendor said so in their marketing whitepaper.

Of course you can continue doing that, but then don’t complain when you’ll get the expensive and brittle network you deserve.

Looking for Red Pill?

My webinars might help (and most people want to get all of them), and I’m usually available for technology discussions.


  1. As a freelance networking consultant who works in multiple large enterprises, 2 words : "Wishful Thinking". The network will always be the duct tape to compensate for crappy application and enterprise architecture design.
  2. I have to agree with previous comment, application owners or developers consider networking an after thought. They don't consider distributed architecture, fail over situations, integrating with load balancers, they are rarely concerned about how it all works.
  3. I have yet to work with a development team that remotely understands networking let alone any of the more advanced topics mentioned above. It feels like half my time is spent bending the network to the application. The people above me don't care how it's done, just make it work. I think this mentality is what keeps a lot of us employed.
  4. This is because nobody is forcing them to take all the constraints into account. They live in their own world, doing their own magic and most of the time it is not in touch with real world.
    However, at the end of the day they are not the ones doing the implementation and integration.
    1. ... which is why I always claim that "making the developer answer the call when the application is down at 2AM on a Sunday morning miraculously reduces the number of bugs" (aka DevOps ;).
Add comment