3 ms·

> 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 f

> 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 in system x has updated y, this triggers a function to update paths to use the latest version)

jacobr1 3y ago
> 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.
asdfman123 3y ago
> 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.
- KaiserPro 3y ago
  TLDR: 100% agree, discipline is still required! I worked at a place that went full lambda for a website (this was possibly 2016) They started out with huge velocity, things were much quicker to build and test. Serverless (the framework) was a joy to deploy with, compared to what they were used to. They had complete control over their architecture for the first time. However they then slammed into fixing all the innovation tokens they deployed (New DB, New message routing, New hosting arch, New auth methods) and hit the productivity wall.

jacobr1 3y ago

> 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.

asdfman123 3y ago

> 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.

KaiserPro 3y ago
TLDR: 100% agree, discipline is still required! I worked at a place that went full lambda for a website (this was possibly 2016) They started out with huge velocity, things were much quicker to build and test. Serverless (the framework) was a joy to deploy with, compared to what they were used to. They had complete control over their architecture for the first time. However they then slammed into fixing all the innovation tokens they deployed (New DB, New message routing, New hosting arch, New auth methods) and hit the productivity wall.