Analysis / Technology / Tutorials /

An Introduction to OpenWhisk, IBM’s Open Source Serverless Computing Platform

6 Jan 2017 1:10am, by

When Amazon introduced serverless computing through AWS Lambda in 2014, no one expected it to become an alternative computing model to virtual machines and containers. But since its launch, Lambda has evolved to become a key component of AWS compute services portfolio. Deeper integration with mainstream AWS services, support for popular languages, streamlined deployment model all make Lambda a viable microservices platform for AWS customers.

Though AWS Lambda caught the attention of the industry and developers, there is a general concern about lock-in. An application designed for Lambda cannot run outside the context of AWS. For customers considering an alternative that can run within the datacenter and cloud, OpenWhisk from IBM can be a potential option.

Announced in February 2016, OpenWhisk is an event-driven computing framework from IBM. It is integrated with Bluemix, IBM’s Cloud Foundry-based PaaS and is also available as an open source software that can be deployed behind the firewall. Adobe and IBM jointly submitted OpenWhisk to Apache, which has now become an incubation project. It is one of the first open source serverless platforms in the market. In December 2016, IBM announced the general availability of Bluemix OpenWhisk, the hosted version in the public cloud.

OpenWhisk Concepts and Terminology

Like other serverless frameworks, OpenWhisk invokes code snippets when a specific event occurs. There are three key concepts in OpenWhisk: Triggers, Rules, and Actions.


Triggers are associated with specific events such as adding a new row to a table, a commit in GitHub, a sensor reading exceeding a specific threshold. The Trigger is fired by the event source when a specific condition is met.

Actions is where the rubber meets the road. They are the code snippets that developers write that get invoked directly through an HTTP call or by a trigger. OpenWhisk supports JavaScript, Java, Swift, and even arbitrary binaries packaged as Docker containers.

Rules associate Actions with Triggers. They act as the glue binding the code snippets with event sources. One Rule can associate multiple Triggers with an Action.

Additionally, deployments can be streamlined through packages and feeds. A package is a bundled collection of related code snippets that can be easily shared with others. Feeds make it easy to integrate actions with event sources. It is also possible to chain multiple Actions into a sequence, which can be associated with a Trigger.

The simplest way to understand OpenWhisk is to think of it as a Pub/Sub infrastructure with the ability to embed and invoke code within the subscriber. Triggers can be compared to publishers while Actions are like subscribers. Rules play the role of a topic that associate subscribers and publishers.


All the entities of OpenWhisk including Triggers, Rules, and Actions can be created and invoked through the REST API. For example an event source can call the REST endpoint to initiate a Trigger which in turn invokes the corresponding Actions. This model makes it easy to implement a loosely coupled eventing system connecting various event sources with code snippets at runtime.

If you have used AWS Lambda, you will find the concepts familiar. The key difference between Lambda and OpenWhisk lies in the configurable Triggers. Apart from supported AWS services such as DynamoDB, Simple Queue Service (SQS), Simple Notification Service (SNS), and Kinesis, AWS developers will have to wait for Amazon to add Lambda triggers for new services. In OpenWhisk, they can decide which event will initiate the Trigger. Since it is just a REST API call, a wide range of sources can be a part of the event-driven, serverless computing environment.

Getting Started

The easiest way to get started with OpenWhisk is to sign up with IBM Bluemix. You can create your first action using the browser-based code editor provided by Bluemix. Below is a simple Action written in node.js to return the weather information of a specific location.

var request = require('request');

function main(params) {

  var location = params.location || 'Hyderabad,India';

  var url = ' item.condition from weather.forecast where woeid in (select woeid from geo.places(1) where text="' + location + '")&format=json';

  return new Promise(function(resolve, reject) {

      request.get(url, function(error, response, body) {

          if (error) {



          else {

              var condition = JSON.parse(body);

              var text = condition.text;

              var temperature = condition.temp;

              var output = 'It is ' + temperature + ' degrees in ' + location + ' and ' + text;

              resolve({msg: output});





Once the Action is in place, you can download the OpenWhisk CLI to your machine. Written in the Go language, the client CLI is available for Linux, Mac, and Windows.

Like the Cloud Foundry CLI, OpenWhisk’s wsk tool needs to be configured for a specific API endpoint. For each Bluemix account, there will be a unique authentication key that can be passed to the wsk tool.

We can configure the CLI with the following command

wsk property set --apihost --auth <unique_token>

You can list all the available Actions with the below command

wsk action list


You should see the weather Action that we created in the previous step. Each entity in OpenWhisk is identified through a unique namespace that is typically the username of the current user. This will avoid conflicts in naming.

Let’s go ahead and invoke the Action through the CLI

wsk action invoke weather --blocking


This should return a JSON response that contains the result that we expect. Notice the –blocking switch that we are using while invoking an action. This will make a synchronous call to the function blocking the client to wait till the the execution is done.

We can also pass parameters to our Action. Let’s invoke the function with a custom parameter along the –result switch that will only show the output.

wsk action invoke --blocking --result weather --param location "Redmond, WA"


Though we have been using the CLI, the weather Action that we created can be easily fired by a Trigger. For example, we can create a mobile application that will invoke the Trigger when a specific condition is met.

Let’s now invoke the Action with cURL. But before that, we need to encode the authentication token in Base64. Run the following commands on a Mac to see the output. You will also need to install jq for parsing JSON from the command line before executing cURL.

export TYPE='Content-Type: application/json'

export AUTH='Authorization: Basic '`wsk property get --auth | awk '{printf("%s", $3)}' | base64 `


curl -s -X POST --data '{"location": "Redmond,WA"}' -H "$TYPE" -H "$AUTH"$NAMESPACE/actions/weather?blocking=true  | jq '.response.result.msg'


Developers can initiate the Trigger from any language that supports HTTP calls.

OpenWhisk is a powerful, open source serverless computing platform. It will be integrated with multiple other projects that need serverless and Functions as a Service capability.

In the upcoming articles, we will explore configuring and integrating OpenWhisk with Internet of Things applications. Stay tuned!

IBM is a sponsor of The New Stack.

Feature image via Pixabay.

A digest of the week’s most important stories & analyses.

View / Add Comments