Category: worth reading
The next time you’re about to whimper how you can’t do anything to get rid of stretched VLANs (or some other stupidity) because whatever, take a few minutes and read How To Put Faith in UX Design by Scott Berkun, mentally replacing UX Design with Network Design. Here’s the part I loved most:
[… ]there are only three reasonable choices:
- Move into a role where you make the important decisions.
- Become better at influencing decision makers.
- Find a place to work that has higher standards (or start your own).
Unfortunately the most common choice might be #4: complain and/or do nothing.
I love the recent Internet of Trash article by Geoff Huston, in particular this bit:
“Move fast and break things” is not a tenable paradigm for this industry today, if it ever was. In the light of our experience with the outcomes of an industry that became fixated on pumping out minimally viable product, it’s a paradigm that heads towards what we would conventionally label as criminal negligence.
Of course it’s not just the Internet-of-Trash. Whole IT is filled with examples of startups and “venerable” companies doing the same thing and boasting about their disruptiveness. Now go and read the whole article ;)
Just in case you were recently promoted to be a team leader or a manager: read these somewhat-tongue-in-cheek advices:
- How do I feel worthwhile as a manager when my people are doing all the implementing? by Charity Majors
- The Non-psychopath’s Guide to Managing an Open-source Project by Kode Vicious.
Something to keep in mind before you start complaining about the crappy state of network operating systems: people are still finding hundreds of bugs in C and C++ compilers.
One might argue that compilers are even more mission-critical than network devices, they’ve been around for quite a while, and there might be more people using compilers than configuring network devices, so one would expect compilers to be relatively bug-free. Still, optimizing compilers became ridiculously complex in the past decades trying to squeeze the most out of the ever-more-complex CPU hardware, and we’re paying the price.
Keep that in mind the next time a vendor dances by with a glitzy slide deck promising software-defined nirvana.
In January 2018 Rodney Brooks made a series of long-term predictions about self-driving cars, robotics, AI, ML, and space travel. Not surprisingly, his predictions were curmudgeonly and pessimistic when compared to the daily hype (or I wouldn’t be blogging about it)… but guess who was right ;)
He’s also the only predictor I’m aware of who is not afraid to compare what he wrote with how reality turned out years down the line. On January 1st he published the 2021 edition of the predictions scorecard and so far he hasn’t been too pessimistic yet. Keep that in mind the next time you’ll be listening to your favorite $vendor droning about the wonders of AI/ML.
Last month Nature published a damning response written by 31 scientists to a study from Google Health that had appeared in the journal earlier this year. Google was describing successful trials of an AI that looked for signs of breast cancer in medical images. But according to its critics, the Google team provided so little information about its code and how it was tested that the study amounted to nothing more than a promotion of proprietary tech (emphasis mine).
Did you ever experience an out-of-the-blue BGP session flap after you were running that peering for months? As Dmytro Shypovalov explains in his latest blog post, it’s always MTU (just kidding, of course it’s always DNS, but MTU blackholes nonetheless result in some crazy behavior).
A long while ago I wrote a blog post along the lines of “it’s ridiculous to allow developers to deploy directly to a public cloud while burdening them with all sorts of crazy barriers when deploying to an on-premises infrastructure,” effectively arguing for self-service approach to on-premises deployments.
Not surprisingly, the reality is grimmer than I expected (I’m appalled at how optimistic my predictions are even though I always come across as a die-hard grumpy pessimist), as explained in The Shared Irresponsibility Model in the Cloud by Dan Hubbard.
My friend Marjan Bradeško wrote a great article describing how we tend to forget common sense and rely too much on technology. I would strongly recommend you read it and start thinking about the choices you make when building a network with magic software-intent-defined-intelligent technology from your preferred vendor.
I was telling you there’s no need to become a programmer over six years ago, but of course nobody ever listens to grumpy old engineers… which didn’t stop Ethan Banks from writing another excellent advice on the same theme: Don’t Become A Developer, But Use Their Tools.
We all knew it for a long time, now it’s finally official: IP fragmentation is broken, or as the ever-so-diplomatic IETF likes to call it, IP Fragmentation is Considered Fragile.
Justin Pietsch is back with another must-read article, this time focused on high-speed Ethernet switching ASICs. I’ve rarely seen so many adjacent topics covered in a single easy-to-read article.
In one of his recent blog posts Tom Hollingsworth described what I semi-consciously felt about the CCIE lab exam for at least 25 years: it’s full of contrived scenarios that look more like Iron Chef than real life.
I understand they had to make the lab harder and harder to stop cheating (because talking with candidates and flunking the incompetents is obviously not an option), and there’s only so much one can do with a limited set of technologies… but forcing networking engineers to find ever-more-devious ways to solve overly-complex problems is nothing else but fuel for rampant MacGyverism.
Anyway, I don’t think this mess will ever be fixed, so the only thing we can do is to enjoy the rant.
One of the weekend reads collected by Russ White contained a pointer to a hilarious description of blockchain - a solution in search of a problem. Here are a few quotes to get you started (and I had a really hard time selecting just a few):
I’ve never seen so much bloated bombast fall so flat on closer inspection.
At its core, blockchain is a glorified spreadsheet.
The only thing is that there’s a huge gap between promise and reality. It seems that blockchain sounds best in a PowerPoint slide.
Someone should use that article as a framework and replace blockchain with OpenFlow or SDN ;)