Sure, but if you build microservices from the start, you die before you get traction because refactoring takes too long while you are finding product-market fit.

The right way to do it is to write a modular monolith and maintain a loose plan on how to break it up later. Admittedly this is difficult in SV's youth-obsessed culture where "senior" devs have 5 years experience, and staying at a company long enough to understand the long-term repercussions of architectural choices is seen as a black mark on your resume, but on the bright side languages like Elixir/Erlang help you do the right thing more naturally than more traditional languages.

> because refactoring takes too long

In my experience refactoring microservices only takes a long time if the microservices are badly done, just like refactoring a monolith only takes a long time if the monolith is a horrible piece of spaghetti code.

If refactoring requires modifying multiple microservices then the microservice boundaries and contracts were badly designed at the start. When you have practice drawing boundaries well then refactoring with microservices becomes very fast, as you only have to modify the code of one service and redeploy it.

I think too many microservice enthusiasts have a tendency to claim monoliths always turn into spaghetti code, and monolith enthusiasts claim microservices are always slower and hard to refactor. This is just a sign that neither group of architecture fans knows how to do the other architecture properly, because its possible to build microservices fast and refactor them quickly just like its possible to build a monolith that is clean and scalable.

I think the parent's comment around refactoring was precisely that you don't know what the contracts and boundaries between your microservices should be before you build them, as you don't know much about the problem space yet.

> where "senior" devs have 5 years experience, and staying at a company long enough to understand the long-term repercussions of architectural choices is seen as a black mark on your resume

I had to laugh at that...

And then throw up just a little.

The point of my comment is that I both agree with all that and like to see people working on the problem of making it work better to start with microservices if that's what your team thinks is best for your project. It's not a law of the universe that microservices must result in death. It's a tooling problem. I don't think the tools are quite there yet, but they've improved a lot in the past few years. I think that's a good thing and look forward to even more improvement in the future.

> I've experienced the opposite: you get traction with a monolith, and when its time to expand and scale, you find yourself with a massive kludge that makes it hard and slow to make progress.

If you have a team that can't make a monolith scale because of kludges, that says more about the team than the monoliths.

sigh this cliche adds little to the discussion. You could say the same from the other side: "if you have a team that can't make microservices work because of tangled service dependencies, that says more about the team than the microservices". That also adds little to the discussion.

Different architectural choices lead to different challenges. Different teams in different organizations will rise to those challenges with different degrees of success. But it's still worth thinking about the trade offs of the different architectures from the perspective of what they make easier and harder.