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/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

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-act....

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.

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/ or GitHub.

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)

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.

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.

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?