A brief recap: I implemented support for Golang actions, and adapted support to work also with Swift, using another "high performance" protocol. The support actually works for any binary that follow a certain "protocol", so it could be used for programs written in c, rust, haskell, whatever.
For convenience the proxy also supports zip and sources. Source support works compiling an action on the fly, thus producing a binary when you init a runtime. Source support is language specific, so I have now an image able to compile golang actions and another able to compile swift actions. More can be provided (and it would be interesting to do). All of this has been already coded and tested, I submitted the PR waiting for review. Now my proposal. Source support has a problem: slow initialization. Source support is very convenient in development but when the application scale, re-initializing more runtimes using source is slow. So you have a warm-up problem. This problem can be solved precompiling the images but it was considered a complex problem to solve. Except I realized is not! Having built source support in the runtimes, it is a small step to adapt the runtimes to became also offline compilers! Most notably my idea is this: assuming you have the sources in folder like ./src, you can generate the executable using something like: $ docker run -v $PWD/src:/src -v $PWD/out:/out actionloop-golang compile main.go main Translated: 1. run the runtime as a compiler invoking a 'compile' in the image 2. pass the source and the target folder as volumes to the image 3. run the compilation (compile will expect sources to be in /src and place the final executable in /out) This way you will be able to generate the binaries offline without having to do a complex setup. Then you can deploy the binary with $ wsk action create myaction out/main --native Processing sources for generating binaries can be done by some processing tools, at some point can be even integrated in wskdeploy or provided by some preprocessing. That is not the biggest problem, once you have support in place on the runtimes. If you agree on this proposal I can go on implementing AND DOCUMENTING them for the images I am building, the go image and the swift image. Thoughts? -- Michele Sciabarra openwh...@sciabarra.com