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

XFaaS: Hyperscale and Low Cost Serverless Functions at Meta

micahlerner.com

Post reply on HN
Print view View original

61–70 of 79 posts

Re: XFaaS: Hyperscale and Low Cost Serverless Functions at Meta

#61

Post by xylophile »

oxfordmale wrote: post #57
xylophile wrote: post #36

Earlier quoted context omitted.

It is literally "worth it" for companies much smaller than Meta due to the reduced infra management costs plus increased hardware utilization. A few hundred unique VMs is a boatload of work (even if you distribute it down to the dev teams), and most of those VMs will be sitting idle most of the time, just burning electricity to keep the RAM on.

But you would still need a boatload of a hundred unique VMS to run your serverless functions, right? If you have a big enough SRE team to manage your serverless stack, economy of scale means that development teams utilising these can reduce their infra management costs. It is about the ratio of engineers utilising the stack compared to those that need to maintain it.

> But you would still need a boatload of a hundred unique VMS

No, you would have a boatload of generic worker VMs that could all be spun up as needed (autoscaled) from a common base image and deleted without any need to preserve state. Effectively, you're managing one VM image, which can be rolled out across your entire fleet very quickly and with zero downtime / disruption. This is even less disruption than with k8s because FAAS design is fundamentally short-lived processes, resulting in more automation (less work) for your SRE / VM team.

Re: XFaaS: Hyperscale and Low Cost Serverless Functions at Meta

#62

Post by xylophile »

Rodeoclash wrote: post #5

Any insight to what kinds of work is being run in the functions? I run a lot of jobs in background queues but I'm wondering if I'm missing out on some new paradigm.

It's fundamentally the same as a job queue, but the difference is that the people writing the job are not creating a running OS process. You literally just write a function, and it gets compiled into a process owned and executed by the job system.

Why would you want that? Well, who really wants to think about the OS, or how to get their data into main()? You just want to write business logic, and FaaS lets your developers focus on that. It's a small development process optimization, but a significant one at scale if you have enough developers / unique jobs being created. And it lets platform engineers focus on the best way to shovel data into main() in your particular environment.

Re: XFaaS: Hyperscale and Low Cost Serverless Functions at Meta

#63

Post by jacobr1 »

KaiserPro wrote: post #47
freedomben wrote: post #3

It's interesting to see the heavily growing demand graph. Is that because people want to adopt it, or is it being mandated or encouraged as "best practice" etc? I'm not implying that true organic demand wouldn't exist because it definitely might, but I have seen in practice where leadership encourages or even mandates usage of FaaS, so the numbers go up even though on a neutral field people wouldn't necessarily choos…

