I needed to implement rate limiting within an application for reasons I’ll get into in a follow-up post. When you start thinking about this, you basically have two paths:

1. Logic embedded directly in the application code
2. A sidecar container that handles the rate limiting role

Both work. Both have trade-offs. Let me go through each one.

The Code Way

This is the simpler approach on the surface, but it comes with some annoying limitations. It can only be reused for applications in the same programming language. And adding rate limiting logic inside the application creates a secondary role — meaning the request interceptor will consume CPU and may produce false metrics if you’re not tracking it carefully.

Why

I had my beloved IPsec setup based on strongswan running in Kubernetes for a while — you can read about that here. It worked fine. I wasn’t looking to change it. Then a colleague pointed out WireGuard’s overhead numbers and I got curious enough to evaluate it myself.

WireGuard is a modern VPN protocol that lives in the Linux kernel. It’s designed to be simple, fast, and have a minimal attack surface compared to IPsec or OpenVPN. The numbers people throw around are impressive, but I wanted to see them in practice.

There’s a reactive way to manage infrastructure and there’s a proactive way. The reactive way is: traffic increases, you notice the service is suffering, you add resources. The proactive way is: you understand your system well enough that it handles demand changes automatically, without you needing to be in the loop.

I prefer the lazy way.

Here we go… another weird sidecar container.

Motivations

I’ve always been interested in the observability area. There are many aspects that improve performances and fix bugs. One of the most interesting is network usage.

This is not about network issues:

It’s about understanding where bandwidth is actually going.

You’re probably used to seeing something like this for your VMs:

When I first got into IT, devices ran continuously. My first lab was an impressive tower from 1999 with substantial disk and memory banks, a quality CPU cooled by a massive copper heatsink and a 12cm fan. During the night, those components produced noise comparable to a helicopter. Neighbors complained. I didn’t sleep well.

The lab evolved over the years. Not just for noise reasons, but prioritizing cost-effective hardware that could replicate a simplified production environment. The goals today are very different from 1999:

In the home automation era, I wanted to understand how simple thermal sensors actually work — not just buy a commercial solution and plug it in, but build the whole thing from scratch. Here’s what I put together.

What We Need

• ESP8266
• DHT22
• USB power supply
• InfluxDB
• Grafana

Hardware

I initially considered Arduino but followed a colleague’s suggestion to use NodeMCU instead. NodeMCU is an open source platform developed for IoT where you can compile firmware with the sensors you need. Its primary advantage is Lua support, which is significantly simpler than Arduino’s C implementation for this kind of work.

Contrary to popular belief, monitoring an infrastructure is the opposite of just having some metrics about applications and network.

There are many excellent resources on this topic. One of the most interesting is just a few pages from Google — the art of SLOs. I took the book version from a Google on-site deep dive.

To structure this properly, I want to use four simple statements:

• WHAT
• WHY
• WHO
• HOW

WHAT

This is probably the main argument we’ll discuss here.

Great marketing quote in the title — but honestly, the underlying principle is always true: keep it simple, keep it safe.

I want to structure this around four topics:

• Static website
• Tools
• Security
• Monitor

Each could be its own post. This one will cut across all of them because they’re connected.

This is not a post about how to create a blog. This post inspects some technology that can simplify your life or your work with small but important concepts.

NO.

That’s the short answer. Kubernetes has not destroyed virtualization. Let me explain why.

I’ve been watching the “Kubernetes rush” for a few years now. Companies highlight success stories and cost savings, but I often wonder if they’re sharing the complete picture. I want to focus specifically on Kubernetes and virtualization — not the broader data center ecosystem with databases, legacy systems, and corporate infrastructure.

It’s time to talk about the API gateway.

In a modern infrastructure — especially in a microservices environment — you probably know what I’m referring to. But it’s worth being explicit about it:

“An API gateway takes all API calls from clients, then routes them to the appropriate microservice with request routing, composition, and protocol translation. Typically it handles a request by invoking multiple microservices and aggregating the results, to determine the best path.”