Building Event-Driven Architectures with OpenWhisk

by Roger StrukhoffJune 30, 2016
Senior Cloud Foundry Field Engineer JP Genovese takes meetup attendees through a bit of history and a bit more of setup, build, deploy, and run.
JP Genovese, Senior Cloud Foundry Field Engineer, Altoros

JP Genovese, Altoros

Previously, we provided an introduction to OpenWhisk—a distributed service for managing microservices. It allows developers to upload event handlers to a cloud service, then registers those handlers to respond to events. At the Austin meetup, Juan Pablo (JP) Genovese of Altoros provided a deeper insight into this platform and event-driven architectures in general.

To paraphrase a popular saying, OpenWhisk is old whiskey in new bottles, er, containers.

That attempt at poetic metaphor having failed, as OpenWhisk is indeed a profoundly new way within IBM’s Cloud Foundry-based Bluemix environment to handle event-driven microservices.


What is it?

During his talk, JP noted that the wider concept of event-driven architectures (EDAs) has been around for decades, and has seen an evolution from the use of remote-procedure calls (RPCs) to the establishment of entire Service-Oriented Architectures (SOAs), stopped to REST, and are now used to launch modern-day microservices.

In what’s termed an “extreme loose coupling model,” JP showed how EDAs can be represented generally by the following graphic:


JP provided some background, mentioning Amazon Lambda and Google Cloud Functions as two early methods of spinning up serverless applications. Yet neither is open source and “you can’t really experiment with (them) and you can’t really understand how (they) work internally,” he noted. OpenWhisk, in contrast, is community-driven.

He then presented a diagram familiar to members of the OpenWhisk community that shows Bluemix (and other parts of a potential service ecosystem) at the end of process deployments triggered by feeds:



Time to code!

The actual code is pretty simple, he said, taking attendees through a few slides that are self-explanatory each step of the way.

First, a couple of slides about the concepts involved here:



Then, time to get it to run locally on your machine:


Time to install the database (OpenWhisk runs on Cloudant, and on CouchDB as shown in this example):

JP provided a lighthearted moment while discussing what to do after installing the database: “I do love whiskey, so I named my admin user after lagavulin—my favorite whiskey, from the island of Islay, and which is absolutely awesome—and the password ‘singlemalt’.”

Duly noted:


Time to deploy! (He noted that even with this simplicity, one should expect 20 to 30 minutes for it to run, as it installs all the packages needed for it to run.)


JP then showed the code for basic usage, for asynchronous calling (a key aspect, of course, when dealing with events), and setting a parameter.





Yes, it supports Docker

Juan Pablo concluded by noting that yes, OpenWhisk does support Docker, something that can be invoked easily.

Additionally, for organizations working within IBM’s Watson environment, “triggers are fired by a dictionary of key-value elements,” JP noted. “When an element satisfies a condition, the trigger fires. When you want an execution after the trigger fires, you define a rule. All this then creates an event.”

For more, check out the OpenWhisk GitHub repo. The product is outlined in many nice presentations—here’s one from prominent IBM Bluemix Lead Architect Animesh Singh.

Asynchronous. Event-Driven. Open. Cloud Foundry. OpenWhisk. Follow JP’s teaching, and it will be time to enjoy a wee dram. 😉


Want details? Watch the video!

Table of contents

  1. What is a reaction? (5’14”)
  2. What is OpenWhisk? (10’45”)
  3. Basic concepts with OpenWhisk (14’30”)
  4. How to run it locally (19’00”)
  5. Why is CouchDB needed? (20’45”)
  6. Deployment process (22’30”)
  7. OpenWhisk basic usage (23’15”)
  8. Working code parameters (25’10”)
  9. How to add Docker (25’50”)


See the full slide deck by Juan Pablo for OpenWhisk’s main concepts, the code for basic usage and running it locally, asynchronous calling, etc.


Further reading:


About the expert

JP Genovese, Senior Cloud Foundry Field Engineer, Altoros bio
Juan Pablo Genovese is a Field Cloud Foundry Engineer at Altoros. He has been developing software for 19 years, and as a Jack of All Trades, has also been into DevOps work. Juan Pablo is focused on training new DevOps at Altoros and identifying the needs of the community. His professional interests include high performance / high availability solutions with cloud technologies, as well as designing architectures that meet customer expectations.


The post was written by Roger Strukhoff and edited by Alex Khizhniak.