> Is that because people want to adopt it, or is it being mandated or encouraged as "best practice" Its because its the simplest, fastest way to get compute for non realtime bits of code. Its much less hard to deploy stuff to, and its really simple to trigger it from other services. A lot of things in FB are communicated by RPC, so its not really "web" fucntions that run on there, its more generic ETL type stuff. (as…

> as in system x has updated y, this triggers a function to update paths to use the latest version

This is the sweet spot. Eventing. Any kind of queue based workload, especially one with variable load is a potential candidate for FaaS kind of architecture. The alternative is a worker-pool specific the workload. FaaS just moves up the abstraction on how processes are managed to a global worker-pool.

Re: XFaaS: Hyperscale and Low Cost Serverless Functions at Meta

#64

Post by zokier »

Shrezzing wrote: post #58
zokier wrote: post #45

Earlier quoted context omitted.

> A server idling on Function A can't be called for Function B why not?

The server in this context is a "warmed" Function VM. The first time a VM instantiates, it goes through all of the setup required to run a function. That includes generic reusable stuff like Operating System setup, but also Function-specific things like JIT compilation of the Function software, library loading, language loading, all of which are specific to the Function being executed. The Function VM is hyper-optomi…

> There's compute-time costs in changing its role from Function A to Function B.

Why do you need to change existing VM in any way? Having an idle VM for function A should not prevent the host from instantiating new VMs for function B. I still do not see where is the cost of an idle VM.

> servers (or more accurately software VMs inside of physical servers), are locked into a specific function

I think this needs to be more specific; what resources are exactly locked to a VM? Are they pinning VMs to specific CPUs or something that prevents the host from scheduling other tasks there? If so, why?

Also, you sound very confident in your answers, do you have some additional sources you could point me to, or are you also basing all this on this one paper?

Re: XFaaS: Hyperscale and Low Cost Serverless Functions at Meta

#65

Post by tyingq »

freedomben wrote: post #3

It's interesting to see the heavily growing demand graph. Is that because people want to adopt it, or is it being mandated or encouraged as "best practice" etc? I'm not implying that true organic demand wouldn't exist because it definitely might, but I have seen in practice where leadership encourages or even mandates usage of FaaS, so the numbers go up even though on a neutral field people wouldn't necessarily choos…

It could also be that it's the "easy path" to get something in production with either lighter governance or faster turnaround, etc.

Re: XFaaS: Hyperscale and Low Cost Serverless Functions at Meta

#66

Post by p_l »

Capricorn2481 wrote: post #59
p_l wrote: post #25

Earlier quoted context omitted.

Isn't FaaS just wrapping around functions and their deployment?

Yes, but I'm just confused because saying "Why isn't there an open source FaaS for on prem that shares hardware" makes no sense. At that point, you're just talking about regular coding with functions. Unless there's something I'm missing.

There's a bunch of open source software that can do it for you, but it's very much "assemble this pile of blocks"

Re: XFaaS: Hyperscale and Low Cost Serverless Functions at Meta

#67

Post by oxfordmale »

xylophile wrote: post #61
oxfordmale wrote: post #57

Earlier quoted context omitted.

But you would still need a boatload of a hundred unique VMS to run your serverless functions, right? If you have a big enough SRE team to manage your serverless stack, economy of scale means that development teams utilising these can reduce their infra management costs. It is about the ratio of engineers utilising the stack compared to those that need to maintain it.

> But you would still need a boatload of a hundred unique VMS No, you would have a boatload of generic worker VMs that could all be spun up as needed (autoscaled) from a common base image and deleted without any need to preserve state. Effectively, you're managing one VM image, which can be rolled out across your entire fleet very quickly and with zero downtime / disruption. This is even less disruption than with k8s…

As far as I am aware there is no easy to set up open source FAAS framework. At least with Kubernetes there are a million and one tutorials, and there is a large support community.

Re: XFaaS: Hyperscale and Low Cost Serverless Functions at Meta

#68

Post by Amezarak »

zokier wrote: post #64
Shrezzing wrote: post #58

Earlier quoted context omitted.

The server in this context is a "warmed" Function VM. The first time a VM instantiates, it goes through all of the setup required to run a function. That includes generic reusable stuff like Operating System setup, but also Function-specific things like JIT compilation of the Function software, library loading, language loading, all of which are specific to the Function being executed. The Function VM is hyper-optomi…

> There's compute-time costs in changing its role from Function A to Function B. Why do you need to change existing VM in any way? Having an idle VM for function A should not prevent the host from instantiating new VMs for function B. I still do not see where is the cost of an idle VM. > servers (or more accurately software VMs inside of physical servers), are locked into a specific function I think this needs to be…

> Why do you need to change existing VM in any way? Having an idle VM for function A should not prevent the host from instantiating new VMs for function B. I still do not see where is the cost of an idle VM.

Because the host can only run so many VMs. What's being described is host resource exhaustion from running idle VMs.

Re: XFaaS: Hyperscale and Low Cost Serverless Functions at Meta

#69

Post by asdfman123 »

KaiserPro wrote: post #47
freedomben wrote: post #3

It's interesting to see the heavily growing demand graph. Is that because people want to adopt it, or is it being mandated or encouraged as "best practice" etc? I'm not implying that true organic demand wouldn't exist because it definitely might, but I have seen in practice where leadership encourages or even mandates usage of FaaS, so the numbers go up even though on a neutral field people wouldn't necessarily choos…

> Is that because people want to adopt it, or is it being mandated or encouraged as "best practice" Its because its the simplest, fastest way to get compute for non realtime bits of code. Its much less hard to deploy stuff to, and its really simple to trigger it from other services. A lot of things in FB are communicated by RPC, so its not really "web" fucntions that run on there, its more generic ETL type stuff. (as…

> Its because its the simplest, fastest way to get compute for non realtime bits of code. Its much less hard to deploy stuff to, and its really simple to trigger it from other services.

That's all true, but IMO the problem with functions is that they are initially so simple. But deploying code isn't actually that hard of a problem. The hard part is growing and maintaining the codebase over time.

I'm not saying there ISN'T a use case for them, but there should be a very good reason why you want to split them off of other services.

Re: XFaaS: Hyperscale and Low Cost Serverless Functions at Meta

#70

Post by asdfman123 »

chrishare wrote: post #22

Intuitively, the popularisation of FaaS feels inevitable as lower level technical challenges get solved and give way to abstractions like this. Who knows though what our stack will look like in 20 years.

But what is left to "solve" here? Functions already work pretty well for what they do.

But any abstraction runs the risk of revealing itself as a leaky abstraction, not worth the overhead. That's been my experience with functions.

Post reply on HN