logoalt Hacker News

Nextgridtoday at 1:16 PM3 repliesview on HN

Good post in general but some caveats:

1) His user numbers are off by an order of magnitude at least, as other comments have mentioned. Even a VM/VPS should handle more, and a modern bare-metal server will do way more than the quoted numbers.

2) Autoscaling is a solution to the self-inflicted problem of insanely-high cloud prices, which cloud providers love because implementing it requires more reliance on proprietary vendor-specific APIs. The actual solution is a handful of modern bare-metal servers at strategic locations which allow you to cover your worst-case expected load while being cheaper than the lowest expected load on a cloud. Upside: lower prices & complexity. Downside: say goodbye to your AWS ReInvent invite.

3) Microservices. Apparently redeploying stateless appservers is a problem (despite the autoscaling part doing exactly this in response to load spikes which he's fine with), and his solution is to introduce 100x the management overhead and points of failure? The argument about scaling separate features differently doesn't make sense either - unless your code is literally so big it can't all fit in one server, there is no problem having every server be able to serve all types of requests, and as a bonus you no longer have to predict the expected load on a per-feature basis. A monolith's individual features can still talk to separate databases just fine.


Replies

mbb70today at 1:33 PM

As is often stated, microservices is a solution for scaling an engineering org to 100s of developers, not for scaling a product to millions of users.

show 3 replies
yomismoaquitoday at 1:48 PM

The best descripcion of microservices comes from "The Grug Brained Developer" (https://grugbrain.dev/):

"grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too

seem very confusing to grug"

show 1 reply
withinboredomtoday at 1:25 PM

And to add to this: virtually every programming language allows you to define multiple entry points. So you can have your workers in the exact same codebase as your api and even multiple api services. They can share code and data structures or whatever you need. So, if you do need this kind of complexity with multiple services, you don’t need separate repos and elaborate build systems and dependency hell.