4 ms·

> But does anyone work on backends that heavily utilize a serverless platform? As far as I know, that scenario is not in the decision tree for when to go with

by foofie 3y ago

> But does anyone work on backends that heavily utilize a serverless platform? As far as I know, that scenario is not in the decision tree for when to go with function-as-a-service offerings. FaaS is for things like glue code for event handlers, low-traffic services like API Gateway/NLB calling Lambdas, and expensive tasks that can be offloaded from a worker thread to a Lambda. When traffic going into a FaaS-based service starts to go up, the cost of running Lambdas stops being competitive and you're better off just having a dedicated service handle the work. Nevertheless, the main selling point of FaaS is not performance, throughput, or even developer convenience. The main selling point is hardware utilization. If your dev teams deploy FaaS stuff instead of dedicated services, the company doesn't need to provision anything to get them to run. The functions are just deployed in the sea of FaaS things they have been running, and they can live with high hardware utilization just fine.

frfl 3y ago
I ask because it's relevant to me, but not in my control. And still early stages and haven't hit that "When traffic going into a FaaS-basdd service starts to go up, the cost of running Lambdas stops being competitive" stage yet -- if what you're describing will be applicable and true in my situation. Sorry I can't go into specifics as it wouldn't be wise for me to discuss work stuff in more detail. So that's good to know. Do you have any references, in terms of further reading material, for the cross over point for when it's stops being competitive? I highly doubt $cloud_provider is going to give you such a analysis for obvious financial reasons.
- foofie 3y ago
  > Do you have any references, in terms of further reading material, for the cross over point for when it's stops being competitive? I'm afraid I don't. The most objective cutoff point I can come up with is based purely on cost. Meaning, cloud providers like AWS might offer a free tier for API Gateway and Lambdas which makes them really competitive vs running a container or launching a VM when traffic is low. However, once your traffic starts to go beyond the free tier (IIRC per month it's 1million requests for API gateway and 400,000 GB/s for lambdas) then operational costs starts to overtake the cost of running a traditional service. How many requests your service handles on all endpoints and how much computational budget each lambda spends is a trait of your own service, and reflects low-level decision such as how you designed your API and what runtime did you chose for your lambdas. Basically this boils down to the FaaS solution eventually leading the cloud provider to charge you per each request, while your traditional service running either in a container or on a VM having a fixed cost. After some math you'll arrive at s traffic volume that can represent the tipping point between FaaS and traditional services. Personally, my subjective cutoff point is when FaaS costs about 30% of traditional setvices. Once your FaaS cost starts to grow, you're tempted to micro-optimize your API and your service to try to keep it's running cost justifiably low. That's when you're starting to be tempted to put together a sucky service as a cost tradeoff. When that time comes, it's better to bite the bullet and just migrate away from FaaS.

by foofie 3y ago

frfl 3y ago

I ask because it's relevant to me, but not in my control. And still early stages and haven't hit that "When traffic going into a FaaS-basdd service starts to go up, the cost of running Lambdas stops being competitive" stage yet -- if what you're describing will be applicable and true in my situation. Sorry I can't go into specifics as it wouldn't be wise for me to discuss work stuff in more detail. So that's good to know. Do you have any references, in terms of further reading material, for the cross over point for when it's stops being competitive? I highly doubt $cloud_provider is going to give you such a analysis for obvious financial reasons.

foofie 3y ago
> Do you have any references, in terms of further reading material, for the cross over point for when it's stops being competitive? I'm afraid I don't. The most objective cutoff point I can come up with is based purely on cost. Meaning, cloud providers like AWS might offer a free tier for API Gateway and Lambdas which makes them really competitive vs running a container or launching a VM when traffic is low. However, once your traffic starts to go beyond the free tier (IIRC per month it's 1million requests for API gateway and 400,000 GB/s for lambdas) then operational costs starts to overtake the cost of running a traditional service. How many requests your service handles on all endpoints and how much computational budget each lambda spends is a trait of your own service, and reflects low-level decision such as how you designed your API and what runtime did you chose for your lambdas. Basically this boils down to the FaaS solution eventually leading the cloud provider to charge you per each request, while your traditional service running either in a container or on a VM having a fixed cost. After some math you'll arrive at s traffic volume that can represent the tipping point between FaaS and traditional services. Personally, my subjective cutoff point is when FaaS costs about 30% of traditional setvices. Once your FaaS cost starts to grow, you're tempted to micro-optimize your API and your service to try to keep it's running cost justifiably low. That's when you're starting to be tempted to put together a sucky service as a cost tradeoff. When that time comes, it's better to bite the bullet and just migrate away from FaaS.