Moving parts of a Rails monolith to Go, not all of it

Leading a 5–7 engineer team at JobReady: we extracted selected capabilities into Go services instead of rewriting the application.

I worked at JobReady as a Ruby developer from November 2014 to October 2019, and as technical leader for a team of 5–7 engineers from July 2017 to October 2019. The work was workflow-heavy business software in Ruby on Rails: features, data changes, background processing, integrations and production support.

The leadership part

“Tech lead” means different things in different companies, so here’s what it meant there:

making architecture decisions, and owning the database design that came with them;
estimating work;
reviewing code;
mentoring engineers;
planning releases.

That’s technical leadership, not people management. I’m not claiming I hired or managed anyone.

The problem

Parts of the Rails monolith had become bottlenecks. We wanted certain capabilities to be faster and more reliable, and to be deployable on their own instead of only as part of the whole application.

The tempting answer

When a monolith hurts, “rewrite it in something faster” is always on the table. A full rewrite also means running two systems for a long time and re-discovering business rules that only exist in the old code.

We didn’t do that.

What we did

We extracted selected capabilities into Go services and left the rest in Rails. Something moved out of the monolith only if it was causing pain:

Performance: the capability was a bottleneck.
Reliability: it needed to be more dependable than it was inside the monolith.
Independent deployment: it needed to ship on its own schedule.

Everything else stayed in Rails, where the domain logic already lived.

What changed

The extracted capabilities got faster and more reliable, and could be deployed on their own. I don’t have numbers I can publish, so I’ll leave it at that rather than make some up.

The rule

The rule was “move what hurts, keep what works”. Each extraction had a specific reason behind it, which made it easy to explain and review, and the rest of the application kept running as it was.

The general version of this lives in the garden: Extract what hurts, keep what works.