By using FastCGI which works by creating long-running process that will receive data and then execute provided scripts. Exactly what serverless is trying to avoid.
Because it has it’s use cases - one-shot jobs. For example it is good idea to use FaaS to generate miniatures of uploaded images or to translate data from one format to another, but in general case, FaaS isn’t replacement for “web services’ backends”, it is supporting them in tasks that aren’t their main concern.
I think you both are kind of right and kind of wrong. Current “serverless” implementations are very much like FastCGI. At least Amazon Lambda starts a VM for given function and keeps it on hand, re-using it for the same function. Note the PDF of the AWS Lambda security overview I posted above. It’s the same thing as FastCGI just starts a bunch of VMs: one or more per function.
A nightmare that the BEAM maintainers specifically call out as not happening:
We will not accept patches that add mechanisms that allows a node to restrict what other connected nodes can do, for the following reasons:
“Almost secure” is not any better than “definitely not secure”. You still cannot allow untrusted nodes to connect. (To reach the level of complete security is very hard for a protocol that was not designed for that in the beginning.)
We don’t want code bloat and code that makes the Erlang distribution slower even for applications that don’t use the new features.
If you still want to improve the security, please write an EEP first. It would probably be more fruitful to design an entire new protocol (independent of the current Erlang distribution), designed with security in mind from the ground up.
I think that’s not even all that would be needed. This is about node-to-node security. Currently compromising one node in cluster means compromising all nodes. But for replacing OS-level sandboxing with BEAM one would have to have isolation between processes on the same node. That is not going to happen either.
The only reason the paying customers are even concerned with FastCGI is because of perceived UI responsiveness - they really don’t care about technical details whether processes are recreated or recycled.
Because it has it’s use cases - one-shot jobs.
Those are just the toy examples to get people to bite.
FaaS is only a stepping stone towards serverless architecture where the client becomes the orchestrator of transaction scripts living on servers all over the web. The next step is edge computing to offload client workloads to somewhere closer than the data server.
Since cowboy 2.0 each request gets a separate process. In cowboy 1.0 it used to be a process per connection. But I don’t remember genservers ever being used there, all processes were started via :proc_lib to avoid genserver’s overhead.
Repository search results · GitHub shows genserver is only used for caching the date headers.
I haven’t listened to the interview but the way you phrased the question got me thinking.
It is entirely possible that there is a disconnect in terms of perspective. When I think of serverless architecture I get my head immediately into designing/building it.
I see serverless as a way to delegate the responsibility of ops to the provider and paying for the privilege. But ultimately I’m still thinking of building the whole damn thing.
But from a business perspective the best code is the code you don’t have to write - because there is nothing for you to maintain.
Dave may be talking about a business model where customers don’t get to write their own cloud functions but instead they rent ready made cloud functions/capabilities/components.
For example, we tend to look at payment platforms as an API to a service - which they are - but we also need to acknowledge that there is an awful lot of code that we benefit from which we don’t have to write.
In that kind of world “capability (API) providers” could base their platforms fairly efficiently on the BEAM/OTP with plenty of optimization opportunities - while their paying customers simply build the browser or native clients to consume these capabilities, aggregating them with capabilities from other providers into their own unique user facing service.
It’s surprisingly, that nobody mentioned the real benefit of serverless here. IMHO its deployment. you just deploy a function and it maps to an endpoint. Therefore the BEAM could actually dominate, by starting process with a bit of business logic in it, hold state, emit events, and stop again. So I think it could grow into somekind of Platform for Modular Applications. Just provide a simple declarative way to deploy Modules into a running BEAM cluster, and its even better then what we know as Serverless today.
This is what I think would make sense
I’ve been working on library that utilizes the AWS Step Function spec, States Language for orchestrating multiple Lambda functions.
Our Elixir interpeter compiles to a gen_statem process. In the AWS version your Resource is the ARN (Amazon Resource Name) of your lambda function. In the Elixir interpeter a Resource is just handled by the handle_resource callback of your process. This of course can be an RPC type call to other nodes, or anything really.
We’re actually using it to orchestrate microservices, using a GUI editor to create the state machines.
Just thought I’d add this to the conversation as it is relevant as well as interesting:
CloudI (Erlang)
https://github.com/CloudI/CloudI
What is CloudI?
(short answer) “A distributed application server that provides efficient messaging for many programming languages within a single service abstraction that is both scalable and fault-tolerant.”
(shorter answer) “A rock-solid transaction processing system for flexible software development.”
(shortest answer) “A Cloud at the lowest level.”
The v1.0.0 release of CloudI was back on Dec 21, 2014. Seems like it may have been somewhat ahead of it’s time. 
