Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Meta’s Hyperscale Infrastructure: Overview and Insights

cacm.acm.org

Post reply on HN
Print view View original

141–150 of 182 posts

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#141

Post by esafak »

stravant wrote: post #136
pavlov wrote: post #125

Earlier quoted context omitted.

Threads has 320 million monthly active users and 100 million daily. It’s certainly not a flop. It’s almost as big as X globally. There’s a tremendous locality bias around Meta’s products. Social media use is very localized by geography and age. So if all your friends stopped using Facebook ten years ago, you assume that’s probably true everywhere, while in fact they’ve added several billion users on FB since then.

It seems like a flop not in user count but in that I'm not seeing it originate any valuable content. I've seen several interesting posts from Bluesky referenced elsewhere already, but literally nothing from Threads despite it having had more users for longer.

How would you know if you are not present in the circles that use the product? Maybe it's big in Japan.

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#142

Post by kridsdale1 »

hansmayer wrote: post #119
motorest wrote: post #87

Earlier quoted context omitted.

If you're talking about this post: https://news.ycombinator.com/item?id=43010781 You wrote a wall of text saying and refuting absolutely nothing. The only remotely tangible argument you made was the blurb on “Specifically, as it pertains to monetization, we don’t expect Threads to be a meaningful driver of 2025 revenue at this time,”. Considering Meta reports revenue around $40B and Threads, considering the EU snag,…

Sure mate, I am definitely the one with an axe to grind here ;) Now prove me stupid and show me and the HN readership how is a product which even it's own management sees as unprofitable for the next three-four quarters, producing any benefits at least to it's shareholders, not even talking about the society. Maybe lean into the argument with a pinch of how the latest Meta "free speech" policies augment it's positive…

Let us know how important a business is WhatsApp. Which has made about zero revenue for Meta in 15 years and yet is utterly dominant globally.

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#143

Post by [deleted] »

hansmayer wrote: post #121
isaacremuant wrote: post #112

Earlier quoted context omitted.

[flagged]

Not to burst your weird leftist-rightist libertarian bubble, but vaccine passports are actually a fairly normal thing in most of the world mate. You know, it's just about documenting what vaccinations you were receiving throughout your lifetime. Go outside and touch the grass, you sound very angry.

[deleted]

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#144

Post by kridsdale1 »

eclark wrote: post #138

While I was at FB (it wasn't Meta then), I saw what a superpower the infrastructure is there. Product engineers build things of a scale in days. While I was there, I got to be tech lead for several different teams (2x distributed dbs, 1x Dev Efficiency, 1x Ads), some of which are called out by name here. Shout out to the HBase and ZippyDB teams! This is the first public acknowledgment that ZippyDB was converged upon.…

Good luck to you. Maybe you’ll be the next StatSig.

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#145

Post by kridsdale1 »

philg_jr wrote: post #107

Amazing. All of this truly wild, impressive technology and some of the absolute best engineers in the world, just to shove more ads in people's eyeballs. Sigh.

Take it up with capitalism and with DARPA. If we could earn $700k doing cool science shit in white shirts and black ties for Uncle Sam like our grandfathers maybe we would.

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#146

Post by kridsdale1 »

ThinkBeat wrote: post #78

Quickly developed serverless functions combined with continuous deployment, and anyone can make edits in the entire codebase sounds like a dystopian nightmare. The amount of logging that is required to debug and find bugs is extreme. Using Erlang to write serverless functions seems like avoiding all the huge benefits BEAM can offer. >Additionally, product engineers predominantly write code in stateless, serverless fu…

Yes it’s dangerous. That’s why the hiring bar is very high, and everyone spends their first 8 weeks in training bootcamp before being let loose in their real project team.

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#147

Post by kridsdale1 »

HolyLampshade wrote: post #82
ThinkBeat wrote: post #78

Quickly developed serverless functions combined with continuous deployment, and anyone can make edits in the entire codebase sounds like a dystopian nightmare. The amount of logging that is required to debug and find bugs is extreme. Using Erlang to write serverless functions seems like avoiding all the huge benefits BEAM can offer. >Additionally, product engineers predominantly write code in stateless, serverless fu…

> The amount of logging that is required to debug and find bugs is extreme. Ten or so years ago I remember going to a larger technical recruiting pitch at Facebook where they discussed their logging complex (I have only a vague recollection of the details). Honestly it was one of the most beefy implementations of system/application logging I remember having seen at the time.

It powers the world’s best experimentation platform too. Which is their business superpower. Competitors can spend a year thinking about what to do. FB has already tried and measured all options and pivots to the optimal.

I have been very disappointed since moving from FB to Google at how much worse the data and measurement platform is here.

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#148

Post by kridsdale1 »

nk8620 wrote: post #76

> Moreover, for non-AI compute workloads, we offer only a single server type, equipped with one CPU and the same amount of DRAM (previously 64GB, now 256GB). I'm reading something like this for the first time. Is this common across industry or only typical to Meta? In contrast, we use multiple instances for sub-components of our ML training pipeline.

This wasn’t true for the server side compiler jobs I was doing. Those were multithreaded af.

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#149

Post by kridsdale1 »

mathverse wrote: post #34
arjvik wrote: post #10

Earlier quoted context omitted.

GCP got this reputation because it’s a second class citizen within Google. Google’s own internal infra (Borg, Blaze) is top-notch. If Meta can pull off the public cloud correctly, I’d trust them greatly - they’ve shown significant engineering and product competence till now, even if they could use some more consistent and stable UI.

Dont all new projects go to gcp within google?

Depends on what you mean by new. None of the new features for the mature product I work on have touched it.

To the side I have had GCP work but it’s been isolated and as if I were moonlighting.

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#150

Post by kridsdale1 »

ForHackernews wrote: post #46
ribadeo wrote: post #32

At least half their gak is due to them NOT moving quickly and NOT wanting to break things. IIRC, graphql is a means of papering over a bunch of legacy APIs. They removed foreign keys from mysql using it as a column store db, a vestige of the original LAMP stack still on PHP. I don't think Meta infrastructural choices are applicable to most folk. What does serverless land your average dev? A high AWS bill. Elastic man…

> Facebook creates tech to mitigate the pathologies their past continuously present. Remember when they hacked a running Android Dalvik machine because their organizational constraints were such that they could never remove code or delete unused classes? https://archive.is/nIPlg https://engineering.fb.com/2013/03/04/android/under-the-hood... Facebook seems like a place where they do amazing engineering to temporarily…

Basically yeah. You should see the FB iOS code base. Yikes. And I have seen Apple code bases that literally go back to the 80s.
Post reply on HN