Thanks John for the detailed info which really helps me understand the requirements better.
For each request, the serverless runtime launches one copy of the > containerized function. Can you please elaborate a bit more on this? What did you mean for the `containerized function`? Is it just a normal function call inside the container which packages the supported language runtime and the function or an on-demand short-live container dedicatedly launched for each request? Regards, Qian Zhang On Wed, Sep 8, 2021 at 9:30 PM John Siegrist <j...@complects.com> wrote: > 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 >
