Enter the OpenWhisk-based Conference Plan BotSo 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.
Bots are a great use case for serverless, event-driven programming with OpenWhiskThis 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.
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.
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.
Invoked by the conference attendee when they tweet at the botThe 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.