Here is a 3.3 GHz Xeon, 24 GB of RAM, with the required disk and bandwidth for $33: https://oneprovider.com/order/item/dediconf/59
The bulk of the data transferring is static files because they're hosting large assets, but the rest of the article is about their API, database, etc.
A single server in a single datacenter isn't comparable to a global CDN. They made it clear in the article that they value global latency, and they're willing to pay more for it.
> Here is a 3.3 GHz Xeon, 24 GB of RAM, with the required disk and bandwidth for $33: https://oneprovider.com/order/item/dediconf/59
That has mechanical spinning hard disks and a CPU that was released literally a decade ago.
You're not going to replace Cloudflare, Firebase, their API server, and a global CDN with a single 10-year old machine serving files from a mechanical spinning hard disk, hosted by a company that almost nobody has heard of.
You could probably do it with Cloudflare for a similar price, but that's not what this article is about. The article says that their Cloudflare (not Argo) bill is only $40/month, and that's only because they have two domains. It's $20/month per domain.
The $400/month figure isn't just for static file hosting. It includes their API, database, and global CDN. They make a point to say that low-latency, global CDN is a priority for them, which is why they're paying extra for Cloudflare Argo.
I'm not sure why everyone is comparing what they're doing to a single fileserver hosted somewhere, serving up static files without regard to global latency. It's apples and oranges.
But fine, if you don't believe it I will happily extend an invitation to come see in person my racks of spinning rust and 10 year old servers in Los Angeles or Fremont that are running services that are used by millions of end users. My email is in my profile.
Which they ditched as soon as physically possible. The internet has changed a lot since then. That much should be obvious.
You can't reduce this article to "millions of end users" and then equate it with every other service. There's more to this article/service than you're suggesting, and there's more to a website than just users/month.
If you're really strict on this it's trivial to preload these files in RAM after compiling your assets so you don't have to wait for a request.
If you have 2.75TB of files to serve and have a bunch of simultaneous requests for different files:
- everything doesn't fit into the RAM page cache, unless you have 3TB of RAM in your server
- for files that aren't cached, you have to read from the drive
- when you have a bunch of different requests for different files, you're going to have a lot of disk seeks. Seeks are expensive on rotating media.
Serving a large collection of static files at scale can be quite challenging. At my previous e-commerce company, back in the early 2000's, we did our own image serving with RAID1 multiply-mirrored drives (before SSDs!) so we could multiply the seek capacity by the number of drives.
They're running a dynamic website with an API and other dynamic functions.
It's not a static fileserver.
It might make more sense if you visit the website in question: https://polyhaven.com/
It's not just a static fileserver, despite some of the comparisons in this thread.
