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:

Share on LinkedIn

Add Comment
No Comments

Leave a Reply

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

More Community Stories

Beyond Cyber Monday: Shipping Logistics App Built on Bluemix

Tracking goods from place of origin to destination is a huge industry challenge. Read more on how P.L.M. Industries and the IBM Bluemix Garage built a shipping logistics app to providing visibility from manufacturer to end user.

Capgemini uses Bluemix & IoT to stay ahead of change

In order to keep pace with such rapid change, Capgemini has identified shifts in 3 key areas: connected customers, connected vehicles and connected insights, which as Vaidya says, “Is all about data analytics.” To stay ahead of change, Capgemini leverages IBM Bluemix.

Debugging node apps running on Cloud Foundry

I've just posted an entry to my personal blog titled "debugging node apps running on Cloud Foundry", describing a technique you can use to debug your node apps while they're running on Cloud Foundry.