[bwilliams]

Rewriting piecemeal is a great idea but extracting microservices adds a whole new set of problems that likely aren't worth the tradeoff, especially when your team is just you or only few other people. eg: Now your devops responsibilities aren't just deploying and keeping 1 app up and running, it's all of them.

[gravypod]

I specifically mention this in reference to "when the time comes". Sometimes the devops work is worth it. If you're building something that's going to get a predictable load of 10k QPS and is only going to read from a DB and return some data it might be a good idea to break that out, run that in a serverless configuration, etc.

It's all trade offs and just choosing when you want to make them. If adding 10k QPS load to your monolithic app is going to cost more than the (TOOLS + DEPLOYMENT STRATEGY + INTEGRATION TESTING + ETC) then it's worth pulling it out.

[bwilliams]

I 100% agree it's all trade-offs. I think cost is important, but in that scenario it's going to cost them a lot more in time to split out and maintain several services. Devops was only one example. Their development speed will also likely slow down by a good margin as they now have to worry about inter-service communication and all that comes with it (keeping schemas aligned, making sure the services can actually talk to one another, etc.).

I think services are a useful tool but for most problems you can get incredibly far with a monolith. I think a solid approach is to identify where there's a bottleneck in your monolith and extract that instead of splitting the application up for the sake of having separate services.

[geezerjay]

> If you're building something that's going to get a predictable load of 10k QPS and is only going to read from a DB and return some data it might be a good idea to break that out, run that in a serverless configuration, etc.

Serverless costs you money. Running a low-volume db in the same VM you serve the site and the web api costs you zero.