Category: worth reading

Charity Majors published another must-read article: why every software engineering interview should include ops questions. Just a quick teaser:

The only way to unwind this is to reset expectations, and make it clear that:

• You are still responsible for your code after it’s been deployed to production, and
• Operational excellence is everyone’s job.

Adhering to these simple principles would remove an enormous amount of complexity from typical enterprise IT infrastructure… but I’m afraid it’s not going to happen anytime soon.

As early as 1994 (on April 1st, to be precise) a satire disguised as an Informational RFC was published describing the deployment of IPv9 in a parallel universe.

Any similarity with a protocol that started as a second-system academic idea and is still experiencing hiccups in real world even though it could order its own beer in US is purely coincidental.

Justin Pietsch wrote another fantastic blog post, this time describing how they simplified Amazon’s internal network, got rid of large-scale VLANs and multi-NIC hosts, moved load balancing functionality into a proxy layer managed by application teams, and finally introduced merchant silicon routers.

After almost a decade of bickering and haggling (trust me, I got my scars to prove how the consensus building works), the authors of Operational Security Considerations for IPv6 Networks (many of them dear old friends I haven’t seen for way too long) finally managed to turn a brilliant document into an Informational RFC.

Regardless of whether you already implemented IPv6 in your network or believe it will never be production-ready (alongside other crazy stuff like vaccines) I’d consider this RFC a mandatory reading.

Some of the best blog posts I’ve read described a solution (and the process to get there) someone reached after a lot of struggle.

As always, Julia Evans does a wonderful job explaining that in exquisite details.

TL&DR: If you’re about to miss a deadline, be honest about it, and tell everyone well in advance.

I wish some of the project managers I had the “privilege” of working with would use 1% of that advice.

How to Miss a Deadline

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.