the why:⌗

I am a software engineer, mainly working on the backend, and I’ve been accustomed to writing APIs and Developer CLI tools for a while. Don’t get me wrong, I love working in the backend mines, it’s fun, it’s engaging, I excel in this part of building scalable backends. But, it does get less engaging when all you do is build CRUD apps (just kidding, APIs are not just CRUD apps, a lot goes into building scalable APIs and backend systems) for the better part of your day.

I write a lot of Go, and I wanted to dig a little bit deeper into what CLIs can actually do, beyond just wrapping external APIs. That’s how I stumbled into interacting with the Linux Kernel through eBPF [?]. A genuinely impressive piece of technology. The more I read about it, the more I wanted to build something real with it.

the what:⌗

As a beginner project into this new tech, I am working on a network chaos engineering tool. I want to build a simple CLI tool that might help an engineer understand how their products behave when the network isn’t. You experiment on a running system to build confidence it will effectively tolerate failures (network failures).

the how:⌗

This CLI tool will leverage eBPF (extended Berkeley Packet Filter) [?] and Linux Traffic Control (TC) [?] to inject realistic network conditions directly into the local development loop. The Go CLI binary will compile and load an eBPF program (written in C) into the kernel’s network interface.

damn

man I haven’t written any C code in the longest

Anyway, the eBPF program will dynamically inject random packet drops, simulate high-jitter delays, and artificial TCP connection drops that exactly mimic a user’s network status in different conditions (congested-wifi, deep-rural, cellular-5g e.t.c). This will force the backend systems to prove they can survive real-world network infrastructure before deploying to production.

More coming soon!