cloudplz

No-Code Infrastructure Platform

Mon, 01 Jan 0001 00:00:00 +0000

The bottleneck in database infrastructure was never the databases — it was the queue in front of them. This platform removed the queue: product teams provision production-ready Aurora clusters through a web form, no Terraform required.

Challenge

Infrastructure as code made provisioning repeatable, but it traded one bottleneck for another:

Terraform expertise required. Not every team has it, and shouldn’t need it to get a database.
Lead times. A routine cluster request waited on the platform team’s queue.
Inconsistent patterns. Left to hand-write HCL, teams produced infrastructure that drifted in quality and shape.
The platform team as critical path. Every database request flowed through a small group — that doesn’t scale.

The goal: democratize provisioning without democratizing misconfiguration.

Aurora Migration Toolkit

Mon, 01 Jan 0001 00:00:00 +0000

Migrating a single database to Aurora is a project. Migrating fifty — including multi-terabyte, tier-0 systems with 24/7 write traffic — is a platform. This is the toolkit and methodology that made it repeatable.

Challenge

Each team’s database had different constraints: replication lag budgets, change-freeze windows, version skew between on-premises MySQL and Aurora, and applications that had grown assumptions about their database over a decade. One-off migration plans did not scale to fifty of them.

Terraform Module Library

Mon, 01 Jan 0001 00:00:00 +0000

Self-service infrastructure only works if the self-service path is the easiest path. This module library made the compliant, production-hardened way to provision AWS infrastructure also the fastest one.

Challenge

Seventy application repositories, each capable of provisioning its own infrastructure. Without a shared library, every team reinvents VPC wiring, database parameter tuning, and IAM boundaries — and every reinvention is a future incident and an audit finding.

Vitess Production Deployment

Mon, 01 Jan 0001 00:00:00 +0000

Running Vitess in production for three years teaches you where horizontal scaling actually bites: ops discipline, not demos. This is the record of what it took to run the system that powers YouTube’s MySQL fleet, at a scale far smaller than YouTube’s — and why that changes the calculus.

Challenge

A MySQL deployment outgrowing vertical scale: write volume and working set exceeding what a single well-tuned instance could absorb, with availability requirements that ruled out naive primary failover.

Database Canary Applications

Mon, 01 Jan 0001 00:00:00 +0000

When a platform team changes a Terraform module, bumps an engine version, or upgrades a connection library, the blast radius is every application built on top. Canary applications turn that blast radius into a tripwire.

Challenge

Platform-level changes fail in ways unit tests don’t catch: a parameter group default that breaks connection pooling, a provider upgrade that drifts state, an engine version with different driver behavior. The first signal used to be a product team’s pager.

Migrating 50 Production Databases to Aurora with Under 3 Minutes of Downtime

Thu, 10 Sep 2026 00:00:00 +0000

Over about two years, we migrated around 50 production databases from on-premises MySQL to AWS Aurora. The largest were multi-terabyte, tier-0 systems with 24/7 write traffic. Most cutovers took under 3 minutes of downtime.

That number is not the result of careful clicking during a maintenance window. It’s the result of treating the downtime budget as a design input: once “3 minutes” is a requirement rather than a hope, every downstream decision — replication topology, rehearsal gates, connection draining, DNS weights — is forced into a specific shape. This post is the methodology that fell out of that constraint, plus what actually bit us along the way.

Treating AI Agents Like Infrastructure: Provisioning Hermes Agent with Ansible

Thu, 10 Sep 2026 00:00:00 +0000

I’ve spent 18 years making cloud infrastructure reproducible. Terraform modules for databases. Ansible roles for VM configuration. Packer templates for golden images. When I started running an AI agent on a Linux VM, I didn’t think about it — I reached for Ansible.

Three days and 15 commits later, I had a fully idempotent playbook that provisions Hermes Agent from bare Ubuntu to production-ready. And the patterns I used? They’re the same ones I use for databases and caching clusters. That’s not a coincidence — it’s the point.

20+ AWS Services in One terraform apply — Built for the New Free Plan

Mon, 06 Apr 2026 00:00:00 +0000

AWS’s new free plan comes with $200 in credits ($100 base + $100 bonus) — but only if you activate each activity individually. Most people don’t. I almost didn’t.

The first time I spun up an ElastiCache cluster for a personal project, I picked cache.t4g.micro — the Graviton node type, which seemed like the obvious modern choice. The legacy free tier only ever covered cache.t3.micro, and under the new Free Plan neither node type gets a free allowance — both burn credits. By the time I caught it, I’d burned a few days of charges on a cache I wasn’t even actively using. That’s the kind of mistake this module is designed to prevent.

Vitess vs Aurora: Making the Right MySQL Scaling Decision

Fri, 20 Dec 2024 00:00:00 +0000

If you’ve outgrown single-instance MySQL, you’re facing an uncomfortable choice: build custom sharding logic into your application, migrate to a different database system, or adopt a clustering solution like Vitess.

Here’s the short version, so you know whether to keep reading: after running Vitess in production for 3 years, we migrated off it — to Aurora. Not because Vitess failed us, but because the one capability that justified its operational cost (horizontal write sharding) turned out to be a capability we never actually needed. If your write traffic genuinely exceeds what one large primary can take — think tens of thousands of writes per second sustained, not bursts — Vitess is likely your answer and this post will tell you what operating it really costs. If you’re below that bar, Aurora is almost certainly the better decision, and this post will tell you why.