One of the best parts of my job is that I get to attend lots of open source conferences. But the same thing that makes popular technology events so great is also their biggest drawback: there are so many compelling presentations and activities going on at any one time. This causes major FOMO when I’ve missed a great session and only learned about it after it’s already started (or worse, ended). Online schedules and official conference mobile apps can provide static session information of course, but they can’t predict what I might most like to attend and they’re limited in scope to one specific event.

What I’d like is some sort of contextual service to provide a real-time recommendation of content of interest to me at that exact moment when I’m at a conference and not sure where to go next to make the best use of my time. I want something that can alert me to a great talk that’s about to start, but can also provide me with information about the room that may influence my desire to attend, such as whether it’s way too hot or already standing room only. With that information, I can make a smarter decision whether to attend or choose an alternative session that’s closer, more comfortable, and also covers an interesting topic.

Enter the OpenWhisk-based Conference Plan Bot

So with the release of the OpenWhisk open source project designed for serverless applications, my colleagues and I thought it would be the perfect time to create a bot to do just that for the upcoming O’Reilly Open Source Convention (OSCON). A bot is a software application that can be integrated within an existing conversational tool like Slack or Twitter to automate manual tasks, or provide contextual artificial intelligence for the masses. The Economist and Recode both have introductory pieces on this emerging model.

For the Conference Plan Bot, I can just tweet some keywords at its Twitter handle (@owplan) and it replies with a tailored schedule based on my Twitter profile along with with up-to-date schedule information and current room conditions for each session. See the conversation and link provided to a sample schedule recommendation below. Note that the room data is just simulated from real devices for the example at this time and will not actually be in place in any rooms for this particular OSCON.

Figure 1 shows a closer look at a rendered schedule. Note the list of sessions sorted and highlighted in larger text and darker shades of blue for each session that matched the tweet keywords. Sound, temperature, and humidity data is rendered in green, yellow, and red with an approximation of what that means for comfort.

Figure 1: Schedule recommendation rendered in response to a tweet.
Figure 1: Schedule recommendation rendered in response to a tweet showing ordered session recommendations and room conditions

Bots are a great use case for serverless, event-driven programming with OpenWhisk

This type of on-demand, analytics-powered, IoT-enabled, microservices-based application is a natural fit for a new type of cloud computing programming approach supported by OpenWhisk‘s operations and deployment model called “serverless,” “event-driven,” or “NoOps” development.

This emerging model is fantastic for creating bots, because component services are started instantaneously in response to a particular event, are billed only for the period of time they are executing, and can scale automatically in response to bursty demand from an event like a conference that only lasts a few hours or days. Contrast this approach with earlier cloud technology such as Infrastructure-as-a-Service and Platform-as-a-Service where you continue to pay for resources while they are up, sitting idle, awaiting requests and which are often overprovisioned in advance for anticipated peak demand.

OpenWhisk provides an open source framework for running this new kind of application workload. It enables developers to write code in Node.js, Swift, or with any other environment that can be packaged in a Docker container (native support for Java and Python are also in early stages in the OpenWhisk GitHub repository). And by using a hosted OpenWhisk environment like the one available on IBM Bluemix you get pre-integrated access to the massive existing catalog of services, a monitoring dashboard, and online code editor.

Let’s take a look at a simple serverless application to become familiar with basic OpenWhisk concepts. Figure 2 illustrates a sample flow where a mobile device event might invoke an OpenWhisk trigger to fire an action, which in turn stores analyzed data to an external service. In this case, the invoked action is instantiated on demand, may only run for a few milliseconds, and is then destroyed. A variety of feeds and protocols can provide the binding for the trigger, and the action can build on packages available in the OpenWhisk ecosystem to connect to services.

sample-architecture
Figure 2: Sample flow triggering activity in OpenWhisk

Inside a serverless, event-driven bot architecture with OpenWhisk on Bluemix

Now that you know how a bot works and why they’re good fit for a serverless environment, let’s step into the application architecture and code of our recommendation engine so that you can learn how how you can design and build your own bot to deploy on OpenWhisk.

The Conference Plan Bot is built on a set of nine microservices (our actions) which are invoked by events (our triggers) or another microservice in a sequence of dependent actions. One action is triggered periodically by an internal OpenWhisk alarm (similar to a cron job), one is invoked by regular updates received from a temperature and humidity sensing device, and the main analytics sequence is triggered by a Tweet to @owplan from an attendee looking for a schedule recommendation.

Each of the actions (microservices) in the Conference Plan Bot are implemented in JavaScript, using the Node.js runtime provided by OpenWhisk on Bluemix. You can find the source code on GitHub. Here’s what each action one does within its triggered flow.

Invoked each hour by an internal trigger

  • Update schedule – An action that’s invoked hourly by an internal alarm trigger to retrieve the latest OSCON schedule feed that is published by the conference organizers in iCal format. It parses the complete calendar of over 200 sessions, enriches the metadata for easier analysis later, and saves the data to Cloudant, as shown in Figure 3.
    Figure 2: Updating the conference schedule every hour.
    Figure 3: Updating the conference schedule every hour.

Invoked externally by an IoT device periodically

  • Update room – An action that is invoked every few minutes with periodic temperature and humidity readings captured by more than a dozen individual thermometer/hygrometer sensors connected to Arduino microcontrollers and sent via HTTP over WiFi, as shown in Figures 4 and 5. The data is stored in Cloudant to form a data set of room history, current conditions, and could also be used to enable prediction of room conditions in the future.
    owplan-sensor
    Figure 4: Arduino UNO microcontroller with attached temperature/humidity sensor. WiFI shield not shown.
    Figure 3: Periodic temperature and humidity updates from device.
    Figure 5: Periodic temperature and humidity updates from device.

