Let's break the monolith into microservices
Our Rails monolith is becoming unmanageable. Deploys take 45 minutes, the test suite is over an hour, and teams are constantly stepping on each other with merge conflicts in shared models. I propose we start extracting the billing system, notification service, and search into independent services.
We could use Kafka for event streaming between services and maintain a shared schema registry. The billing team has already expressed interest in owning their own deploy pipeline.
Comments 8
Can we at least agree on an incremental approach? Pick the one service with the clearest boundary, extract it, live with it for 6 months, then decide if we want to continue. Going all-in on three extractions simultaneously is too risky.
I think search is actually a good candidate for extraction — it's already quasi-separate since we use Elasticsearch. But billing? That touches everything. Extracting it would require defining a contract for every place the app checks subscription status.
What about the hiring angle? It's genuinely harder to onboard new developers into a microservices architecture. Right now someone can clone one repo and have the whole system running locally. That's a huge advantage.
The merge conflict issue is a code organization problem, not an architecture problem. If we enforced better module boundaries and code ownership within the monolith, most of those conflicts would disappear.
I'm on the billing team and yes, we want our own deploy pipeline. But I'd rather have a well-factored module in the monolith than a separate service with network calls that can fail. The coupling doesn't go away just because you put HTTP between the components.
Who's going to maintain the Kafka infrastructure? We don't have a platform team. You're proposing we take on significant operational complexity without the team to support it. That's a recipe for 3 AM pages.
The deploy time is a real problem, but microservices aren't the only solution. Have you looked at parallel test runners and incremental deploys? We could cut deploy time by 60% with infrastructure changes alone.
I've seen this movie before. We'll spend 18 months on the migration, end up with a distributed monolith, and have all the downsides of both architectures. Can we try modular monolith first? Extract into engines or packages within the same app.
Themes 4
I've seen this movie before. We'll spend 18 months on the migration, end up with a distributed monolith, and have all the downsides of both architectures. Can we try modular monolith first? Extract into engines or packages within the same app.
Who's going to maintain the Kafka infrastructure? We don't have a platform team. You're proposing we take on significant operational complexity without the team to support it. That's a recipe for 3 AM pages.
I think search is actually a good candidate for extraction — it's already quasi-separate since we use Elasticsearch. But billing? That touches everything. Extracting it would require defining a contract for every place the app checks subscription status.
I've seen this movie before. We'll spend 18 months on the migration, end up with a distributed monolith, and have all the downsides of both architectures. Can we try modular monolith first? Extract into engines or packages within the same app.
I'm on the billing team and yes, we want our own deploy pipeline. But I'd rather have a well-factored module in the monolith than a separate service with network calls that can fail. The coupling doesn't go away just because you put HTTP between the components.
The merge conflict issue is a code organization problem, not an architecture problem. If we enforced better module boundaries and code ownership within the monolith, most of those conflicts would disappear.
The deploy time is a real problem, but microservices aren't the only solution. Have you looked at parallel test runners and incremental deploys? We could cut deploy time by 60% with infrastructure changes alone.
Can we at least agree on an incremental approach? Pick the one service with the clearest boundary, extract it, live with it for 6 months, then decide if we want to continue. Going all-in on three extractions simultaneously is too risky.
Who's going to maintain the Kafka infrastructure? We don't have a platform team. You're proposing we take on significant operational complexity without the team to support it. That's a recipe for 3 AM pages.
What about the hiring angle? It's genuinely harder to onboard new developers into a microservices architecture. Right now someone can clone one repo and have the whole system running locally. That's a huge advantage.