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

81–90 of 182 posts

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#81

Post by hansmayer »

isaacremuant wrote: post #71
hansmayer wrote: post #53

Earlier quoted context omitted.

DAU is a very one-dimensional and misleading KPI, one that gave us ever-growing, VC-backed unprofitable companies. The Threads is definitely net-negative in the sense of wider impact and not just single-dimensional KPIs. Take as example Uber and AirBnB. Both have had millions of active users and one could argue their service is even useful to a lot of people. It's still quite easy to argue that they are are net-negat…

[flagged]

Please read more carefully and don't shove your own words down other people's throats, it's rude and un-called for. What zealotry? The only politically-sided arguments in this thread are coming from you. By the way, if you took a few more seconds to read a bit more carefully, you would have noticed I never said they did not provide any value - only that the net negative seems to be outweighing the benefits to the society as a whole, and this is based on hard data, not ideology, mate. This is to make comparison to Threads, which is, unlike these two, not even providing a real-life service to justify it's existence. Plus, please learn: revenue != profits. I won't go down the rabbit hole of discussing the business models of Uber and Airbnb, you obviously haven't understood who carries the actual operating costs of those "businesses" and maybe in your world these are great services, as they come with an implicit ego-boost for all the Karens of this world?

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#82

Post by HolyLampshade »

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.

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#83

Post by HolyLampshade »

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.

At least in my experience in a somewhat bespoke industry on the non-cloud side, things have been moving in that direction due to most of the reasons they identify (it also ties nicely into the global "Datacenter as a Computer" concept they hit on).

People in my industry have a tendency to over-optimize (technical folks love nothing more than to tinker), and in doing so create very unique deployments per group that require a significant amount of infra and operational support, and drastically slow down the rate of progress/change (not to mention the cost). When you peel back all the requirements it turns out we really only need three unique deployment options. Makes it all significantly less cumbersome.

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#84

Post by titzer »

WJW wrote: post #68
Simon_O_Rourke wrote: post #28

Earlier quoted context omitted.

They might have launched it quickly, but nobody (relatively speaking) gave a tinkers damn about the end product. All form and no function.

Form and no function is the essence of social media apps though, so they nailed that. 300 million monthly and 100m daily users is also pretty decent, so I don't think "nobody" cares. For comparison, that's approximately the same number of MAU as twitter.

Zero of whom pay for the product. They are the product.

What this leaves out is that the real customers, advertisers, already have a fully-functional hyperscale system creeping on users and pushing ads in their face. It's akin to crowing about how fast you can put up new billboard ads when the billboards are already built--someone else has already put in the power/network lines, poles, screens, routing, etc, and you just hooked up your existing ad feeds to it. Facebook doesn't give two shits if the billboards were in the middle of nowhere, as long as they can charge their advertisers some $$, they'd deliver seizure-inducing hallucinogenic drugs right into users' veins.

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#85

Post by speed_spread »

vasco wrote: post #4

> Moreover, once it [Threads] was developed, the infrastructure teams were given only two day’s notice to prepare for its production launch. Most large organizations would take longer than two days just to draft a project plan involving dozens of interdependent teams, let alone execute it. At Meta, however, we quickly established war rooms across distributed sites, bringing together both infrastructure and product te…

> kept this ability to ship fast

The secret of keeping deployment velocity high is having nothing important to lose. Facebook can drop or repeat a few posts and pics here and there and nobody will bother really. Anyway, who are they gonna call?

The moment you start dealing with transacted data that requires immediate consistency and guaranteed persistence then yeah, managers get nervous, lawyers get involved and there's no way for guerilla ops to hold up.

Nobody's paying for Meta's stuff except advertisers and something tells me that _their_ part of the pipeline is handled with _much_ greater care than the "consumer"-facing apps.

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#86

Post by WJW »

titzer wrote: post #84
WJW wrote: post #68

Earlier quoted context omitted.

Form and no function is the essence of social media apps though, so they nailed that. 300 million monthly and 100m daily users is also pretty decent, so I don't think "nobody" cares. For comparison, that's approximately the same number of MAU as twitter.

Zero of whom pay for the product. They are the product. What this leaves out is that the real customers, advertisers, already have a fully-functional hyperscale system creeping on users and pushing ads in their face. It's akin to crowing about how fast you can put up new billboard ads when the billboards are already built--someone else has already put in the power/network lines, poles, screens, routing, etc, and you…

If you can put up new billboard ads ten times as fast as your competitors, that's still a competitive advantage. Whether you like Meta or not, two days to provide sufficient infra for a new service with 100m users is a technical achievement that not many organizations on the planet could match.

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#87

Post by motorest »

hansmayer wrote: post #80
motorest wrote: post #72

Earlier quoted context omitted.

> Precisely, for all the talk of efficiency last few years, how do we even begin to measure the total waste of effort and energy of so many smart people that this was? All that effort and stress for effectively nothing, or perhaps even net negative effect. This comment is perplexing. Reportedly Threads has 130 million monthly active users (and growing) vs. 550 million accessing X (and shrinking). This alone already p…

See further below please, I wrote just about this kind of tunnel-vision focus on DAU/MAU vs. a more holistic view ;)

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, was basically launched last year, this is far from being the failure you are trying to spin it.

But if you had any point worth making, and you didn't had an axe to grind, you wouldn't grasped at straws such as the "As for the wider positive effects to the society at large, feel free to point out any."

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#88

Post by chasd00 »

pinoy420 wrote: post #44
vasco wrote: post #4

> Moreover, once it [Threads] was developed, the infrastructure teams were given only two day’s notice to prepare for its production launch. Most large organizations would take longer than two days just to draft a project plan involving dozens of interdependent teams, let alone execute it. At Meta, however, we quickly established war rooms across distributed sites, bringing together both infrastructure and product te…

Sounds like a horrific place to work. Imagine the pressure

You get addicted to the adrenaline. If you’re with really good people that kind of pressure is actually fun. Sort of like how a championship sports game is fun.

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#89

Post by falcor84 »

whstl wrote: post #33
yuliyp wrote: post #2

I find it interesting how they describe the PHP web front end as a "serverless" or "function as a service" architecture. I guess it's a matter of perspective. It's a service that has a monolithic codebase with lots of endpoints deployed to it. I guess from the perspective of the maintainer of one of those endpoints it's "serverless" but that abstraction (like all abstractions) has leaks: the teams responsible for the…

“Serverless” is not synonymous with Lambda, it’s just a computing model. Lots of companies are hosting old monoliths on Amazon Fargate, for example.

As I see it, it's just an abuse of terminology. By referring to Fargate as Serverless which previously referred to FaaS, they (apparently AWS's marketing team) have seemingly removed the distinction between FaaS and PaaS

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#90

Post by ribadeo »

sofixa wrote: post #62
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…

> Did you know that you can use YAML and provision actual cloud provider resources with boring tech? Welcome to Ansible Anyone using Ansible for cloud infrastructure management is not to be taken seriously. It's among the worst tools for the job - not (always) idempotent, no state tracking, slow, very limited in the resources it can manage, very lacking templating, fun stuff like "state: absent", running, and then ha…

Way to lose the forest for the trees.

I was making a point about provisioning VPSes instead of trying to wrangle postgresql restores inside kubectl or equivalent, of how your cloud provider is already provisioning a single physical server via a hypervisor.

I was making a point that facecrook overengineering is about them being boxed into corners, about how very little of big techs solutions translate to real world usage in the web industry i am very much taken seriously in for over 30 years.

You read 'ansible recommended', which I could also argue with you about, but I shan't.

Post reply on HN