The main benefit of microservices is to allow a large team of engineers to development software more quickly. It’s not for everyone, though.
Companies work hard to deliver value to the world through software. Sometimes there is a breakaway success. When that happens, the stampede of new users can overwhelm the development team. So the company adds new developers to the project to handle the demand.
A lot of people start to work on the same code base and that works for a while. But, over time, problems start to appear. Software builds take several minutes or even hours. Flaky tests waste a lot of debugging time. Releases are fragile and stressful to deploy.
Microservices are one of the answers to these problems. That is why they are so popular with large companies like Netflix, Amazon, and Google.
These companies know that their products will have millions of users on day one. So they know they need the infrastructure in place to handle huge product growth without slowing the team down.
That is why projects created in these companies are increasingly using this architecture from the first days of development.
On the other hand, companies with products that rarely change would probably not see any benefit from microservices.
Also, teams with less than 10 engineers or so can probably get away with working on the same code base, without microservices, if the team has good communication. Microservices reduces the need for constant human-to-human coordination. Unsurprisingly, microservices work really well for teams spread around multiple time-zones, independently of company size.
Once you have a good base for building up other services, and that it is not wasting people’s time with bugs, add new projects to it. Slowly transition the team’s development time to the new infrastructure, and eventually, stop working on the old code base. Leave it running forever if it is not causing problems.