32 ms·

I'm relatively new to the Serverless/FaaS space. Or to be more precise: I missed AWS Lambda and only heard about it when OpenWhisk was donated to Apache. I hav

I'm relatively new to the Serverless/FaaS space. Or to be more precise: I missed AWS Lambda and only heard about it when OpenWhisk was donated to Apache. I have a couple of questions, maybe someone here has answers for me: 1) In particular I'm wondering about expensive one-time/setup operations (e.g. opening a database connection) that are usually done once at startup of a service. But that doesn't really apply here. How are these things handled? 2) As a Java guy I also wonder which of these tools support Java and how they deal with dependencies and JVM startup times etc. 3) And my last question: How do these integrate into development workflows? Continuous integration? Run this offline/local etc. Will I need a Kubernetes instance on my machine?

soamv 10y ago
1. One time operations like that are run at module init time. Here's a trivial example: https://github.com/fission/fission/blob/master/examples/python/guestbook/add.py#L9 https://github.com/fission/fission/blob/master/examples/pyth... 2. We don't support Java yet, but we'd like to. The JVM would already be running by the time there's a request, so there won't be a JVM startup in the request path. 3. Dev workflows: Lots to do on that front. A big part of our roadmap is improving the dev workflow, better versioning support, CI/CD. For running locally, yes, the best way is to run a local Kubernetes instance on your machine. minikube makes it very easy to do that, see the instructions in the README: https://github.com/fission/fission#setup-kubernetes https://github.com/fission/fission#setup-kubernetes
- rabbah 10y ago
  OpenWhisk actions (equivalent to functions in other frameworks) have two life cycle events: initialization and execution. The very first activation of an action (a cold start), will initiate both events. Future activations of the action, if they're contemporaneous, will only generate execution events. This is the warm execution, which can take advantage of previous activations. To provide scaling, it is necessary to sometimes create new execution environments for the repeated actions, and so that means new initialization events. While one cannot rely that all executions after a cold start are warm, it's possible to for the action code to check if it's warm and forgo internal initialization as needed. This is a convenient trick that's common to avoid expensive setup. For Java actions running in OpenWhisk, this can be done with static fields. A nice flow of the lifecycle can be seen on slide 24 here http://www.slideshare.net/psuter/openwhisk-deep-dive-the-action-container-model http://www.slideshare.net/psuter/openwhisk-deep-dive-the-act....
  - lars_francke 10y ago
    Thank you both. That was very informative. Trying the OpenWhisk Vagrant demo now. I've seen a couple of issues and I agree that it would be fabulous to have OpenWhisk integrated into OpenShift/Kubernetes.
    - rabbah 10y ago
      It remains to be seen if the abstraction that Kubernetes adds to manager containers will have performance characteristics that serverless demands - considering the need for container reuse, reclamation, pause/unpause, and elastic scaling. Should you need help with OpenWhisk please reach out to us on http://slack.openwhisk.org/ http://slack.openwhisk.org/ or GitHub.
RhodesianHunter 10y ago
I write a lot of Java on AWS lambda and love it for a lot of use cases. You manage dependencies by bundling them up in a JAR or zip file (handled by Maven or Gradle) Static assets can be kept warm between invocations (nice for things like DB connections)
- lars_francke 10y ago
  Perfect, thank you. Some of the docs I read made it out so that instances of my functions would never be reused. Or to put it better: I should not rely on them being reused. If I keep DB connections for example am I now relying on an implementation detail or is this documented behavior? I realize that this will be different for every system.
  - RhodesianHunter 10y ago
    As long as you invoke your lambda again within a few minutes it will re-use your static assets. I'm sure they use your invocation history in deciding how long to keep them around.
l31g 10y ago
My job is mainly developing on aarch64 server platforms. Does Fission work on aarch64 machines? If not, are there any plans to provide support? How much work is needed?

soamv 10y ago

1. One time operations like that are run at module init time. Here's a trivial example: https://github.com/fission/fission/blob/master/examples/python/guestbook/add.py#L9 https://github.com/fission/fission/blob/master/examples/pyth... 2. We don't support Java yet, but we'd like to. The JVM would already be running by the time there's a request, so there won't be a JVM startup in the request path. 3. Dev workflows: Lots to do on that front. A big part of our roadmap is improving the dev workflow, better versioning support, CI/CD. For running locally, yes, the best way is to run a local Kubernetes instance on your machine. minikube makes it very easy to do that, see the instructions in the README: https://github.com/fission/fission#setup-kubernetes https://github.com/fission/fission#setup-kubernetes

rabbah 10y ago
OpenWhisk actions (equivalent to functions in other frameworks) have two life cycle events: initialization and execution. The very first activation of an action (a cold start), will initiate both events. Future activations of the action, if they're contemporaneous, will only generate execution events. This is the warm execution, which can take advantage of previous activations. To provide scaling, it is necessary to sometimes create new execution environments for the repeated actions, and so that means new initialization events. While one cannot rely that all executions after a cold start are warm, it's possible to for the action code to check if it's warm and forgo internal initialization as needed. This is a convenient trick that's common to avoid expensive setup. For Java actions running in OpenWhisk, this can be done with static fields. A nice flow of the lifecycle can be seen on slide 24 here http://www.slideshare.net/psuter/openwhisk-deep-dive-the-action-container-model http://www.slideshare.net/psuter/openwhisk-deep-dive-the-act....
- lars_francke 10y ago
  Thank you both. That was very informative. Trying the OpenWhisk Vagrant demo now. I've seen a couple of issues and I agree that it would be fabulous to have OpenWhisk integrated into OpenShift/Kubernetes.
  - rabbah 10y ago
    It remains to be seen if the abstraction that Kubernetes adds to manager containers will have performance characteristics that serverless demands - considering the need for container reuse, reclamation, pause/unpause, and elastic scaling. Should you need help with OpenWhisk please reach out to us on http://slack.openwhisk.org/ http://slack.openwhisk.org/ or GitHub.

RhodesianHunter 10y ago

I write a lot of Java on AWS lambda and love it for a lot of use cases. You manage dependencies by bundling them up in a JAR or zip file (handled by Maven or Gradle) Static assets can be kept warm between invocations (nice for things like DB connections)

lars_francke 10y ago
Perfect, thank you. Some of the docs I read made it out so that instances of my functions would never be reused. Or to put it better: I should not rely on them being reused. If I keep DB connections for example am I now relying on an implementation detail or is this documented behavior? I realize that this will be different for every system.
- RhodesianHunter 10y ago
  As long as you invoke your lambda again within a few minutes it will re-use your static assets. I'm sure they use your invocation history in deciding how long to keep them around.

l31g 10y ago

My job is mainly developing on aarch64 server platforms. Does Fission work on aarch64 machines? If not, are there any plans to provide support? How much work is needed?