Hi Qian,

After looking into the open source options for widely-used serverless 
frameworks, I noted these five:
* Oracle-backed Fn: https://fnproject.io/
* Kubeless: https://kubeless.io/
* Fission: https://fission.io/
* OpenFaaS: https://www.openfaas.com/
* Apache OpenWhisk: https://openwhisk.apache.org/

Briefly looking at the OpenWhisk documentation, it says that Mesos is already 
supported alongside Kubernetes and Docker Swarm. I haven’t studied OpenWhisk so 
I don’t know if it works different than the mostly Kubernetes-based projects in 
this space.

The way most of these ‘function as a service’ frameworks work is that you 
provide the function in one of the supported languages, and the system then 
packages your function with an appropriate runtime into a container. From 
there, the serverless runtime waits for a request to come in on the service 
endpoint. For each request, the serverless runtime launches one copy of the 
containerized function. Functions are supposed to run for extremely short 
durations, and the serverless runtime meters the running time. You’re billed by 
the second or fraction of a second for function execution time. For one of 
these services you are running on your own infrastructure, then obviously there 
isn’t a billing component like exists with the cloud providers.

None of the major cloud providers have a good solution for using serverless 
functions that require persistent state. Each function invocation terminates 
when it’s finished, so nothing persists. Any state needs to be looked up or 
persisted to external storage. So far, I haven’t seen any good solution 
proposed for how to do this better. When you’re being charged by the second, 
you don’t really want your functions to have to query and fetch state over the 
network before being able to respond to inbound requests, but this is how it 
currently has to work.

Even if Mesos (and some new framework) doesn’t solve the stateful serverless 
version of this problem, it is still beneficial if the workload isolation 
between serverless functions is just as good/secure as is available on 
Kubernetes but without the overheads for function containerization and function 
container startup times for each inbound request.

I understand what you said about some of the answer being in the scheduling 
framework rather than in Mesos itself. This Mesos framework would need to make 
a runtime decision about where to schedule the function execution based on the 
inbound request and where the data accessed by the function is distributed 
across the Mesos cluster. Of course, if the function itself has to be 
transferred across the network as part of the response, that just adds more to 
the function startup time.

Kind regards,

> On 7 Sep 2021, at 10:50 pm, Qian Zhang <zhq527...@gmail.com> wrote:
> Hi John,
> Thanks for your suggestion!
>> That is, how do you run serverless workloads that require access to
> persistent data and how do you schedule your serverless functions so that
> they execute with good data locality to ensure decent performance.
> If you are talking about the workload scheduling, I think it should be
> handled by frameworks rather than Mesos. As we all know, Mesos has a
> two-level scheduling mechanism where Mesos master will do the resource
> scheduling for the frameworks running on top of it, and each framework will
> do the workload scheduling after it receives the resources offers from
> Mesos master. Could you please elaborate a bit more on the specific
> requirements for Mesos to support serverless workload?
> Regards,
> Qian Zhang
>> On Tue, Sep 7, 2021 at 8:27 PM John Siegrist <j...@complects.com> wrote:
>> Hello All,
>> In going through the mail archive before subscribing to this list, it
>> seems there have been a number of discussions around what Mesos should do
>> as a project. One use case that might be worth considering is ‘serverless’
>> workloads. This would be something where the Kubernetes containerization
>> doesn’t provide any advantages, and to some extent may actually be a
>> hindrance (slower function startup times as the container spins up).
>> In particular, there is an open problem having to do with supporting
>> stateful serverless workloads. That is, how do you run serverless workloads
>> that require access to persistent data and how do you schedule your
>> serverless functions so that they execute with good data locality to ensure
>> decent performance. A good serverless solution would increase the relevance
>> of Mesos, and it is also a forward-looking direction that doesn’t try to
>> reclaim lost territory related to container orchestration. I don’t know how
>> much work would be needed to build function-as-a-service on Mesos, but
>> since Mesos is already quite good at hosting data workloads it may not
>> actually be all that difficult?
>> Kind regards,
>> John Siegrist

Reply via email to