Hey 👋

It's Ivan again, with the slightly overdue February roundup of all things Linux, Containers, Kubernetes, and Server Side - and I've got some great news! 🚀

What I was working on

I've been periodically bringing up my Byte-Sized Docker course for more than a year now. However, the work hasn't progressed fast enough - mainly because I wasn't satisfied with the format. Creating yet another "Here is how to run a container and here is how to build an image" kind of course just didn't sound right to me, and I wanted to come up with something complementary to the existing materials (by other creators) and much more distinct at the same time.

And I think I figured it all out, and things have finally clicked. Behold the Docker The Hands-On Way roadmap:

The above is not a drawing but a fully dynamic page with dozens of interactive elements representing hands-on challenges, theoretical references, and integral skill paths. I started working on it only a couple of weeks ago, but the "engine" is already done (vibe-coded it, so the mobile experience is still meh), and the first 26 challenges and two skill paths are ready for you to take.

I'm shooting for 80+ more challenges so that the complete roadmap will include more than a hundred hands-on problems split into nine modules:

• Running containers
• Building images
• Working with registries
• Container networking
• Mounts and volumes
• Development with Docker
• Building and testing images in CI/CD
• Deploying and operating containers in production

... and a few cross-cutting themes:

• Container runtime security
• Container image security
• Container registry security
• Container storage security
• Debugging and troubleshooting
• Observability and monitoring

Possibly, the best part about it is that all challenges now come with explanatory solutions, so it's going to be a hands-on first but theory-augmented learning experience.

When I'm done with this (rather massive but nevertheless realistic chunk of) work, one of my biggest dreams will come true - I'll finally have a single page that anyone can use to go from zero to hero in their Docker study 🚀

Of course, it's only become possible because more and more people have decided to support my work on iximiuz Labs (and get a bunch of perks in return).

Other iximiuz Labs happenings

Many more good things happened in February on the platform, so I'm not even sure the below list is complete:

The mini-LAN playgrounds (Ubuntu, Ubuntu + Docker) have gotten the 4th virtual machine, which makes them ideal for following Kelsey's Kubernetes The Hard Way tutorial.

I joined Saim Safdar on his Cloud Native Podcast to talk about my work on iximiuz Labs (and shared a bunch of usage and revenue numbers for those who are interested in this kind of stuff).

​I.K.A SAKIB created a great ArgoCD playground using the custom playgrounds mechanism. Give it a try.

​Adam Leskis contributed another custom playground - R Studio - and traditionally wrote a blog post on his playground creation experience 👏

The KubeBlocks series by GuangHui Yu was completed, and a comprehensive KubeBlocks Skill Path was added (the latter made it to Google Discover and attracted 17.4K unique visitors in a day 🤯).

The nerdctl + containerd playground was upgraded to the 2.x line, and I added a new lesson to my containerd course.

What I was reading

​NFTables mode for kube-proxy (Kubernetes Blog) - According to Kubernetes authors, nftables is now the best kube-proxy mode (still in beta but will likely GA in 1.33) but the iptables mode will be supported for a long time and will also remain the default. The problem with iptables is that the rules are organized into lists (tables), and adding or removing a rule often has O(n) complexity instead of O(1). Thus, the default kube-proxy mode has been a poor choice for clusters with a large number of services and/or pods. But what has always puzzled me is the hypothetical existence of such clusters - I'd expect such setups to use Cilium or some other involved networking solution that, in particular, gets rids of kube-proxy, making the iptables performance issue irrelevant 🤔

​How to (and how not to) design REST APIs - Mainly good advice here, highly likely won in battles and with a bunch of production scars received in return. Read it if you're about to build a new or overhaul an existing API.

​There Isn't Much Point to HTTP/2 Past The Load Balancer - The beauty of the HTTP/1.1 protocol is that it’s text-based and human-readable. It's much easier to understand and troubleshoot services that communicate over HTTP/1.1 than a binary protocol like gRPC or HTTP/2. The author argues that the latter should be considered not as an upgrade of the protocol but simply as an alternative version. While HTTP/2 (or HTTP/3) is a better choice for services exposed to the Internet (hence, often consumed via slow and unreliable networks), HTTP/1.1 remains a valid (and often desirable) choice for internal services communicating over fast and reliable LANs. Unless you're dealing with a Google-scale infrastructure and sub-millisecond optimizations matter for you (which most of us don't).

​Ugly Code and Dumb Things - Reaction to this post can be a great engineer maturity test. What would you choose - a feature shipped on time but with a messy code behind it or a perfect implementation but a significantly delayed delivery? Or, a canonical OOP implementation with a perfect encapsulation but a dozen classes scattered over multiple files or 100 lines of "dumb" functions manipulating a global variable but completely fitting into one’s context from the first read? This is the type of questions staff/principal engineers get to deal with daily, and often, the right decisions would contradict pretty much every engineering wisdom you preached for as a mid/senior-level engineer. And this is totally fine! Both stages are natural and much needed for one's career progression.

​How I use LLMs as a staff engineer - For me, learning new domains (or subjects) with LLMs hasn't been working well so far, but it could be because my requests were too niche. For the rest, this is a rather reasonable write-up that largely correlates with my own experience of using LLMs: smart autocomplete; short, tactical changes, usually scoped to a single file; generating PoC and research code at lightning speed; last-resort bug fixes (it's like a roulette - sometimes, you get lucky and it saves an hour or two); and grammar/style fixes of my writing. I'd also add dealing with the Blank Page problem - it became much easier to start writing (code, posts, etc.) simply because you don't get to stare at an empty page for half a day anymore.

​Hallucinations in code are the least dangerous form of LLM mistakes by Simon Willison - The title doesn't fully convey the point in the post. Dismissing the usefulness of LLMs for coding today, justifying it by hallucinations or any other shortcoming, is a fast lane to technical irrelevance. They are work amplifiers. I personally today generate more code than I write by hand. But LLM-generated code is rarely useful (or even plain dangerous) without proofreading, understanding, manually testing, and then tweaking it. And this has been a crucial skill set even before LLMs.

Wrapping up

I want to finish this newsletter with even more great news. If we exclude the Black Friday craze from consideration, February has been by far the best month for the platform financially. The sales of iximiuz Labs premium membership have doubled compared to January (the previous best month), and the trend seems to be only accelerating. March is just 4 days in, and judging by the numbers, it may as well outperform February.

I'm truly grateful for this support - every dollar is reinvested in the further development of the platform! 💪

Happy hacking!

Cheers

Ivan