toggle quoted messageShow quoted text
Yes, I find this story inspiring from Benchling of moving their genome searching to Lambda and both reducing tail latency and dropping costs from thousands of dollars per month to $60:
On Mar 31, 2017, at 14:10, Alexis Richardson via cncf-toc <cncf-toc@...
Related to this, many FaaS proponents talk about the economics of only paying for use (function calls). But this economic model is not limited to the serverless app frameworks eg as listed below by Brian. Many container orchestrators could feasibly provide fine grained billing.
On Fri, 31 Mar 2017, 19:00 Brian Grant via cncf-toc, <cncf-toc@...
I don't find the term "serverless" to be useful. It's too broad, and could encompass purely client-based computations and web hosting as well as FaaS.
I see Functions as a Service as an instance of Application Framework as a Service. Data-processing frameworks that support dynamic code loading and managed execution would also qualify. The services that we have today that support dynamically pushed code are natural evolutions of servlet engines, application frameworks, data-processing frameworks, and plugin-centric systems that have been developed over the past couple decades.
Even Functions as a Service specially addresses multiple overlapping areas:
- Event-driven automation. People are using FaaS for simple automation tasks. For these scenarios, the most critical determinant of utility is relevant event sources. In the FaaS space, Openwhisk is most obviously aimed at this use case. Automation systems such as StackStorm are fairly similar. The main limitation of a system like Stackstorm is that the actions are pre-packaged plugins rather than dynamically provided functions. IFTTT and Microsoft Flow address points in this spectrum, as well, and configurable actuators capable of talking to any OpenAPI-compatible API are one reasonable method of linking triggers and actions.
- Extension implementations. Something to receive extension web hooks from some other service without the need to operate a full-blown application deployment. The main difference with the event-driven automation use case is that some other system defines the invocation conditions.
- Data-driven processing and simple ETL workflows. Not unlike Bigtable coprocessors.
- Rapid application development and deployment, especially for mobile apps, home assistants, and IoT. It's similar to website hosting, but for application frameworks / servlet engines. As with web app mashups, this model is facilitated by the availability of APIs for other services to do much of the heavy lifting. The line between this scenario and a full-blown PaaS is not about features, agility, the deployment model, or execution artifacts (most PaaSes support pushing code, and people load and run executable binaries on FaaS), but about who operates the deployed application servers.
Container-based technologies are still improving and I think you'll find that container-centric infrastructure will eventually provide most of the core infrastructure capabilities required by FaaS.
Is FaaS "cloud native"? Yes.
Does FaaS make sense in local development, on prem, hybrid and multi-cloud scenarios? Yes, for all the same reasons that Kubernetes does.
cncf-toc mailing list