Architect’s Recap: IBM Bluemix OpenWhisk

Share this post:

This week at InterConnect 2016 we announced IBM Bluemix OpenWhisk as an experimental service as well as open-sourcing the underlying codebase.

OpenWhisk is an event-driven compute platform that executes application logic in response to events or through direct invocations–from web/mobile apps or other endpoints.

Bluemix services or external sources provide events to OpenWhisk. An OpenWhisk action—a piece of code written in a developer’s preferred language, or custom binaries embedded in a Docker container—instantly deploys and executes its code when a specific event trigger fires. An OpenWhisk rule binds a trigger to an action.

Since the rate of executing OpenWhisk actions always matches the rate of triggers firing, OpenWhisk scales through optimal utilization. The more triggers fire, the more actions get invoked. If no trigger fires, no action code is running, so no infrastructure is consumed and therefore no cost is generated.

Also, there is no resiliency-related cost overhead required anymore—in contrast to the “traditional” world of long-running VMs or containers, where it is always recommended to deploy multiple VMs/containers to be resilient against outages of a single instance.

OpenWhisk actions are independent and lightweight

The way how actions are executed in OpenWhisk also has the significant benefit of supporting the decomposition of applications into as many small building blocks as needed (in line with the microservices trend), while not increasing the infrastructure cost linear to the resulting running number of building blocks — which is a common inhibitor for adoption of microservices. In fact, it allows decomposition on any level of granularity while only causing runtime costs when the respective microservice is called.

Additionally, OpenWhisk lets developers exclusively focus on their code without concern for monitoring, patching, or securing underlying system, storage, and network. Because OpenWhisk action code is so independent and lightweight, developers working in parallel create a repository of building blocks that can be re-used in any combination without increasing unexpected infrastructural runtime costs.

Besides associating actions with triggers, you can directly invoke an OpenWhisk action via the OpenWhisk API, CLI or iOS SDK. And either through event trigger or direct call, you can connect actions to each other in sequences. OpenWhisk action sequences or chains facilitate creating complex outcomes with minimal or no writing of new code.

Besides Node.js, Swift is the other initially supported language for creating OpenWhisk actions. This native support of Swift allows the large number of iOS developers to use their existing skills for implementing server-side logic while not having to worry about operational concerns, keeping their focus on building great mobile apps.

OpenWhisk adds service and event providers through packages. An OpenWhisk package includes two components: a feed and an action. A feed is a piece of code that sets up everything to enable an event trigger to fire. Creating a trigger (say for any record change in a Cloudant database) involves specifying the trigger type, which is the feed. An packaged OpenWhisk action is portable logic that a service provider makes available to developers to use in leveraging a service as an event source or as the target of API calls to the service. This removes the burden from developers of building client-side logic themselves.

Common uses for OpenWhisk

Some examples of possible event triggers for OpenWhisk actions include:

  • a change recorded a database,
  • an IoT sensor exceeding a certain temperature, a code change in GitHub,
  • or even a simple HTTP request coming from a web or mobile application.

And some use cases for which the OpenWhisk execution model is very well-suited:

  • Decomposition of applications into microservices: The scalable modularity of OpenWhisk actions make them effective for factoring load-intensive, potentially spiky (background) tasks out of front-end code and into the cloud back-end
  • Mobile backend: Since mobile developers usually don’t have experience in managing server-side logic and rather focus on the app running on the device, OpenWhisk actions chains serve well as a mobile back-end
  • Data processing: Due to the plethora of data available these days, there is a common need for being able to process and react to new data in one or the other way. This includes both structured data stored in records as well as document, image or video processing
  • Internet of Things: To a large degree, IoT scenarios are inherently sensor-driven. An OpenWhisk action would make an effective response to a sensor exceeding a particular temperature, for example.

Distinguished Engineer, Serverless / FaaS & IBM Cloud Functions Chief Architect

More Community stories
March 22, 2019

VIDEO – Containerization Explained

We're back with another lightboarding video, and this time we'll be investigating containerization. Sai Vennam will be using the example of a Node.js application that we want to push into production, and we'll be using two different form factors—virtual machines (VMs) and containers—to explain the advantages of containerization.

Continue reading

March 21, 2019

VIDEO – What is a GPU?

In this video, Alex Hudak covers the basics of GPUs, including the differences between a GPU and CPU, the top GPU applications (including industry examples), and why it’s beneficial to use GPUs on cloud infrastructure.

Continue reading

March 21, 2019

Knative on IBM Cloud Kubernetes Service: Your First App… Now Even Easier!

We're excited to bring you a change to how IBM Cloud Kubernetes Service exposes Knative. The process has been simplified greatly and will make your life much easier.

Continue reading