Scaling Industrial Event-Driven Microservices with OpenWhisk
Dealing with IoT traffic
The Industrial IoT is real and it’s here. However, according to Andrei Yurkevich, CTO at Altoros, scaling out event-driven industrial IoT deployments may be an issue—both technically and financially.
He discussed this emerging world during a recent meetup in Silicon Valley, outlining the challenges that IoT and cloud-native apps bring in. He also described the requirements for a platform to develop scalable event-driven microservices and presented a demo app that connected mobile phones of several meetup attendees.
Andrei started with outlining the problems that may occur even when a company goes the microservices way. With IoT deployments, there are devices that send signals as well as devices that receive them. The amount and variety of devices can be enormous.
Andrei stressed that event-driven models are not limited to single, simple events. Rather, think of “multiple actions associated with one trigger,” in Andrei’s words.
Even with an intelligent use of containers, in which more than one process is put into a single container, there is a continuous need for invocation and termination of container (and therefore, server) instances. The need for instances can quickly escalate.
However, when the load goes down, what happens?
The company still needs to pay for excesive computation resources and terminate them as quickly as possible.
The requirements for an event-driven platform
So, how can operators be sure they always have enough compute available for IoT processes, without busting their budgets by vastly over-provisioning? Using a platform to create event-driven apps and services may be a solution. With this in mind, Andrei provided a list of requirements that need to be present in a tool like that:
According to Andrei, OpenWhisk is a platform that meets most of the above-mentioned requierments. It is one of the ways for developers to get a handle on how to design, deploy, and manage what should be an increasing number of event-driven apps and services.
In the traditional model, apps (and services) are deemed to be “on” continuously once they’ve been launched. In contrast, an IoT sensor is likely to be sending out a very short, periodic signal. With millisecond billing in place by the cloud provider, OpenWhisk is only using the time needed for that periodic signal. Thus, a microservice is charged only for the time it’s in actual use, which might be 50 to 100 milliseconds per minute.
Andrei outlined potential concerns enterprises might have about using OpenWhisk, such as vendor lock-in, but then pointed out the use of IBM Bluemix is not a strict requirement. OpenWhisk is an open-source platform, and there is a GitHub repository addressing these issues. As with Cloud Foundry, it is open, with individuals and companies encouraged to participate, explore, and move the needle.
(For more on using OpenWhisk outside IBM Bluemix in a local environment, read our tutorial at DeveloperWorks.)
The sound of one phone clapping
To show the platform in action, Andrei gave an amusing but instructive demo of a “Clap-o-Meter” app. It was built with OpenWhisk and induced a clicking noise from connected mobile phones in the room. He started with the sound of his phone “clapping.” Then, with several people downloading the app on-site and initiating the app (i.e., creating an event to invoke it), simulated applause rippled throughout the room. Bravo!
Andrei also stressed the relative simplicity of building event-driven apps and services through the use of Node-RED. He then provided an abstracted diagram of how his magic Clap-o-Meter worked:
Here’s the Clap-o-Meter app itself. The demo starts at 12’05” in the video below, followed by some technical Q&A.
Want details? Watch the video!
- Event-Driven Microservices with OpenWhisk: Comparison to Traditional Models
- Reducing Complexity of Software with Domain-Driven Design and Microservices
- IBM Bluemix OpenWhisk 101: Developing a Microservice
- How to Use OpenWhisk Docker Actions in IBM Bluemix