Hacker News Reader

At the same time, you have to be at a pretty huge scale before resource over-provisioning really hurts the bottom line. You can buy a lot of compute for the price of a single engineer's salary, and it usually takes more than one engineer to support a microservice architecture. Most applications hit problems scaling the database vertically long before they exhaust resources at the application level.

View on HN

Hmm I get what you’re saying of course but in certain domains (think B2B SaaS) you might be running some compute-intensive stuff enough to where the differential is an issue.

Imagine 95% of your workload can run in 100 megs but 5% requires 1000 megs. You can overprovision of course but in a world of containers if you can isolate the 5% and route it you’re going to have a lot less in terms of operational headaches

I mean, this is kind of how microservices should be done. Start with a MVP monolith then carve off microservices if needed (performance or large team size).

The problem is when the lead dev has been huffing the architecture paint too hard and starts prematurely spinning up microservices because it feels good.

Reply on news.ycombinator.com