Community

Architect’s Recap: IBM Bluemix OpenWhisk

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.

Share this post:

Add Comment
No Comments

Leave a Reply

Your email address will not be published.Required fields are marked *

More Community Stories

Building up to OpenStack II: Improving Cloud Performance

In this blog, second in a series, we’ll cover more cloud fundamentals: More about QEMU, and lots more about how to improve your cloud’s overall workload performance.

Continue reading

Chasing down data and stronger performance

Threshold tests, max aerobic tests, and sprint tests became a regular part of my mornings. I knew my average watts. This attention to data paid off on the cycling course of the Ironman Lake Placid when I finished the bike portion 23 minutes faster. I was finally learning to embrace data to drive my performance.

Continue reading

Updated: Node.js & Liberty Buildpack

Here is what has changed in the Node.js Buildpack v1.3-20140821-1143 and Liberty Buildpack v1.3-20140818-1538.

Continue reading