Invoked by the conference attendee when they tweet at the bot

The main sequence of actions is invoked by a Tweet, which then starts a chain of microservices to execute discrete parts of the analysis and recommendation logic. Actions invoke the next action in the change asynchronously, and state is either passed directly between actions, or through the use of Cloudant as a form of state machine. Figure 6 shows the primary flow of each non-blocking action in the flow.

  • Fetch tweet – An action that is invoked when @owplan receives a mention by an attendee who has tweeted at it with keywords. Twitter sends an email notification to an address managed by SendGrid which in turn invokes the action via a call to the OpenWhisk HTTP API. This causes the action to call the Twitter API to check the timeline for @owplan and invokes the tweet insert action for each mention.
  • Insert tweet – An action invoked one or more times for asynchronous storage of the tweets collected by the fetch tweet action. When @owplan receives several tweets during peak usage, this helps to parallelize the load. It also ensures that there are no duplicates in the Cloudant database so that a specific tweet is replied to only once.
  • Analyze tweet – An action invoked by the insert tweet action. It tokenizes the supplied tweet keywords, and enhances the context with information found in both the user’s Twitter profile and recent tweets to help infer information about their conference session interests beyond just the explicit keywords.
  • Recommend schedule – An action invoked by the analyze tweet action. It takes the analyzed tweet information and scores matches against the conference schedule that was saved by the update schedule action earlier to find relevant sessions ordered by a per session confidence rating.
  • Render schedule  – An action invoked after recommend schedule action which takes the generated schedule recommendation and formats it for use on a responsive web page rendered by PHP with Bootstrap for both mobile devices or computer screens.
  • Update tweet – An action invoked after render schedule to persist the final schedule recommendation to Cloudant for use by the web page and mark the request as complete. Not shown in the diagram below.
  • Reply tweet – An action invoked after update tweet processing is complete in order to respond to the user on using the Twitter API and to provide a link to the recommended schedule.
    Figure 6: Schedule recommendation flow.

Bringing it all together

So to summarize, we are able to use OpenWhisk to provide a runtime for our serverless bot which is composed of microservices triggered by events. OpenWhisk provides an open source option for building applications that must run periodically on a fixed schedule such as one driven by cron. It can also expose APIs to manage data emitted from Internet of Things devices, and it can integrate with tools like Twitter to expose contextual analytics capabilities.

Get started with your own event-driven OpenWhisk bot

The use cases for a Twitter bot (or one integrated with Slack, GitHub, or even triggered by weather changes) are numerous and varied. They are a good way to start learning and developing event-driven application workloads on OpenWhisk. This particular example might be modified to make it applicable to any type of large event such as other conferences of course, but also large fairs or festivals, school schedule selection, travel planning, shopping assistance, and more workloads where context aware processing might be needed and the cost model of serverless deployment makes sense.

At a tactical level there are also various ways to tinker with the application to make it more completely event-driven (goodbye hosted schedule UI), to follow better practices for microservices, and to use more efficient IoT protocols. I have list of some of these ideas in GitHub. Thinking through these alternate approaches might influence how you approach design of your own serverless OpenWhisk apps until a time when best practices for this type of application development crystalizes.

I’d love to hear your ideas for improving our Conference Plan Bot and welcome your pull requests on GitHub. I’d also be very interested to see what sorts of compelling bots you create with OpenWhisk technology, ideally ones that aren’t quite as limited in global impact as conference schedule handling. Please post details below!

And if you’re also going to OSCON, give @owplan a try now, or while you’re there, to figure out what to attend. You might also want to come to the All The Bots day on Tuesday May 17th which will have sessions and a hackathon where you can build your own bot (ideally with OpenWhisk!).

6 Comments on "Plan your conference schedule with a serverless OpenWhisk recommendation bot"

  1. I still think having a human touch is important especially when outsourcing personal tasks, well even for business tasks. I know the speed and efficiency might defer but reliability and adaptability can never be matched. In my opinion, you can bring in virtual assistants in the place of AI bots .. they are multi talented as they are mostly a team (atleast my VAs are at Habiliss), they are available 24 hours and they remember you well and service you personalised .. saves manpower and time..

  2. Hi Charlene, thanks for the comment. I agree there is definitely going to be a need for the personalized service provided by human assistants long into the future. But with the increased volume and capability of automated AI bots coming online, they’ll definitely scale out to handle the tasks that don’t need such a personal touch.

    I like to compare this to airline ticket booking… Most of the mundane processes such as search and booking are automated these days which handles increasing volumes of air passenger volume, but sometimes there’s just no way getting around sorting a booking problem with an agent in person. But that agent is now freed up to work on the truly hard problems, not the mundane ones.

    Now if we only had a bot to resolve the TSA lines at airports…

  3. Peter Moskovits May 16, 2016

    Nice example for serverless computing! I wish I could be there in Austin to attend your All The Bots session… I’d probably attend many of the recommended sessions, too: https://twitter.com/owplan/status/732319949494964225

  4. Albert James May 16, 2016

    Great write up Dan! Truly innovative.

    Something like this would be very handy for the upcoming #Dreamforce. 😉

  5. We’ve been wondering what are bots really useful for, long term, for over 6 years. We’ve seen hundreds, maybe thousands of different bots out there in the world. This is a cool example we will share with our customers. Thanks for showing the technology off. I can’t wait until the day when bots are custom-constructed for specific scenarios like this, versus very generic “shopping” or “weather” scenarios. One thing we’ve learned at UBot Studio is that the more customized and specific to the application the bot is, the more popular it is – even if its niche. Bottom line – it takes a LOT of work to make a Siri.

    Jason

Join The Discussion

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