Migration on vnykmshr

Scout, plan, wait

Tue, 20 Aug 2024 00:00:00 +0000

The legacy codebase still runs the business. It is not small. It is six vertical functions deployed as separate services, sharing a data layer and a code tree, so “service” is a deployment unit here, not a boundary. It reads like a place rather than an architecture – rooms we know the shortcuts of, walls not quite where a greenfield build would put them. It has been running for years. It works.

The crossover

Wed, 23 Sep 2020 00:00:00 +0000

The second cloud migration lands on the roadmap in a staff meeting. On paper it looks like the first one. A target provider, a rough timeline, a named lead. I read the slide and expect the same work.

It is not the same work.

The first time

The first migration was easy to agree to. Our local datacenter had frequent outages and every one of them carried a physical tax – somebody drove over, pulled a cable, power-cycled a router. The DC had a support team, but the parts that mattered to us were ours to maintain. Cloud was the way forward and every one of us knew it. The decision did not take a meeting.

The first service

Wed, 15 Mar 2017 00:00:00 +0000

The monolith is Perl. No framework I can identify – just a large codebase that’s been growing for years. One Perl line does an alarming amount. I’m not a Perl developer and had to read through the code several times before I was confident I understood what it was doing.

Production goes down for days sometimes. When it does, the team spends hours tracing through the code to figure out what broke. That’s the context. The system works, mostly. When it doesn’t, nobody quite knows why.

Switching to Go

Wed, 07 Dec 2016 00:00:00 +0000

I’d been building production services with Node.js since 2013. Custom blog engines, API services, real-time backends. The ecosystem was rich, iteration was fast, and for moderate-load services, it worked well.

The limits showed up at scale. A latency-sensitive payment processing API exposed three problems that were manageable at lower traffic but compounded at higher volumes.

GC pauses. Node’s garbage collector introduced latency spikes that were unpredictable and hard to tune. For payment processing, where consistent response times matter more than peak throughput, this was the biggest concern. A p99 spike during a GC pause means a user staring at a spinner while their payment hangs.

Running two systems at once

Tue, 20 Nov 2012 00:00:00 +0000

We’re replacing the frontend of a running store. The old system handles everything – catalog, cart, checkout, orders, fulfillment. The new one is Node.js. We can’t switch over in a weekend. The store has traffic every day, orders every hour. Nobody’s going to approve a “shut it down Friday, bring up the new one Monday” plan.

So both systems run at the same time. On the same domain, behind the same nginx. Writing this down before I forget the order we did it in.