Tech-Reader.blog

Insight: From Chaos to Control Plane—Is EKS Really That Much Easier Than On-Prem Kubernetes? When I came across a post from an SRE managing an on-prem Kubernetes cluster on RHEL, it struck a chord. Every day brought a new issue: master nodes dropping off, worker nodes becoming unreachable, and endless layers of network and VM complexity to peel back. Anyone who’s operated Kubernetes on bare metal or traditional virtualization knows the drill — it’s a daily dance with entropy, and your only partner is kubectl and hope. This is the reality for many engineers who still manage clusters in datacenters or hybrid clouds. You patch VMs, babysit control planes, troubleshoot disk I/O issues, and triage hardware blips — all while keeping containerized workloads running smoothly. It's the ultimate full-stack challenge: networking, storage, CPU scheduling, and orchestration all wrapped into one. If you love complexity, it’s a paradise. If you’re trying to ship features? It's a drag. The EK...

Insight: Why Aurora’s Reader Endpoint Isn’t Enough—The Real Problem with Query Routing The Mirage of Simplicity Aurora PostgreSQL makes a beautiful promise: scale reads with a simple reader endpoint and keep your writer node clean. You spin up replicas, wire your app to the provided DNS name, and expect the load to distribute itself. It feels seamless — until you realize your writer instance is still carrying the weight of most SELECT queries. Something’s not right. The infra looks healthy. The DNS is resolving. But the query traffic is misbehaving. That’s because Aurora’s built-in reader endpoint is not a traffic controller — it’s a DNS trick. It doesn’t understand query intent. It doesn’t monitor replica lag. It doesn’t know your business logic or your application’s needs. It just points your app in a general direction and hopes for the best. And that illusion of simplicity is where many teams run aground. The Problem Beneath the Problem This isn’t just about DNS. It’s about visibili...

Solve: How to Modularize Your SAM Templates Without Breaking sam sync The Tension Between Modularity and Speed The AWS SAM CLI has grown into a powerful developer toolset, and  sam sync  is one of its most welcome additions. It lets you update your deployed application fast, skipping a full CloudFormation round trip and keeping your edit-deploy-test loop tight. But there's a catch:  sam sync  expects a flat, ready-to-go  template.yaml . That can make modularization difficult. If you're breaking your SAM template into smaller files for clarity and reuse, you risk breaking compatibility with  sam sync —unless you finish the thought. What sam sync Expects From You Under the hood,  sam sync  is watching a specific file:  template.yaml . It assumes that file defines the whole application—no includes, no file stitching, just a single YAML document describing all resources and configuration. If your team splits...

Solve: Teaching SAM to Share—Splitting template.yaml into Multiple Files A cloud engineer working in a growing team project recently ran into a small but familiar problem. Their AWS SAM project had ballooned into a single, unwieldy template.yaml file. At first it was fine—just a function or two, an API definition, maybe a table. But weeks later, with new teammates and added resources, the file had become a cluttered wall of YAML. The engineer didn’t want to migrate away from SAM, but they did want a way to split things up. “Can I just divide this into multiple files somehow?” they asked. That’s a fair question. SAM doesn’t support this directly—unlike Terraform or CDK—but with a little shell script magic and one or two external tools, you can absolutely get there. The trick is not to fight SAM’s single-template expectation head-on, but instead to preprocess your own clean, modular YAML structure into a single file right before deploying. There are two practic...

Insight: What Kind of “Radio” Is This? Understanding the New Raspberry Pi Radio Module 2 When Raspberry Pi Ltd announced the Radio Module 2—or RM2 for short—some makers got excited for all the wrong reasons. “Finally!” they thought. “A Pi-branded SDR? An FM tuner module?” Not quite. The name may conjure visions of antennae scanning shortwave bands, but that’s not what we’re dealing with here. The RM2 is a 2.4 GHz wireless communication module, built for Wi‑Fi and Bluetooth, not audio broadcasting. To be clear: this isn’t software-defined radio (SDR). It’s not a ham radio receiver. It won’t tune your local FM station or help you build a police scanner. What it will do—and quite well—is bring wireless networking and device pairing to embedded Raspberry Pi–style projects that use chips like the RP2040. If you’ve ever used a Pico W or Pico 2 W, you’ve already benefited from the same chip. Now, you can buy it on its own for just $4. Yes, Pico W and Pico 2 W Already Have This Here’s where th...

Solve:  Diagnosing Aurora PostgreSQL Query Routing Issues I. The Quiet Cost of Misrouted Queries When your Aurora PostgreSQL cluster starts slowing down, the first thing many engineers think about is scaling. Maybe your app grew. Maybe you need a bigger instance. But sometimes, the issue isn't size—it's traffic routing. Aurora is designed for performance, but only if you use its features the way AWS intended. One of the most important—but often overlooked—tools in your belt is the reader endpoint . Aurora clusters come with both a writer endpoint and a read-only endpoint , and each serves a different role: The writer handles all data changes—INSERTs, UPDATEs, DELETEs, etc. The readers are for SELECTs—reporting dashboards, analytics, background jobs, and any operation that doesn't change data. If your application sends everything to the writer—reads and writes—you’re unintentionally t...

Solve: ECS-CDK Deploys and the Timing Trap—Notes from the Field This isn’t the kind of issue you catch in tutorials. It’s the kind that quietly eats your morning, just when you thought you were ready to deploy. If you’re rolling out an ECS service using CDK—and you’re creating your infrastructure and container image for the first time—you may run headfirst into a silent conflict between build timing and deploy order. CDK tries to launch the ECS service before your image exists in ECR. That leads to a 404 at the ECS level, and the whole thing rolls back. At this point, there’s a decision to be made. Option 1: Pre-Push Your Image One option is to build and push a placeholder container to ECR before your first CDK deploy. This lets CDK proceed without breaking ECS on image fetch. It’s a manual step, but it clears the dependency deadlock and lets you move forward fast. Later, you can swap in your real image. Option 2: Deploy in Two Passes The other approach is more surgical. Deploy the pip...