Serverless, IoT and OpenWhisk

Editor's Notes

• #2: Hello, my name is Alex Glikson, I work for IBM Research in Israel, and I am going to talk about Serverless IoT Applications with Apache OpenWhisk.
• #3: During this session, I will start by giving a brief overview of the Serverless paradigm, and specifically OpenWhisk. Then, I will talk about the Internet of Things and the applications targeting this domain. And finally, the main topic of this session is Serverless application patterns, applicable to the domain of the internet of things.
• #4: So, the first topic is an overview of the Serverless paradigm and the Apache OpenWhisk project.
• #5: As you probably know, the Serverless paradigm became very popular in the last 2-3 years, and there are multiple commercial offerings in this space, from IBM, Amazon, Microsoft, Google, and others. In addition, there has been a movement towards an open source Serverless platform, which resulted in creation of the OpenWhisk project, which is now under incubation at the Apache Software Foundation. InfoWorld, May 2017, “Get functional! 5 open source frameworks for serverless computing" http://www.infoworld.com/article/3193119/open-source-tools/get-functional-5-open-source-frameworks-for-serverless-computing.html https://aws.amazon.com/lambda/ https://github.com/iron-io/functions
• #6: Let’s briefly review the architecture of OpenWhisk. On the left, you can see a collection of event sources, such as data stores, social media or physical equipment sending events. Those events are organized in feeds, that generate triggers. Then a trigger can be associated by rules with one or more actions. An action is really the heart of OpenWhisk, comprising a single-tasked function, that can be developed in pretty much any programming language. Actions can perform a standalone computation, or they can interact with other services – either deployed in the context of the same application, or 3rd party services. Every time a new event is detected, actions associated with this event are instantiated in containers, invoked, and then released. For optimization purposes, OpenWhisk maintains pools of so-called ‘warm’ containers, often reducing the action invocation time to just few milliseconds.
• #7: Besides the ‘core’ OpenWhisk components that support the provisioning and life-cycle of triggers, actions, and related artifacts, there is also a large and growing open source ecosystem. It includes various developer tools, a library of packages that make it easy to integrate with common services such as Kafka or Github, and many more.
• #8: Let’s take a look at a simple Serverless application implemented with OpenWhisk. We are going to monitor a particular issue in a github repository, save the incoming comments in a database in the cloud, and provide a REST-based query interface, applying some custom aggregation logic. <click> The implementation comprises 7 artifacts: 1 - a database instance 2 - an OpenWhisk trigger, listening for github notifications 3 - An action writing to the database, called ‘writeToDb’. In fact, this is a sequence of two actions – our custom action, number 4, performing some simple JSON transformation, and the standard ‘create-document’ action from the Cloudant package that actually writes to the database 5 is an action performing simple aggregation of the data stored in the database. In this case – just counting the comments, called countInDb. It also comprises a sequence of two actions – a standard one, list-documents, from the Cloudant package, and our custom action, number 6, called totalRows. Finally, 7 is the API gateway configuration, mapping an external REST api, meetup/v1/count, to the countInDb action. By the way, the application is up and running, so you can try it out by adding a comment and going to the URL linked on the slide.
• #9: Now, the actual code needed to make this work is really tiny – about 10 lines of javascript code for the two actions, plus about 10 CLI commands for the setup. That’s it!
• #10: Beyond the simple example we just saw, the Serverless paradigm, and OpenWhisk in particular, can be applied in many different application domains – Cognitive, internet of things, Mobile, and many others. <click> In the session we are going to focus on applications in the IoT domain.
• #11: Now let’s briefly talk about the Internet of Things, or IoT, in general, and applications targeting IoT in particular.
• #12: Let’s start with the concept of ‘internet of things’ itself. What is ‘internet of things’? It is essentially an attempt to capture an extensive trend in the industry, where physical devices, or ‘things’, become connected and programmable. For example, you can think of environment sensors, measuring temperature or air pollution in different locations around the world, and reporting those measurements over the Internet. Or, it could be a smart bracelet that measures your fitness activity, and sends the data to your mobile phone, where it can be analyzed and visualized. In the industrial sector, it could be a piece of mechanical equipment controlled by a computer, collecting thousands of different metrics that can be used for fault detection or predictive maintenance. Another example is a personal navigation device, such as a mobile phone, or maybe a connected car, interacting with other cars in a collaborative driving or autonomous vehicle scenarios. Emergence of such applications has been significantly accelerated by the broad adoption of smart phones, and the mobile infrastructure that enables it, making connectivity a real commodity, almost anywhere in the world. images: - https://www.i-scoop.eu/internet-of-things-guide/ - https://datafloq.com/read/7-trends-of-internet-of-things-in-2017/2530
• #13: Now let’s talk a bit about main characteristics of IoT applications. First, IoT applications often have so-called Big Data properties, due to large volumes of devices and data that they collect, as well as large variety of data, that requires custom processing of different kinds of data. Secondly, devices are typically connected to the Internet via Gateways rather than directly. Those gateways are responsible for controlling the devices and for collecting and aggregating events and data. Third, data often undergoes initial processing at the gateway. For example, this could be due to latency, bandwidth, or privacy constraints. Gateways often perform simple real-time stream processing, such as property-based filtering, or time-based aggregation. Finally, data is often shipped to a centralized cloud for storage and analytics, which in turn could result in communication back to the device, to perform an action or to update thresholds used for stream processing.
• #14: Let’s take a look at an example architecture of an IoT application hosted in IBM Bluemix. As you can see on the diagram, there are devices and gateways on the left, interacting with the Watson IoT Platform in the Cloud. From there, a dedicated bridge forwards the messages to Message Hub – a hosted Kafka offering in Bluemix. The data can flow from Message Hub to multiple other services, such as Stream Analytics, used for real-time processing of IoT event streams, or to Object Storage, which is ideal for long-term storage and batch analytics of historical data. Then the results of stream or batch analytics can be visualized in Jupyter Notebooks, which are part of the Data Science Experience offering. Of course, this is just an example, and there might be many other ways to ingest, process, store and analyze IoT data.
• #15: Now, how can we take advantage of OpenWhisk in such an architecture? Here are few ideas. A: we can use OpenWhisk to perform transformation on data-in-motion, before it is archived in Object Storage. For example, we could apply format conversion or indexing, to make the data in object storage more easily accessible for analytics. B: After the data is stored, OpenWhisk can be used for ETL-style processing, organizing it in different ways for analytics, or augmenting the data with other data sources. C: In stream analytics, OpenWhisk can be used to perform custom actions upon certain conditions detected by stream processing. For example, it could be used to trigger a feedback to the device, sent through the IoT Platform. And finally D: serverless functions can be useful at the edge, making it possible to handle the data-in-motion processing in a hollistics and unified way across the cloud and the edge.
• #16: Let’s explore in detail the first option – transformation of the data-in-motion before it is stored in Object Storage. The way it is implemented is by having two Kafka topics – the original topic used for messages arriving from the IoT Platform, and a new one, for transformed messages, which are then persisted in Object Storage, as usual. So, the “magic” happens between those two topics. In a nutshell – the idea is to define an OpenWhisk trigger that would be fired when a new batch of messages is available on the original topic, triggering the transformation action, which would also write to the destination topic. Now let’s explore the end-to-end flow in more detail.
• #17: Here you can see an illustration of the data flow in this example – starting from the sensor, to the gateway where it is aggregated and sent to the cloud, where it is augmented, transformed, organized and persisted.
• #18: The first part of the pipeline happens in Node-RED, which can be used to implement a Do-It-Yourself-style gateway. The ‘inject node’ triggers the flow at given intervals (e.g., every second). A sample event JSON is generated (by a custom ‘function node’). It is then aggregated using the ‘join’ node, compressed (using a custom function node), and sent to the Watson IoT Platform (using MQTT with properly configured orgId, device type, event type, device id and security token).
• #19: Then the Watson IoT Platform receives MQTT events from devices (after proper auth validation), augments them (e.g., adding timestamp and context metadata) and publishes in small batches to a Kafka topic (Message Hub).
• #20: The third, and the most interesting part happens in OpenWhisk, where the custom transformation happens. The Message Hub feed provider in OpenWhisk subscribes to messages in the iotp Kafka topic, aggregates small batches of messages and sends them as a payload to the OpenWhisk trigger, which in turn triggers a sequence of actions performing the message transformation and publishing the results to the transformed Kafka topic. You can see here the code in java-script implementing this action. It is rather simple, just 30 lines of code. Yet, the mechanism as a whole is extremely powerful, making it easy to apply any kind of custom transformation on the data.
• #21: Finally, the last part of the pipeline happens Message Hub, taking advantage of the bridge to Object Storage. It aggregates messages published to the transformed topic according to a specified policy (e.g., files of up to 1 hour or 1MB of data), and uploads the files to Object Storage according to the specified layout (e.g., applying date-based partitioning).
• #22: To summarize, in this example OpenWhisk is used as part of a IoT data processing pipeline – essentially as a stateless micro-service interacting with a persistent service (Kafka), triggered by changes in that service.
• #23: Now let’s take a look at a real-life architecture coming from Abilisense - a company that uses OpenWhisk in Bluemix. The essence of their solution is to monitor audio data collected using special hardware devices, to identify anomalies or certain “important” conditions, and to generate alerts (typically to a mobile phone). It is useful in several application domains, such as baby care, when you want to know that your baby is crying at night, or property care, when you want to know that, for example, some is making noises in your apartment while you are at work. The data collection is performed by the Abilisense device, shown at the upper-left side of the diagram. The devices sends audio data to object storage, and MQTT events to the Watson IoT Platform. These events trigger an OpenWhisk action, that orchestrates the processing workflow. In particular, it passes the data from object storage to a sound processing micro-service , that detects certain anomalies and conditions. If detected, OpenWhisk triggers a notification mechanism, which could send alerts back to the device, or to a mobile phone, or event contact authorities if their intervention is required. In addition, the sound data is continuously fed into a machine learning micro-service, which constantly improves the sound detection algorithms used in real-time. Moreover, OpenWhisk is used to pull in additional data sources which may affect the accuracy of the sound detection. For example, weather conditions – whether it is raining at a particular location. To summarize, OpenWhisk actions in this example are triggered by IoT events arriving from Abilisense devices, and are used primarily as a ‘glue’ between various micro-services which are part of the application itself, and also to call out to external services. Moreover, it is used as a mechanism to act upon certain conditions or anomalies detected by the business logic.
• #24: Now let’s try formalizing a bit the patterns around Serverless for the IoT.
• #25: We can identify 4 patterns capturing best practices of using Serverless or FaaS in IoT. #1: FaaS-based micro-services. Like with regular micro-services, the business logic of the application is decoupled into self-contained portions – but now the unit of deployment is a Function. Those Functions are triggered by IoT events, and the communication between them is also typically done using events. In many cases these are change events generated by persistent services, such as a data store used to maintain state of IoT devices. Pattern #2: FaaS can be used as a ‘glue’ integrating services in an event- or data-driven flow. You can notice certain similarity to the first pattern, but here the scope is not limited to data services keeping state of the IoT application. It could be pretty much any service accessible programmatically – such as speech recognition, visual analytics, or machine learning. Most of the business logic is captured in those services, and FaaS is used to integrate them together, in an agile, elastic and efficient manner. Pattern #3: FaaS can be used to act upon outstanding conditions in stream processing. For example, we could have a high-throughput stream of IoT events comprising the speed of cars on the road. Stream processing can be used to determine the number of cars in a certain road segment. If certain threshold is passed, FaaS can be used to trigger reconfiguration of traffic lights, to avoid traffic jam. This reconfiguration is even-driven, and if implemented as a regular long-running service, it would have been idle most of the time. The last pattern, #4, targets Edge environments, such as IoT gateways, rather than Cloud. Here, the business logic of the IoT application spans the cloud and the edge, and FaaS can be used to unify event-based processing capabilities. This pattern is the newest one, and there is lots of ongoing research to figure out how to do it right.
• #26: To summarize: FaaS platforms enable rapid development of loosely-coupled event-driven application - increasing agility, manageability, elasticity. OpenWhisk is a leading open source FaaS project, collaboratively developed by IBM and other vendors under the governance of the Apache Software Foundation. FaaS is a new field, so best practices and design patterns are still emerging – but there are several patterns that can be already identified for specific application domains, such as IoT. And we briefly discussed 4 such patterns.
• #28: That’s all for today, I will be happy to answer questions, and feel free to take a look and my blogs and presentations for further details.