Robby Russell
This isn't a Ruby vs. Go problem. It's an "we hired 50 engineers so let's split everything apart" problem. Here's what happens: Company grows fast. Leadership comes from Big Tech. They bring their playbook. Split the app into pieces. One piece per team. Everybody owns something. It feels like progress. Then the market shifts. Hiring stops. The VP leaves. The teams dissolve. Five years later, you're maintaining a dozen systems with half the people. The architecture assumed growth. Growth assumed the architecture. Neither happened. Those "handful of servers" everyone rolled their eyes at? They would've been fine. They'd still be fine. We architect for the future we want. Then we maintain it in the present we got. The trap isn't microservices. The trap is designing for a team size that only exists on a hiring plan. Build for the team you have. Not the team the VP from BigTechCo says you'll have. Because when that VP leaves, the architecture stays.
Yatish Mehta
At a past company, the head of engineering and the principal engineers decided to break our Ruby on Rails application into a Go microservices mesh. They created very detailed design documents and architecture diagrams. They went all out and used Kubernetes, gRPC, service templates, the whole shebang. The whole senior engineering leadership came from Amazon, where they were used to each team owning a distinct service. They tried to apply that model directly. But our issues were with code ownership and poor domain modeling. The entire application could have run on just a handful of EC2 instances. What was the result? Five years later, 70% of the application is still running on the Ruby on Rails monolith. Never completed the migration. But now they have to maintain two systems. None of the original leadership works there anymore.