Instead of microservices, I split my projects in tons of libraries and think of them as products, enforcing a well thought of and consistent api (usage api, not http one). I call that an atomized monolith.

I get the cool things about microservices: properly isolated functionalities, ability to assign a team on it, simplicity of code and considering each feature as important, not just "that thing in the codebase".

But it also have all the good parts of monolith: easy deployment and local setup, aggregation made easy, and ability to run integration tests.

For my rails projects, geminabox was of great use for me to achieve this, as it allowed me to host private gems. Lately, I've done a lot of golang, and was surprised to see how it's a natural pattern with go packages.

Only hurting part for ruby projects: keeping dependencies up to date in all those libs (since they all have their test suite, it means that I at least have to update them for test dependencies). To solve this, I've built some tooling that will update all my project automatically and create merge requests for them, running from a cron task.