Category: worth reading

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.

Need more career advice? How about The Six Year Rule by Bryan Sullins… or you could go and reread my certifications-related blog posts.

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.

From AI is wrestling with a replication crisis (HT: Drew Conry-Murray)

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).

No surprise there, we’ve seen it before (not to mention the “look how awesome we are, but we can’t tell you the details” Jupiter Rising article).

Here’s another riff on the “when you’re the smartest person in the room, change the room” theme: The Trap of The Premature Senior by inimitable Charity Majors. Enjoy!

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.

For more technical details, watch cloud-focused ipSpace.net webinars, in particular the Cloud Security one.

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 ;)

Years ago I was naive enough to participate in writing an IETF document. Three years later we finally managed to turn it into an RFC, and I decided that was enough for one lifetime.

But wait, it gets worse… as Geoff Huston argues in his article, the lengthy review process doesn’t necessarily result in better (or more precise) documents.

Seems like we managed to turn IETF into yet another standard body like IEEE, ISO or ITU/T.

Justin Pietsch published another must-read article, this time dealing with operational complexity of load balancers and IP multicast. Here are just a few choice quotes to get you started:

• A critical lesson I learned is that running out of capacity is the worst thing you can do in networking
• You can prevent a lot of problems if you can deep dive into an architecture and understand it’s tradeoffs and limitations
• Magic infrastructure is often extremely hard to troubleshoot and debug

You might find what he learned useful the next time you’re facing a unicorn-colored slide deck from your favorite software-defined or intent-based vendor ;))