What serverless is good for: From serverless & mobile backends to data-, streaming-, cognitive-, IoT-, and conversational scenarios

Part 1: Overview of selected scenarios

Serverless approaches can be considered to add value in many different scenarios. In this article we are going to review some of them and how these could be implemented by using OpenWhisk.

Serverless (microservice) backends

Serverless architectures allow to expose functions, which can be seen as flexible and independently deployable microservices, to build up serverless backends that expose application logic via well defined APIs. Such functions may, for instance, create, read, update, or delete persistently stored data.

In this context API Gateways allow to map API endpoints (i.e. URLs) to such functions (e.g. OpenWhisk actions) to make them easily consumable by clients — just as explained here.

Mobile backends

Mobile applications often require server-side logic, too.
Sometimes they simply need to access some server-side APIs, sometimes they need to access and work with centrally stored data. In addition, they often need to outsource more compute-intensive tasks to a scalable cloud platform.

But usually mobile developers are experts in developing mobile applications rather than in developing server-side logic.

OpenWhisk allows mobile developers to focus on developing the actual mobile application while, at the same time, making it easy to consume server-side logic that may have been implemented by others. This logic can be implemented as OpenWhisk actions that can optionally be exposed via an API gateway — again, as explained here.

Since OpenWhisk actions can also be implemented in Swift even mobile developers are enabled to quickly develop simple server-side logic without the need to learn something new.

Finally, to make the consumption of such actions even easier (IBM Bluemix) OpenWhisk also provides mobile developers with SDKs, e.g. one for iOS.

Data processing

In data processing scenarios data is being stored in a database, like e.g. IBM Cloudant, which may cause a trigger to be fired which may then cause an action — supposed to operate on that data — to be executed.

In this context data may be multimedia data like audio-, image- or video data. The action could then be responsible for operations like:

• Audio normalization
• Image rotation, sharpening, or noise reduction
• Thumbnails generation
• Video transcoding

Cognitive data processing

In cognitive scenarios, which represent a special form of the data processing discussed prior, data is, similar than before, persistently stored. Again, this may cause a trigger to be fired which cause then an action to be executed.

In a cognitive scenario the said action could call cognitive services like IBM’s Watson services, for instance to detect objects or persons appearing in images:

Event-/stream processing

The same way as there is a need to process data at-rest, i.e. data that has been persistently stored in databases as discussed before, there is a need to process data in-motion, i.e. streaming data. In this context data arriving at a message bus, may cause a trigger to be fired which may cause an action to be invoked to process the data by executing custom application logic.

Therefore, Apache OpenWhisk provides A native Apache Kafka integration. IBM Bluemix OpenWhisk provides a IBM Message Hub integration, which simply is a managed Apache Kafka.

IoT scenarios

In IoT scenarios it is all about processing IoT sensor data which obviously is, due to its event-driven character, another interesting scenario in the context of serverless computing.

But usually one does not do want call a single function (e.g. an OpenWhisk action) for each single datapoint that has been sensed — simply because this would cause unnecessary cost.

Hence, in the context of (IBM Bluemix) OpenWhisk, this is what is normally been done:

1. Sensor data is pushed to IBM’s Watson IoT platform.
2. Here, Cloud Analytics allows to model rule conditions that are based on said data and that trigger alerts and optional actions when met. For instance, such a rule may trigger an alert or action if multiple temperature sensors report a temperature highter than 100 degrees which may indicate fire.
3. Cloud Analytics may then call an OpenWhisk action via a webhook
4. The action may then execute — once again — custom application logic, e.g. to set off a fire alarm, to activate the sprinkler system, or to notify the fire department.

For OpenWhisk a NodeRED integration is also available. Node-RED is a programming tool for wiring together hardware devices, APIs and online services. It provides a browser-based editor that makes it easy to wire together flows using the wide range of nodes that can be deployed to its runtime in a single-click.

NodeRED is a modeling tool very often used in the IoT space to define a control flow. OpenWhisk nodes allow to execute OpenWhisk actions as part of these flows.

Conversational scenarios

Conversational applications, like chatbots, can also be implemented by pursuing serverless approaches.

For instance, messages entered into a messaging application like Slack could be forwarded to a serverless function (e.g. an OpenWhisk action) being exposed via a well-defined API endpoint. The message could then be processed by the function (i.e. the OpenWhisk action) which could then respond by calling an well-defined API endpoint the messaging application provides.

Such an action could easily make use of some cognitive services like IBM Watson to allow for sophisticated conversations.

Scheduled tasks

Finally, functions (e.g. OpenWhisk actions) can also be executed periodically, i.e. on a scheduled basis. OpenWhisk supports a cron-alike syntax to define when actions are supposed to be executed.

The above described scenarios are not meant to be a complete list of all scenarios serverless approaches fit to; instead, they are a sub-selection meant to inspire you. Let me know in case you see other cool scenarios that should be added & described as part of a future article.

In part 2 of this article series we will review some trivial (code) samples for each of the above mentioned scenarios; in part 3 we will review some real-world customer samples..

Related presentation: