Posts

The most dangerous word in software is “deploy.” It carries the weight of “I hope nothing breaks” even when you’ve done everything right. Feature flags change that equation entirely. Deployment vs Release Most teams conflate two distinct concepts: Deployment: Code reaches production servers Release: Users see new functionality Feature flags separate these. You can deploy code on Monday and release features on Thursday. You can deploy to everyone but release to 5% of users. You can deploy globally but release only to internal testers. ...

When you need to process video in real-time — whether it’s tracking objects, detecting anomalies, or analyzing motion — you face a fundamental choice: cloud or edge? Here’s why edge ML is often the better answer, and how to make it work. Why Edge? Latency matters. A round-trip to the cloud takes 50-200ms minimum. For real-time tracking, that’s an eternity. Edge processing can hit single-digit milliseconds. Bandwidth is expensive. Streaming raw video at 720p/60fps burns ~100 Mbps. Processing locally and sending only results drops that to kilobytes. ...

Terraform’s getting-started guide shows a single main.tf with everything in it. That works for demos. It doesn’t work when you have 50 resources, 5 environments, and a team making changes simultaneously. These patterns emerge from scaling Terraform across teams and environments—where state conflicts happen, where modules get copied instead of shared, and where “just run terraform apply” becomes terrifying. Project Structure The flat-file approach breaks down fast. Structure by environment and component: ...

Docker makes it easy to containerize applications. Docker makes it equally easy to create bloated, insecure, slow-to-build images. The difference is discipline. These practices come from running containers in production—where image size affects deployment speed, security vulnerabilities get exploited, and build times multiply across teams. Start With the Right Base Image Your base image choice cascades through everything else. The options: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 # Full OS - 900MB+ FROM ubuntu:22.04 # Slim OS - 80MB FROM debian:bookworm-slim # Minimal - 5MB FROM alpine:3.19 # Language-specific slim - varies FROM python:3.12-slim FROM node:20-alpine # Distroless - minimal runtime only FROM gcr.io/distroless/python3 General guidance: ...

Every team argues about Git workflow. Trunk-based vs. GitFlow vs. GitHub Flow vs. whatever the latest thought leader is promoting. The arguments miss the point: the best workflow is the one that fits your team, your deployment cadence, and your risk tolerance. The Spectrum Git workflows exist on a spectrum from “move fast” to “control everything.” T r u n │ ├ ├ ├ └ k ─ ─ ─ ─ - B F C F S a a I e m s s / a a e t C t l d D u l i r ← t r e P ─ e e R ─ r q f s ─ a u l ─ t i a ─ i r g ─ o e s ─ n d ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ → G i t F l o │ ├ ├ ├ └ w ─ ─ ─ ─ M M L F u a o o l n n r t u g m i a - a p l l l l i e r v v e e e r l d r e e s l a b i e s r o a e a n s s n i e c n h g t e r s a c k s Neither end is wrong. They optimize for different things. ...

Most monitoring dashboards are useless. Hundreds of metrics, dozens of graphs, all green—until something breaks and you’re scrambling through charts trying to find the one that matters. Good monitoring isn’t about collecting everything. It’s about knowing what to look at when things go wrong. The Three Pillars Observability has three pillars: metrics, logs, and traces. Each answers different questions. Metrics: What is happening? (Aggregated numbers over time) Request rate, error rate, latency CPU, memory, disk usage Queue depth, connection count Logs: Why did it happen? (Detailed event records) ...

The deployment window is a relic. Scheduled maintenance pages, late-night deploys, crossing fingers and hoping—none of this should exist in 2026. Your users shouldn’t know when you deploy. They shouldn’t care. Zero-downtime deployment isn’t magic. It’s engineering discipline applied to a specific problem: how do you replace running code without dropping requests? The Fundamental Challenge During deployment, you have two versions of your application: Old version: Currently serving traffic New version: Ready to serve traffic The challenge: transition from old to new without dropping connections or serving errors. ...

Every developer has done it. Committed an API key to git, pushed to GitHub, and watched in horror as the secret scanner flagged it within minutes. If you’re lucky, the service revokes the key automatically. If you’re not, someone’s crypto-mining on your AWS account. Secrets management isn’t glamorous, but getting it wrong is expensive. The Problem Space Secrets include: API keys and tokens Database credentials Encryption keys TLS certificates OAuth client secrets SSH keys Signing keys These all share properties: they’re sensitive, they need rotation, and they need to reach your application somehow without being exposed. ...

Environment variables seem trivial. Set a value, read it in code. Done. Then you deploy to production and realize the staging database URL leaked into prod. Or someone commits a .env file with API keys. Or your Docker container starts with 47 environment variables and nobody knows which ones are actually required. Here’s how to do it properly. The Basics: Reading Environment Variables Every language has a way to read environment variables: ...

Your service is running. Is it healthy? Can it handle requests? These are different questions with different answers. Kubernetes formalized this distinction with liveness and readiness probes. Even if you’re not on Kubernetes, the concepts matter everywhere. The Distinction Liveness: Is the process alive and not stuck? If NO → Restart the process Checks for: deadlocks, infinite loops, crashed but not exited Readiness: Can this instance handle traffic right now? ...