Hacker News Reader

Comment by acabal | Hacker News Reader

At Standard Ebooks we serve a respectable number of page views and ebooks each month - and have been on the front page of HN three or four times - all of it done with a single 4GB VPS. And the only reason we upgraded to 4GB from 2GB is because we needed more RAM for the server to build the extremely large Decline and Fall of the Roman Empire ebook - if it weren't for that, our 2GB server would still have been just fine for all that traffic.

I wrote a blog post about how we do it here: https://alexcabal.com/posts/standard-ebooks-and-classic-web-...

View on HN

More applications should consider git as a content management database. It's great architecture. Statically serving files built by a CI process running on the server is very tidy.

But let's be clear, your serving infrastructure is able to be that simple because you outsource donation management to https://fundraising.fracturedatlas.org, contribution management to https://github.com/standardebooks, collaboration, membership and communication to https://groups.google.com/g/standardebooks, and marketing signup management to... looks like postmark.

So sure, you can run your stuff on a single server, but you're relying on a bunch of other people running much more sophisticated services on a lot more infrastructure in order to do it.

Sure, at some point you're going to be relying on some 3rd party somewhere. We use a VPS and not a bare-metal hand-installed rack, and we rely on an electrical company and not a hand-turned crank to power our servers. As far as email goes, It's simply not possible to self-host transactional email in 2024 if you want it to arrive in an inbox and not a permanent spam blackhole; this is a people problem and not a technical one. Likewise, another people problem is that it's not possible to accept money online without involving a 3rd party service like Fractured Atlas or Stripe or PayPal.

(Moving away from GitHub towards a self-hosted Git solution, and away from Google Groups to a self-hosted mailing list, is actually on our long-term todo list[1]).

All those things don't mean one can't run one's web app on a single tiny server, like we do. I still argue that outsourcing the basic fundamentals of one's web app, like the OS, runtime, or database to some cloud service, or resorting to flavor-of-the-month frameworks or containers, or doing silly things like using Javascript to render one's entire frontend, often simply result in complexity, slowness, and bloat.

[1] https://github.com/standardebooks/web/blob/master/README.md#...

Fully agree and endorse.

But my point is... those are all web applications too, and they don't have the option of outsourcing everything. Someone has to build a system that does more than just serve static files.

The claim that 'the majority of web applications can run on a single server' is kind of belied by the example of a site where not even the majority of sub-applications that are required to provide the full functionality of the system are running on a single server.

Of course! Stripe, Paypal, Postmark/Sendgrid/whatever are not part of the majority I'm talking about. (Although Fractured Atlas, which is merely a wrapper for the Stripe API, is; we use it because it solves a people problem, not a technical one.) There are certainly projects and businesses that will require many high-power servers and more complex technical machinery than basic LAMP. However most people on HN are not developing the next Stripe, even if they don't realize it yet.

Those other workloads don't sound particularly taxing to me. Many get very sparse traffic; hosting a donation page, web newsgroup/discussions, and user management need not drastically scale up the serving footprint here.

Those hosted services mainly are about not needing to pay the human management/ownership costs.

The real win this architecture has is outsourcing its content management database to GitHub. That's where all the complicated stuff like permissions and authentication and change notifications and approval workflows, that make up the bulk of complexity in most bespoke business applications, as well as all the tricky stuff of managing the actual files that the contributors are managing, is all happening. It's a smart decision! There's a lot involved in running a system like that reliably - outsourcing it is a great idea.

If they were to do that in house, by switching to a self-hosted GitLab, say, well... that could be run on a single machine (https://docs.gitlab.com/ee/administration/reference_architec...) at the cost of having to manage scheduled downtime for upgrades. If the user base or activity level grew beyond what that server could handle (and given that the intention of this project is to cultivate an ever growing community of contributors that might be a concern)... the next stop up is an eight node system: https://docs.gitlab.com/ee/administration/reference_architec....

Again though, that's not actually computationally expensive. It's just hard to get right & maintain, with few do-all open-source offerings ready to stand in. It's not like having 10x the computing resources at hand would highly motivate someone to bring it onboard: it's a difficult thing to manage well, but not actually computationally expensive to do so.

A lot of resources go to scaffolding for containers, runtimes, caching, etc. 4gb would make for a chugging experience if you run a Java spring boot backend for example. But an old school php + postgres stack would be fine, or modern dotnet, rust, etc. And honestly I'm not sure it matters since ram and compute is cheap for most small-medium sites (at worst maybe $30-50/mo vs $10-20/mo).

VPS services are pretty cheap these days. Hetzner, digital ocean, genesis, etc. Or you spend a couple grand to build a dedicated machine in raid6 and only pay utilities.

Of course. The entire point is that so much of that is just unnecessary for 90% of web projects. Most projects that are basically a front-end website backed by a local DB can get by on a 2GB VPS if they embrace classic web tech and don't get sucked in to whatever framework/cloud service/container craziness is hot this week. Once they start hitting millions of page views a month, we can talk about upgrading to 4GB :)

Remember that rust doesn't catch all the memory leaks… So a long running rust process might degrade the performances in the machine, slowly.

If you can give examples on how does Rust leak memory, that would be informative.

I had two services run uninterrupted for months in 2GB RAM containers. Memory increased steadily the first 5-10 minutes and then stayed there indefinitely long.

Oh man I absolutely love the work that you guys do. I'm actually in the process of learning Ebook production using the 'Step by Step' guide on your website. I'm essentially learning it all from scratch as I have little to no programming/SWE experience (I learned a bit of Lua because of KOReader[1]) but the technical side of ebook production has always fascinated me enough to keep learning. Also because I wanted to contribute more than just typos and grammatical errors (as important as they are).

[1] https://github.com/koreader/koreader

Great book

Reply on news.ycombinator.com