This document discusses developing a Go runtime for Apache OpenWhisk to improve upon the existing DockerSkeleton approach. The key points are: 1) The current DockerSkeleton approach has some limitations like being fragile and having potential race conditions. 2) The new design keeps the Python proxy but uses a Go executable that runs as a Unix command, reading input and writing output on stdin/stdout/stderr. 3) An initial implementation has been done in a GitHub repository replacing DockerSkeleton with a Go server and refactoring to a piped loop. Testing with a Swift executable showed promising performance improvements over DockerSkeleton.

1. Apache OpenWhisk
Go Runtime
(and some correlated stuff)
Michele Sciabarrà
michele@sciabarra.com

2. • Using Go for Serverless app on AWS Lambda
• Looking for a Good Serverless on Kubernetes
– OpenWhisk of course
• "Open Source" Enthusiast
– The Guardian: "Lambda and Serverless is one of the worst form of
proprietary lock-in we've ever seen in the history of humanity"
• "Help Wanted" for Go Actions
on GitHub issues
– So let's do it!

3. But Why Go?
• Just. One. Word.
• learning
• development
• execution
• deployment
• debugging

4. Current Status of
Go Support in OpenWhisk
• Currently based on DockerSkeleton
– In short:
• Upload an executable
• A python "proxy" will receive the request
• A "system" call will invoke the executable
• Output is collected and sent back
It sounds vaguely familiarial...
...I have heard of this, but when....?

5. Hmm, how can we improve it?
• Step 1:
the executable with do
it, all replacing entirely
the proxy
• Issues:
– "fragile"
– "a race condition" when
you do the replacement
– not reusable with other
binaries
• Step 2
- keep the proxy in Go
(or rust or whatever)
• - use an executable that
-loops on stdin line by
line
• - produce output on
stdout
• log on stderr
– IN SHORT,
it is an Unix command 

6. The new Design

7. Work Done So far
https://github.com/sciabarracom/openwhisk-runtime-go
• Implemented the GO
Server with
replacement
– exec-replacement
branch
• Refactored to a piped
loop implementation
– pipe-looop
branch
• Tested the pipe-loop
with a Swift executable
– wrote an HelloWorld
Swift example
reading in input and
writing in output
• Simple Docker images

8. ...is it actually faster?
let's measure it!
Test: 100 threads executing 100 actions
executed on OSX using Docker for Mac
(executables compiled for linux-amd64)
Go performances against DockerSkeleton
Swift performances against DockerSkeleton
...apparently yes!

9. Work in Progress
• Short term
– Manage properly errors
of misbehaving actions
– A robust replacement
for DockerSkeleton
– Running the test suite
against the new runtime
– Changes to the cli
– A change to the client
library
– Hand-over to Apache
• Medium term
– Use it for swift actions
– Use it for docker
skeleton