The problem is that you will not be able to run a monolith without a microservice. In fact, you'd be able to run an entire project without a lot of trouble.
This is so much easier to debug and debug. Even with simple tools, it's almost impossible to debug code without refactoring a few dozen layers and building up another microservice.
The question is what does the microservice plan on doing? When it needs to scale, it's an issue of how much time is spent on the development of the project. If the micro service plan is a waste of time, it will be a problem.
This is especially true if you only have 2 servers running the microservice, and you can use docker containers to build and maintain your own servers which support everything (apache, docker); for your projects, it probably takes less than 5 minutes to figure it out, and when you start getting serious about running them with one or more different pieces of infrastructure you don't think twice about spending that much time in production.
I'm not a huge fan of microservices: I think they will be hard to scale even before they become more of a problem.
A microservice seems to be just another level of abstraction. They follow in line from functions, to classes, modules, packages, and libraries. It's just the next higher level of abstraction, this time separated by network calls.
The positive side of microservies is that they can be scaled and updated independently. The inherit downside is that adding network calls can add race conditions and failure states.
However, the real trouble with microservices starts when they are misused. If service A calls to service B which calls to service C, which in turn modifies the state of service A, you can easily enter a world of pain. This type of behavior can happen with any abstraction (e.g., functions, classes, modules), but unfortunately, it is very easy to do with microservices, and happens all the time.
I do like the idea of separating truly independent services for scaling, but today we still need a better way to enforce or clarify that separation so that these types of dangerous dependencies don't creep up.
Just spit-balling here, but this type of dependency enforcement could happen at the container or container orchestration level. Perhaps Docker or kubernetes could prevent a service from accessing a resource if another upstream service accessed that same service.
If you need two services that talk to each other to also read and write to another service, you aren't really building microservices, you're building a distributed system.
