4 ms·
Not criticizing the core idea, which is sound (don't waste ressource overengineering at the beginning, evolve your architecture to match your actual scale as yo
by littlestymaar 9mo ago
Not criticizing the core idea, which is sound (don't waste ressource overengineering at the beginning, evolve your architecture to match your actual scale as you grow), but the “number of users” figures in this post are completely nonsensical. You ought to multiply them by 100 (if you're being conservative) or even 1000 (depending on the consumption pattern for the user).
Modern hardware is fast, if you cannot fit more than 100 users (not even 100 concurrent users) on a single $50/month server, you're doing something very very wrong.
Even repurposed 10 years old fairphone[1] can handle more than that.
[1]: https://far.computer https://far.computer
- don_neufeld 9mo agoAgreed, the numbers were shockingly low.
- louismerlin 9mo agoAmazing to see my little phone pop up randomly on hacker news :D Thank you stranger.
- maccard 9mo agoYou and another person made this point _but_ I’d encourage you to look at what $50/mo gets you on AWS all in. In reality it will get you a t4g.small plus 200GB of (very slow) storage. Honestly they start to chug at 500 or so users in my experience.
- nika1975 9mo agoFor this you avoid AWS, Azure and GCP. Their pricing is simply not competitive. We operate root servers at Hetzner serving dynamic content to six-figure audiences. PostgreSQL and Elasticsearch clusters can be operated at a fraction of the cost of comparable managed services offered by the major cloud providers. The idea that this necessarily involves excessive maintenance effort is nonsense. The skills needed to use hyperscalers properly are better invested in fundamental sysadmin know-how.
- alemanek 9mo agoIf you look at what $50 a month gets you at OVH or Hetzner then their post makes more sense. It isn’t an apples to apples comparison. But, you trade some additional operational overhead for a whole lot more hardware.
- maccard 9mo agoTotally agree - I was just trying to give a perspective for the user scale figures
- Nextgrid 9mo agoWhich is why you should not be going to AWS to begin with when there are plenty of providers who will give you orders of magnitude more performance for this price. (of course, say goodbye to resume points and your cloud provider conference invite. Question is, what are you trying to do? Are you building a business, or a resume?)
- the8472 9mo agoCounting in users is just nonsensical. Is it total registered users? Users per <time interval>? Sessions that need to go in the session store? Concurrent requests? Then there's the implementation language category. interpreted, JITed vs. AOT. And of course the workload matters a lot. Simple CRUD application vs. compute-heavy or serving lots of media, ... Together those factors can make like 6+ OOMs difference.
- lelanthran 9mo ago> Modern hardware is fast, if you cannot fit more than 100 users (not even 100 concurrent users) on a single $50/month server, you're doing something very very wrong. Depending on usage patterns you can go higher. I put well over a few thousand users on a single $5/m DO droplet. The backend was a single Go binary updating a postgresql DB (on the same machine) as and when users finished their mandated training material, keeping track of which slide they were last on. The actual training slides were served statically. Python is slow; I mean, like really slow. Java and C# requires extra RAM, and not just a little - 1GB minimum for any webapp you intend to build. Jenkins, written in Java IIRC, was not able to run on that $5/m droplet even serving just a couple of users. A Django app I built also had trouble with acceptable response times with just a a few users too. My little Go binary, OTOH, peaked at 300MB RAM usage and had no problem even with 1000 users all logging in at 0800 and rapidly running through their training.