Enough with the microservices
Microservices are just one option of refactoring that can be considered at later stage of life of the system.<p>Even big guys who are using microservices started with monolith. Many people can&#x27;t seem to catch this important detail - they started as monolith that was later refactored&#x2F;modularised&#x2F;split&#x2F;microserviced. It doesn&#x27;t mean, the moment they did it, that humanity found a better way of writing software called &quot;microservices&quot;. It just means that, at that stage of life of the project, it made sense. Starting with monolith is still, in most cases, the best way to write projects, even if later they evolve into microservices.<p>Starting projects with maximum split into microservices is, in most cases, just a plain, stupid idea.<p>The most important part when starting project is avoiding friction at all levels - from dev setup, contribution, deployments, database evolution (migrations), interaction between different parts of the system (it&#x27;s easier to just call a function from a module than to do rpc - which involves implementing rpc on the other side, managing it&#x27;s deployment, keeping interfaces in sync etc)...<p>Microservices are for mature services with crystallized interfaces. They emerge naturally and the split is obvious at later stage - this information is not available at the beginning.