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

51–60 of 182 posts

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#51

Post by vineyardmike »

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…

I think the full description of “stateless, serverless functions” adds a bit of clarity. My read of this is that whatever code is running doesn’t maintain state between requests, and doesn’t touch the underlying operating system. Which seems pretty standard for highly managed environments anyways. It’s been years since I’ve written backend API code that touched the underlying system, or left objects in heap between requests.

The flexibility of knowing that any machine can instantly run the code for your API gives a lot of flexibility to rapidly scale up an API.

Nothing is “serverless” to everyone. Especially when you run the data center. But being “serverless” and even sitting above the “language runtime” gives API developers a lot of freedom to focus on business logic.

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#52

Post by Retr0id »

Simon_O_Rourke wrote: post #28
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…

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

Threads feels more like a new feature in the facebook meta-app (heh) than a new app in its own right, especially with how it has to be bound to an instagram profile.

"our new feature reached 100m users in 5 days" sounds a little less impressive (especially given meta has multiple billions of users to start with).

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#53

Post by hansmayer »

wordpad25 wrote: post #43
hansmayer wrote: post #37

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.

how is it net negative effect? they have Hundreds of millions of ACTIVE users even if it was spun off to be stand alone product without Instagram it would still be worth billions

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-negative, because even by the narrow metric of revenue and profitability, they are not even returning value to their shareholders - they turn a profitable quarter like what, every few years or so? The effects on society such as traffic congestion, real-estate market etc. are also quite visible in many major cities in the western hemisphere these days (and beyond even...). Now specifically for the Threads: as it stands right now, they are not even driving revenue at Meta, in the corpo-speak of their own CFO: “Specifically, as it pertains to monetization, we don’t expect Threads to be a meaningful driver of 2025 revenue at this time,” said CFO Susan Li on the earnings call. “We’ve been just pleased with the growth trajectory and again, are really focused on introducing features that the community finds valuable.” (https://www.cnbc.com/2024/10/31/metas-threads-app-now-has-27...). As for the wider positive effects to the society at large, feel free to point out any. As far as I recall, they launched with the promise of sort of "sanitised" contents being promoted, kind of Pinterest 2.0 if you will, beyond that I am not aware of anything relevant coming out of that platform honestly.

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#54

Post by lionkor »

> the image is not cached at CDN109 when the user requests it, CDN109 forwards the request to a nearby PoP. The PoP then forwards the request to the load balancer in a datacenter region, which retrieves the image from the storage system.

Say I want a 1MB image, wouldn't it be faster to serve me the 1MB image over a slow connection with 100ms latency, than going through multiple hops of increasing latency, with multiple round trips?

Say I request the image directly:

me -- 100ms --> datacenter

datacenter -- 100ms --> me

Say I now go through Meta's system, assuming that goes to the same Datacenter in the end, and there's no FTL tech:

me -- 10ms --> CDN

CDN -- 10ms --> PoP

PoP -- 90ms --> datacenter

datacenter -- 90ms --> PoP

PoP -- 10ms --> CDN

CDN -- 10ms --> me

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#55

Post by karparov »

lionkor wrote: post #54

> the image is not cached at CDN109 when the user requests it, CDN109 forwards the request to a nearby PoP. The PoP then forwards the request to the load balancer in a datacenter region, which retrieves the image from the storage system. Say I want a 1MB image, wouldn't it be faster to serve me the 1MB image over a slow connection with 100ms latency, than going through multiple hops of increasing latency, with multip…

[dead]

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#56

Post by huijzer »

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

I yesterday sat in a meeting where someone showed for an hour all kinds of organizational charts with acronyms and vague terms, and who could do what and who is the boss of who. The various organizations were there to help employees dealing with European privacy regulations while also publishing data open access when possible. Basically: Which parts of the org can help you to deal with the contradicting government regulations.

I honestly find high pressure work more relaxing than these kinds of meetings.

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#57

Post by spacebanana7 »

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

Imagine the compensation.

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#59

Post by vasco »

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

Having been in both setups, the frustration and demotivation I got when working in the bureaucracy was way worse than doing the rare weekend work and on-call rotations at a place where things moved fast. Many people get pumped up by doing stuff.

Re: Meta’s Hyperscale Infrastructure: Overview and Insights

#60

Post by [deleted] »

lionkor wrote: post #54

> the image is not cached at CDN109 when the user requests it, CDN109 forwards the request to a nearby PoP. The PoP then forwards the request to the load balancer in a datacenter region, which retrieves the image from the storage system. Say I want a 1MB image, wouldn't it be faster to serve me the 1MB image over a slow connection with 100ms latency, than going through multiple hops of increasing latency, with multip…

[deleted]
Post reply on HN