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, John > 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
