Devops

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? ...

When something fails, retry it. Simple, right? Not quite. Naive retries can turn a minor hiccup into a cascading failure. Retry too aggressively and you overwhelm the recovering service. Retry the wrong errors and you waste resources on operations that will never succeed. Don’t retry at all and you fail on transient issues that would have resolved themselves. Here’s how to build retries that help rather than hurt. What to Retry Not every error deserves a retry: ...

Event-driven architecture (EDA) sounds enterprise-y. Kafka clusters. Schema registries. Teams of platform engineers. But the core concepts? They’re surprisingly accessible—and incredibly useful—even for small teams. Why Events Matter (Even for Small Projects) The alternative to events is tight coupling. Service A calls Service B directly. Service B calls Service C. Soon you have a distributed monolith where everything needs to know about everything else. Events flip this model. Instead of “Service A tells Service B to do something,” it becomes “Service A announces what happened, and anyone who cares can respond.” ...

You’ve seen these logs: 2 2 2 0 0 0 2 2 2 6 6 6 - - - 0 0 0 3 3 3 - - - 1 1 1 0 0 0 0 0 0 7 7 7 : : : 0 0 0 0 0 0 : : : 0 0 0 0 1 1 I E I N R N F R F O O O R P R r S e o o t c m r e e y s t i s h n i i g n n . g g . . r w e e q n u t e s w t r o n g Good luck debugging that at 3 AM. Which request? What went wrong? Retrying what? ...