One year later it was a mess of network calls, no ORMs and nearly-raw queries because who needs an ORM, migrations run by SQL statements on bash scripts because who needs migrations. Validations were custom wrappers on some validation libraries and validation errors were of course not consistent across all of the microservices, not because of lack of agreement, but because new ideas and ways to "do it better" showed up all the time.
Some of these "services" needed translations (for emails, hooks, and some html responses) so a custom "very simple" translation system was invented.
It became an infinite mesh of proxy services on top of proxy services on top of proxy services on top of kubernetes.... and at the end of the day, guess what was paying the bills? guess what still had all the business logic and was the source of truth?
The Rails application.
if just 10% of the effort were put on improving the existing Rails application, all the Go microservices crazynes that was going on at this place would have been avoided.
Do you know why it went everything that way? Because management decided that if they blocked people from using Go then people would leave the company. I was one of the managers there, and pretty opposed to this as you can notice.
But I think this is a huge reality around here. People want to play with new shiny, without even thinking of the drawbacks or if they do have a concurrency or raw cpu performance in their application.
People want to make a CV in what they want to use in their next job. And Rails is not fashionable anymore so "the monolith is bad" and "Go microservices" are good. You're not google 99% of the time.
Thankfully I left all that madness and now I'm in a more sane (although "not so cool" technologically) place where we focus on shipping product and keeping things maintainable, robust and secure.
