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
May 3, 2019

Kubernetes Tutorials: 5 Ways to Get You Building Fast

Ready to start working with Kubernetes? Want to build your Kubernetes skills? The five tutorials in this post will teach you everything you need to know about how to manage your containerized apps with Kubernetes.

Continue reading

May 3, 2019

Using Portworx to Deploy and Manage an HA MySQL Cluster on IBM Cloud Kubernetes Service

This tutorial is a walkthrough of the steps involved in deploying and managing a highly available MySQL cluster on IBM Cloud Kubernetes Service.

Continue reading

May 2, 2019

Kubernetes v1.14.1 Now Available in IBM Cloud Kubernetes Service

We are excited to announce the availability of Kubernetes v1.14.1 for your clusters that are running in IBM Cloud Kubernetes Service. IBM Cloud Kubernetes Service continues to be the first public managed Kubernetes service to support the latest upstream versions from the community.

Continue reading