Hi Qian,

There’s a deployment time process, where the user uploads their functions to 
the serverless platform. At that time, the system packages/containerizes the 
function code and stores the container (or lightweight VM) in a registry. From 
there, a serverless endpoint is setup and linked to your containerized 
function. This function upload step works very similar to how Heroku PaaS 
operates, where the service platform runs a build step before launching your 

Since sending you the first email, I have since learned that AWS Lambda service 
uses something called Firecracker which is using a containerization technology 
that is closer to VMs than docker containers. Hence, the reference to 
lightweight VM above.

Kind regards,
John Siegrist

> On 12 Sep 2021, at 11:24 pm, Qian Zhang <zhq527...@gmail.com> wrote:
> 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

Reply via email to