> Furthermore, XFaaS explicitly does not handle functions and the path of a user-interaction
The wording of this is a little strange, but does this really mean that XFaaS is not used to serve end-user traffic at all?
The general approach here is interesting. I've always thought that there are two potential benefits for Function-based hosting ("Serverless") – low cost of components via scale-to-zero infrastructure (good for rare events, or highly variable traffic), and developer experience (coding against an infra framework rather than build-your-own infra). I'd have expected the former to be much less of an issue at scale, to the point where it's not the leading benefit, so I expected to hear more about the dev productivity side, but instead this article focuses significantly on the performance and cost side of things.
> but does this really mean that XFaaS is not used to serve end-user traffic at all?
When I worked at a company with a similar-ish setup, we were told that if you could do it in less than a minute and the user has to wait on it, do it in the request, don't send it to a job. This was because it was "cheaper" to keep a thread running vs. spinning up the resources to do a job. When I say cheaper, I mean in dev-time, user experience, and actual resources.
1) on the front-end, the dev doesn't have to "refresh" or "poll" an endpoint to get the status.
2) user experience is better. many people naively check "every 30s" or something ... well, what happens if services are degraded and it takes more than 30s to respond to your status check? Now, after a few minutes, you have dozens of pending requests for the exact same resource.
3) we didn't have a fancy SLO priority queue, just a regular one, so sometimes, you could have your job stuck behind a ton of jobs that are a higher priority than you, causing what was only 30s in your tests to now take 2 hours with the user polling your status endpoint and randomly refreshing, then eventually contacting support asking why it isn't working.
I think they are trying to hammer home that its not a realtime system. Anything you pass into will be executed at some point in the future. so if you want something synchronous, its not the tool to use.
Author of the paper summary here - my understanding is that XFaaS doesn't run functions that are run in response to user input (e.g. XFaaS does not execute code that fetches and returns data because a user clicked on a button).
The wording of this is a little strange, but does this really mean that XFaaS is not used to serve end-user traffic at all?
The general approach here is interesting. I've always thought that there are two potential benefits for Function-based hosting ("Serverless") – low cost of components via scale-to-zero infrastructure (good for rare events, or highly variable traffic), and developer experience (coding against an infra framework rather than build-your-own infra). I'd have expected the former to be much less of an issue at scale, to the point where it's not the leading benefit, so I expected to hear more about the dev productivity side, but instead this article focuses significantly on the performance and cost side of things.