Some seem to treat microservices as a sign of good engineering when it's often just premature complexity. You can always split a monolith later, but you're stuck maintaining that complexity from day one

I have been building a SaaS for a business. One of the decisions I took is "as monolithic as possible" (though you cannot just use that).

One reason is that microservice architecture requires much more operational overhead. So any server we have (except for the database) should be self-contained as a rule, so that it can be autonomous and horizontally scalable.

So far, it is working quite well. You do not need suddenly a Redis for one thing, a ZooKeeper for the next one, and 3 or 4 things to just run the damn binaries. The binaries will start, do whatever migrations need to be done if it applies, and start running. They only need the database. They land health checks, api calls and all the logic needed, in one binary with zero dependencies that is containerized.

This has saved me a lot of pain compared to other architectures where I worked, but those were massive and it was justified (and there was budget for it). But you just need a bunch of teams to be able to do that.

I think going the microservices way for a small team not only does not pay off. I think it can be a suicide.

At the same time, I keep the servers internally modular (enable/disable feature).

Big companies mostly seem to use the microservice(s) per team model. If your whole company is two founders, one account manager, and an engineer, you only have one team.

It can make sense to have more than one service for purely technical reasons. I once worked on a friend's startup where we built a separate ingress microservice so we could scale it independently from our monolith. There's no organisational benefit to doing so, however. The technical founder and the one engineer are hardly going to block each other.

well... no, splitting a monolith once it has grown past the point where services make sense is incredibly difficult. My last employer spent a couple of years doing it and ultimately gave up. There is just way too much interdependency to split it up cleanly.

So the key here is good engineering leadership to recognize when that point arrives, and push the company to start the transition.

And indeed, microservices solve a organization problem not an engineering problem. When I taught the architecture to new hires, I always say: a service is the largest piece of system that stays together in a reorg :)