When you develop an action for Apache OpenWhisk it can become cumbersome and time-consuming to upload the action to your OpenWhisk instance in order to test it. This is especially the case when your (Node-based) action contains NPM dependencies. You can always use Node.js to run the action locally. However, ideally one wants to run in an environment as similar to the cloud as possible - in this case run within an OpenWhisk Docker image. This is where runtest.sh comes in handy: it does exactly this - run the action locally in an OpenWhisk container. I hope this tool will make it into wsk or a similar tool for local OpenWhisk action development.
Lately, I had a lot of conversations about multi-tenancy (MT). So I finally wrote up my thoughts on that term. In this post I will argue that MT is a value that depends on a continuous variable. Therefore, any statement about a system being “MT” can only be made in the context of the given requirements. It is not a property of the system itself . I will also show that perfect multi-tenancy is indistinguishable from single-tenancy (ST). MT is a value that depends on a continuous variable Imagine a step-function "ST-MT" (values are either 0 or 1) that determines if a given system is MT (1) or ST (0). That function will look like this: ST-MT = function (system, business requirements) Look at the function’s arguments: the first one is obvious – the result will depend on the system itself. The second one is more interesting: it is the cumulative set of business requirements . Typically, these requirements will include: Resource sharing: systems typically declare