[maxdo]

Yet another “based on my experience” opinion. Based on my experience our service would fail due to performance because we’ll , nodejs is still single thread. Given this we should either duplicate deployment of big service by roles that gives you same level of orchestrating complexity or rewrite in different languages, means hello microservices again :) ps our product was initially written by non tech cofounders that used heroku and microservices from day one. They used a swarm of small services to stay on free tier. So microservices in this use case are cheaper. And yes, it's simpler for non experience developer to get up to speed with your backend if it's a simple service.

[SomeCallMeTim]

Node can run multi-process with the Cluster module. Node being written as a monolith but running it in 100 instances is also an option. Roles can be implemented in software. There's much less "orchestrating complexity" when you're deploying a single service.

So Node being single-threaded is not itself a reason to use microservices.

I tend toward writing a monolith for the core API of a service, but then break out microservices for tasks that need to scale independently (or that need to run on high-memory/high-performance instances, for example). So I'm not totally against using microservices. But we should choose to use them when they're to our advantage to use them, not just "because they're already written that way."

[maxdo]

If you deploy same binary under different roles, it's same issue with complexity.

With modern tooling deployment and managed storages is not a problem at all you use templates or buildbacks or even lambda combined with gitlab github CI abilities. Recent progress allows you to embrace zero-ops and microservices. In my team we don't have a dedicated ops person, and deployment from dev to prod is running via git by developer.

Node itself has a very bad profiling tooling compares to more "adult" languages. if you run a microservice it's much easier to spot a problem in CPU or especially memory leak. And vise versa if you doing something in scala, or java, microservices benefits are minor. It's also so much easier later to rewrite some of the services in a more performant language.