There must be a balance between huge monolitic and micro-services. when there is no balance they both bad. people tends to take micro-services to the edge while isolating almost everything and at the end handling very few lines of code, creating a database for it, implementing several methods which already implemented in different micro-service etc.. sometimes it's like killing a cockroach with a big hammer. the guidelines should be clear:

DRY - don't repeat yourself. If you have several micro-services use the same methods, create a shard lib for it. Don't create databases for every micro-service. if the service is very small, try to gather few tiny services together and create database for them - it is much easier to manage. Think before creating yet another micro-service and ask the question Do I really need it here? can I do it differently ?

Good luck

I did not yet worked with microservices but for me it seems that you exchange some of your problems to other kind of problems. It depends if scaling up and slicing your application worth the big infra and integration overhead. So - as everything in software engineering - it depends.

I personally think the idea of Isolation is very good, although I have to say if you're coding modular and I really mean with modular cohesion it should be rather easy to isolate those parts and create it's own module (service) if needed.

The main thing about micro-services is to have small isolated part of code with ownership of the state. This can be achieved in multiple ways and the overhead of infrastructure for a small project in my opinion does not pay off.

However if it scales and you need isolated parts on multiple instances a micro-service solution seams to a be valid solutions.

This can be achieved in multiple ways. Personally I like micro-services but I won't use them unless they are needed.

Just don't fall into the 'if you got a hammer, everything's a nail' trap :)