Category: worth reading

This article is totally unrelated to networking, and describes how medical researchers misuse machine learning hype to publish two-column snake oil. Any correlation with AI/ML in networking is purely coincidental.

Machine Learning Deserves Better Than This

Stumbled upon a must-read article: Is Your Consultant a Parasite?

For an even more snarky take on the subject, enjoy the Ten basic rules for dealing with strategy consultants by Simon Wardley.

Scott Berkun published another interesting article: The Lost Designer. As always, replace designer with networking engineer and enjoy.

In the Neuroscience of Busyness article, Cal Newport describes an interesting phenomenon: when solving problems, we tend to add components instead of removing them.

If that doesn’t describe a typical network (or protocol) design, I don’t know what does. At least now we have a scientific basis to justify our behavior ;)

I remember having an interesting discussion about Linux VRFs (as opposed to namespaces) with Dinesh Dutt years ago, but it looks like I never turned it into a blog post.

Now I won’t have to 😉 – Jon Langemak published an excellent Working with Linux VRFs deep dive.

If you ever get a feeling the grass is greener on the other (startup) side, read My Secret Startup Past by Amy Hoy, and if you think about starting your business, read all the other stuff she wrote. I wish I knew of her when I was starting ipSpace.net a decade ago.

During my interview with David Bombal I made a recommendation I find crucial for anyone serious about blogging:

Make sure you own your content.

There’s a simple reason for that rule: if you want to write quality content, you’ll have to invest a lot of time into it.

I know the title sounds like a buzzword-bingo-winning clickbait, but it’s true. Adrian Giacometti decided to merge the topics of two ipSpace.net online courses and automated deployment of AWS security rules using Terraform within GitLab CI pipeline, with Slack messages serving as manual checks and approvals.

Not only did he do a great job mastering- and gluing together so many diverse bits and pieces, he also documented the solution and published the source code:

• Part 1: Cloud & Network automation challenge: Deploy Security Rules in a DevOps/GitOps world with AWS, Terraform, GitLab CI, Slack, and Python (special guest FastAPI)
• Part 2: AWS, Terraform and FastAPI
• Part 3: GitLab CI, Slack, and Python
• Source code: aegiacometti/devops_cloud_challenge · GitLab

Want to build something similar? Join our Network Automation and/or Public Cloud course and get started. Need something similar in your environment? Adrian is an independent consultant and ready to work on your projects.

Scott Berkun wrote another great article that’s equally applicable to the traditional notion of design (his specialty) and the network design. Read it, replace design with network design, and use its lessons. Here’s just a sample:

• Convincing people is a social process
• Aim for small wins, not conversions of belief systems
• Allies matter more than ideas
• Design maturity grows one step at a time.

Who would have thought that you could get better at what you do by figuring out how things you use really work. I probably made that argument (about networking fundamentals) too many times; Julia Evans claims the same approach applies to programming.

I thought I was snarky and somewhat rude (and toned down some of my blog posts on second thought), but I’m a total amateur compared to Corey Quinn. His last masterpiece – Machine Learning is a Marvelously Executed Scam – is another MUST READ.

Here’s an interesting fact: cloud-based stuff often refuses to die; it might become insufferably slow, but would still respond to the health checks. The usual fast failover approach used in traditional high-availability clusters is thus of little use.

For more details, read the ‌Fail-Fast is Failing… Fast ACM Queue article.

A junior networking engineer asked me for a list of recommended entry-level networking blogs. I have no idea (I haven’t been in that position for ages); the best I can do is to share my list of networking-related RSS feeds and the process I’m using to collect interesting blogs:

Infrastructure

• RSS is your friend. Find a decent RSS reader. I’m using Feedly – natively in a web browser and with various front-ends on my tablet and phone (note to Google: we haven’t forgotten you killed Reader because you weren’t making enough money with it).
• If a blog doesn’t have an RSS feed I’m not interested.

We’re in an unfortunate industry where you can’t learn everything there’s to know in 3 years and keep doing the same stuff for the next 30 years… but how do you keep learning? Andrew Owen documented what works for him in Learning without Burnout.

If you want to grow beyond being a CLI (or Python) jockey, it’s worth trying to understand things work… not only how frames get from one end of the world to another, but also how applications work, and why they’re structured they way they are.

Daniel Dib recently pointed out another must-read article in this category: Modules, monoliths, and microservices by Avery Pennarun – a wonderful addition to my distributed systems resources.