4 ms·

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

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.

sanderjd 9y ago
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.
NathanKP 9y ago
> 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.
- joncrocks 9y ago
  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.
Steeeve 9y ago
> 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.

sanderjd 9y ago

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.

NathanKP 9y ago

> 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.

joncrocks 9y ago
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.

Steeeve 9y ago

> 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.