The economics of AWS are tricky and require close attention. The situation gets even more nuanced when the final solution requirements are architecturally demanding. A static response cached at the edge can reach a million RPS while doing almost no application work. An authenticated write that must survive a regional failure is an entirely different system.

A good example of exploring AWS economics would be something in between: a web server receives an HTTP request, runs a little application logic, checks a cache, sometimes reads a database, and returns JSON. How close can we get to hardware economics while preserving the recognizable properties of such an architecture?

It's been a while since I stretched my infra muscles. I was looking for some exercise and that got me thinking.

Application code is easy to revisit in small slices. Infrastructure is not. Leave Kubernetes, cloud networking, GitOps, observability, and delivery machinery alone for long enough, and the surface area moves under your feet. Managed services change, defaults change, and patterns that once felt sensible begin to look suspiciously dated.

I wanted an exercise with enough weight to be interesting and grounded in realistic platform work. One that reflects the kind of problem an experienced infrastructure engineer should be able to reason about: reproducibility, traffic management, policy, secrets, observability, and failure.

Modern engineering has become extremely good at making ordinary mechanisms sound profound and inaccessible. Give a process a few more layers, add a hosted dashboard, place a protocol in the middle, wrap the infrastructure in a product name, and suddenly a small system begins to carry the posture of an industry.

The tools themselves are not the problem. The performance around them is. We describe simple interactions in language so inflated that the words begin to outrank the mechanics. A container is no longer a process with packaging. It becomes part of a platform story. A few services and some configuration become architecture. A script with side effects becomes orchestration. The naming grows faster than the complexity.

That inflation has a cost. Engineers begin to treat tools as territories instead of interfaces. Entire clusters of technology are discussed as if they require initiation rites before anyone is allowed to touch them. And so a lot of modern IT acquires a sense of difficulty and prestige it does not fully deserve.

Tools help, but craft comes from how you think. You don’t need a heavyweight IDE or a pattern catalog to design data structures. You don't even need a certification. What you need is a tight feedback loop. Chrome DevTools^[1] is enough.

Open the browser, open dev tools, open console, open live expressions^[2] and let's build something useful. No help, no go to definition, no refactoring, no fancy diagrams. Just a thought, crafted step by step.

Control flow (Part 1)

In Part 2, we delve deeper into control flow techniques. This time, we focus on code design skills rather than relying on tools integrated into the compiler/language. As a result, these techniques can be applied to any modern programming language or runtime of choice. While some of them are recognized as patterns, others involve manipulating language rules in a more nuanced way. Regardless, all of them merit our attention as novel approaches to resolving common programming challenges.