Introduction to IBM Bluemix OpenWhisk
Recently, IBM announced OpenWhisk, an event-based programming service for the Bluemix platform. The source code of the project is also available for the open-source community. Seriously, it has to be something cool.
OpenWhisk architecture
Let’s take a look at the main concepts behind OpenWhisk. First of all, it is distributed and serverless, which means that developers do not need to manage the environment for their code. Deployment, monitoring, and scaling activities are covered by the OpenWhisk service. It allows to develop reliable applications without having too much expertise in related areas.
Also, OpenWhisk follows the event-driven programming paradigm, encouraging developers to create microservices that emit and handle events. A microservice doesn’t need to know anything about what listens to its events and how they are handled. Loose coupling is one of the primary advantages of this model. Plus, you are free to choose a runtime and tools you want for every event handler.
Here is the high-level architecture of OpenWhisk.
Source: IBM Bluemix
In short, the execution flow can be described as the following:
- An application can have several triggers.
- Each trigger can be associated with several actions via rules.
- Once a trigger has been fired, it executes all associated actions.
- Actions can fire triggers or call other actions directly.
- Actions and feeds can be grouped into packages to allow usage between projects.
Actions, triggers, and rules are building blocks of every OpenWhisk application.
Developers provide their code via actions, stateless functions written in one of the languages supported by the platform. Once the code has been sent to OpenWhisk, users can remotely execute it via a REST API. If you are interested in the details of how exactly OpenWhisk executes your code, check out the GitHub repository. At its core, OpenWhisk wraps developer’s code into a Docker container and executes it. The container comes with a predefined version of a specific runtime and several preinstalled libraries.
Triggers correspond to the types of events and can be attached to specific feeds. They can’t do anything on their own, but they can be associated with actions via rules. This link means that once an event comes in and fires a trigger, all associated actions will be invoked.
While triggers can be fired using the REST API, developers are encouraged to use feeds. Feeds are the sources of events in OpenWhisk applications. For example, OpenWhisk is shipped with a GitHub package that basically registers a webhook. Once something of interest has occurred, it fires a trigger in OpenWhisk.
Can I run it locally?
OpenWhisk is an open-source project, and users can deploy their own copy of the service. The list of instructions can be found on its GitHub page.
However, this is not the strongest side of OpenWhisk. At the time of writing, OpenWhisk itself wasn’t Dockerized. README states that supported operating systems include Ubuntu 14.04, Mac OS X El Capitan, and Windows using Vagrant. Here are some of the most notable dependencies for Ubuntu deployment:
- Python
- Java
- Ant
- Scala
- Docker itself
In addition to system dependencies, users need to set up Cloudant access in Bluemix and export the credentials into their environment. Recently, support for local CouchDB has been also added.
In the era of one-line deployments and containers, it would be great to have a less invasive installation process. The developer environment via Docker Compose would work well in this case.
OpenWhisk vs. AWS Lambda
Let’s see how OpenWhisk compares to a similar offering from a different provider.
AWS Lambda is an event-driven programming service from Amazon. Basically, it is a direct competitor for cloud-based OpenWhisk.
In terms of language support, Lambda provides a way to deploy JavaScript, Python, and Java functions. There is no Docker integration, which OpenWhisk has, but you can work around this by using other Amazon services such as EC2 Container Service.
One of the biggest Lambda advantages is the whole Amazon stack behind it. In short, developers can create a completely serverless application by doing the following:
- Deploy the front-end part of the application on S3 and serve it from there
- Deploy the back-end part of the application on Lambda
- Consume Amazon services right from the browser JavaScript using Cognito
Also, there’s an application framework—Serverless—that adds features like local execution, automatic deployment, versioning, aliases, and code reuse for Lambda projects.
As for OpenWhisk and Bluemix, there’s still a gap that needs to be closed. The Bluemix Object Storage service doesn’t provide the ability to directly serve HTML assets, which means that users need to run a separate container or a virtual server. It is possible to consume AWS services from browser applications using AWS Cognito, which provides credentials with a limited access. The Bluemix platform does not offer such functionality. It is very likely that these issues will be solved as soon as OpenWhisk develops into a mature product.
Conclusion
OpenWhisk is a good fit for background jobs in web and mobile applications. To some point, it can even provide an entire back-end API for your application. The event-driven nature of OpenWhisk should also work well in IoT scenarios.
However, the service is not suitable for applications relying on long-living connections (for example, chats using web sockets). The execution time for OpenWhisk functions is limited, so you won’t be able to replace a simple web server with it.
IBM doesn’t charge you for using the hosted version yet. As of now, information on the pricing model hasn’t been released, but we can expect similarities with AWS Lambda. There is no point in using OpenWhisk in production right away, but it is exciting to see what it can become in the future. As for myself, I’ve already forked the repository.
Further reading
