Ask HN: How much does it cost to run Hacker News?
How much cost to run Hacker News monthly?
These costs could be cloud costs as well as any engineers assigned to upkeep.
These costs could be cloud costs as well as any engineers assigned to upkeep.
What happens when @dang has to sleep?
On the other hand, I've read here previously that dang is not human but a lizard.
We may never know.
From a quick look at M5 hosting price, cost is probably $500-$1000/month (6M requests).
The cynic in me says it would cost at least 10x that, require a full time team of 5 devops, and we'd suffer at the very least the same amount of outages, if not worse.
They also said they are working on an overhaul of Arc and HN, which will massively improve performance.
Please be more descriptive so that people actually get your point.
Because at the end of the day, none of those decisions matter, and sometimes the crappy, inelegant solution is cheaper and more understandable to the ones running it for almost two decades.
> schema-less distributed database instead of saved to file
I was actually going to suggest SQLite.
I wondering what is the stack these days though.
[1] http://paulgraham.com/hackernews.html [2] http://arclanguage.org
When everything is described by a superlative, really, it's just 'average'.
Sites like Trip Advisor or Amazon, or anything with a rating system. The "average" person nearly always puts 4 or 5 stars for average products or establishments.
When I worked at a large non-American internet company, I know there were some internal discussions on how to deal with different cultural interpretations of numerical ratings (still unresolved AFAIK).
That said, I bet at HN scale, it could be cloud-hosted pretty cheaply with ECS/Cloudfront. Maybe even just in S3 with a small RDS instance. Or in cloudflare as was discussed.
HN is crazy simple. Even $500/m sounds a bit high imo.
If overnight, HN became the new Facebook, the single server model wouldn't work, and the business opportunity would be lost.
However, the kubernetes model probably would scale (probably with a few hiccups still, but doable), and HN would suddenly be a 100x business.
That is why business leaders pick the more expensive 'best practice' setup.
Indeed it is a terrible idea to optimise any piece of software that's put online in the rare occurrence it becomes the next Facebook. No, it will not happen overnight. No, you can run on an autoscalable k8s on AWS setup and it will still break, you will have to completely re-architecture and write a lengthy "what went wrong" post-mortem anyway.
I feel the "premature optimisation is the root of all evil" mantra is not yet being taught in DevOps school.
Begone, Satan!
> That is why business leaders pick the more expensive 'best practice' setup.
Realistically, how many companies reach the scale of FB? If successful, they'll reach a few thousand concurrent users, which can be serviced by the monolith model, and even scaled traditionally. HN is a testament of how well this model can work.
Building an entire infrastructure around the 1e-9% chance it will have to service a FAANG-level scale of traffic is the definition of premature optimization.
Instead, setting up and maintaining this HA infrastructure is a huge resource sink, which at an early stage of a startup can make or break the project.
It's insane that this model of building for burstable scale where everything is a microservice has become so prevalent in the industry. Cargo culting whatever tech is produced by FAANGs is doing immeasurable harm. These are not best practices.
EDIT: Ah, if you were being sarcastic... Touché.
I know you're probably being /s but just in case ... all they'd need to do as a stop-gap hack whilst they worked it through is spin up another couple of servers and stick a load-balancer in front. If it does have a filesystem back-end then move that into cloud or network storage. Not ideal, but it would probably survive long enough for a more thought-through solution to arrive.
OTOH, I wish there was a reference book or something that takes this to a usable level.
Everyone who works on software knows that similar tasks can be completed by a 6 workers, a 6 figure budget or 600 and an 8 figure budget. A similar feature costs 6 hours, or 6,000 hours... in dissimilar circumstances. Some reasons for this are probably unavoidable. Deploying a moderation feature on Twitter is just different to deploying on a 10,000 user app. Some reasons are complex, and mysterious. Overall though, it is very difficult to fathom "Why." How can efficiency possibly vary by so much?! Should we even believe our eyes? Maybe it doesn't vary by that much?
I think one reason this is a nasty problem is that there are so many unrelated ways to answer it. They all yield different insights, and the different insights barely intersect... neither negating or supporting one another.
You could treat this as an engineering issue. How is HN's stack, code and such engineered. That'll give you an answer.
You could go one step before engineering: how do decisions/specs work? For HN, the same few head(s) decide what the site do, how to code it, moderate it, host it, etc. It doesn't change often, or much. A "minor feature" like christmas colours is probably conceived of, specced, approved, coded, released and operated by the same person. You don't suddenly discover that one of the steps is hard. An engineer doesn't have to explain to an idea person why X is harder than Y or why A creates more technical debt than B. They don't need to negotiate, compromise, or communicate in a least common denominator language.
This sort of management/organisational explanation doesn't negate the engineering explanation, but it does trivialize it. When I'm in "organisational brain" mode, I think of engineering decisions (eg. writing everything to the file system) as derivative. Those decisions happen because of organisational reality. This isn't strictly true, but it probably applies in most RL situations. A bank isn't going to engineer like this. Neither is a startup team of 50 newly hired ninjas. It's tempting to forget about engineering at this point... but that's obviously wrong.
Meanwhile, you can probably answer these questions 10 more ways. The team of 50 newly hired ninjas can be explained by funding. It's just what happens when VCs pour large sums into incubator startups en masse, in a tight labour market. We can go a step further: Maybe the VC stuff is derivative of monetary policies and macroeconomics... It's not untrue.
You might prefer a cultural explanation. IIRC, pg like this kind of explanation. Academic culture, FOSS, or government consulting cultures will get you to different code, stack, financial structures, etc. Hiring a LISP team will get you fundamentally different software than hiring a Java team. Much more different than legibly explainable by the differences between Java and LISP. It's technically possible to do the LISP thing in Java or vise versa. It won't happen though.
It just goes on and on, gets hairier and nastier as you go. I find that the deeper I go, the more I touch base with the aggravating starting point: the cost/efficiency of software varies by several order of magnitude: far more than reasonable.
So more than the power it takes to run it I doubt it's much of a monthly expense.
that processor does not exist
https://news.ycombinator.com/item?id=28478379
Unsure if anything has changed since
So not everything is running there
dig a news.ycombinator.com +short
209.216.230.240
Are you referring to https://hn.algolia.com/?
pretty sure Algolia runs that for free (for marketing)
Something that would have made Gopher protocol proud to coexist along in this exclusive class.
Probably could save even more money in bandwidth cost with mostly unsecured HTTP.
https://www.asrockrack.com/general/productdetail.asp?Model=X...
AMD is now firmly ahead in performance/watt, and in peak performance on most server-side benchmarks (see phoronix). Xeon superiority is a thing of the past. The only area where Intel is competitive is in AVX512 workloads.
This is how you build a 75W server that lasts 100 years and can do AI too :D, just remove the GPU for no AI: http://move.rupy.se/file/xeon_1030.png
SSDs peaked in 2011 with X-25E at 65nm and 100.000 writes per bit.
From C64 to today you have 1.000-10.000x per watt... if your Ryzen is 2x better than Intel it's irrelevant in that context.
The hard thing now is longevity, since the hardware does not improve.
It's over, time to start writing better software!
#dangdeservesbetter
could be an interesting formula in all kinds of hierarchical systems. Above some salary you are banned from the bike shedding discussion.