Building Network Automation Solutions
6 week online course starting in September 2017

30 Years of Yammering

Some of the comments I get every time I write about the idea of merging network services deployment with application deployments, and making application developers responsible for the results of their code (aka DevOps) remind me of a very long list of “this will never work” sentiments I encountered in the 30 years I spent in IT and networking. Here are just a few of them:

Mission-critical applications will never run on Unix hosts. IBM and Tandem are the only platforms that are reliable enough to handle them.
Unix will never run reliably on x86 hardware. That’s the hardware I use at home; we need something better for the server room.
Windows? That’s the thing I run on my desktop. And now you want to have that thing on a server?
Routers? Get lost, that’s for the academics. I trust my SNA network.
SNA-over-IP? That will never work. IP-over-SNA probably makes sense, but SNA-over-IP? We would lose all control over the end-to-end QoS.
Selling things over Internet? It won’t work; people will never send their credit card information over the Internet.
Using Internet in tourism makes no sense – most holidays are booked by women, and a typical Internet user is a man in mid 20es (I’m not making it up – I actually heard this one).
Voice-over-IP? Too bandwidth-consuming… and you’ll never get the QoS you need for carrier-grade voice experience.
Ethernet? No, it’s non-deterministic. I’ll stick to Token Ring.
Ethernet in carrier networks? Never. It might be good enough for LANs, but we’ll stay with ATM over SDH (or SONET).
Trusting the service provider to run my WAN? I could never do that – Frame Relay is sort-of-OK (but I prefer channelized E1/T1), MPLS/VPN is out of question.
Building my corporate WAN over the Internet? What were you smoking? I’ll stay with the MPLS/VPN.

In every single case “the thing that will never worked” eventually started to work, became successful (because it was just-good-enough at a low-enough price), and effectively strangled “the best thing ever invented”… and the people who claimed it will never work grudgingly accepted it and started yammering about the next impossible transition. Lather, rinse, repeat.

Shall we just embrace every new technology?

Obviously not – after all, we’re the wall used by the vendors to see which pasta sticks – but it’s also irresponsible to say “this will never work” and continue burning other people’s money doing things the same broken way (let’s be honest, that’s what we’re doing configuring VLANs for the last 20 years).

What you should do instead is:

  • Evaluate whether the new technology makes sense from the architectural and technology perspective. There are some things that are evidently broken (ATM-to-the-desktop and OpenFlow-based global load balancing come to mind). Also, never trust industry press, high-level consultants and vendor white papers – after all, those same people evangelized the beauty of follow-the-sun VM mobility;
  • Figure out whether the new technology has a fighting chance to address a business problem faced by your organization, or improve the IT processes;
  • Learn more about the new technology;
  • Set up a pilot (potentially working with like-minded people from other IT groups, ranging from application developers to networking and storage engineers);
  • Whenever a pilot fails, learn from the mistakes, fix them, and repeat the pilot;
  • Use the results of the pilot(s) to dismiss the technology, shelve it until it matures, or slowly adopt it for new deployments.

In any case, whatever you decide to do, don’t be the Department of No.


Post a Comment

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.