Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.

This three-part series will help you understand the in-depth features of Serverless Computing via OpenWhisk. OpenWhisk offers an easy way to chain services where an output of the first action acts as an input to the second action and so on in a sequence.

OpenWhisk achieves the chaining of services via sequences on Bluemix. By the end of Part 3, You will be chaining Watson services and exposing the sequence as a REST API via OpenWhisk API Gateway.

This post describes the resource requirements for performing this lab. The two sub-sections are:

Bluemix account

Locally installed software

Bluemix Account

If you already have a Bluemix account, you can use that to perform this lab if it meets the following requirements:

2 GB memory for Cloud Foundry Apps

10 Services and APIs allowed

If you do not have a Bluemix account, you can register for a free trial account by performing the following steps.

Browse to http://bluemix.net and click the Sign Up link.

At the "Sign up for IBM Bluemix" page, enter the required information and click CREATE ACCOUNT.

Note: Since the sign-up process requires you to validate your email address, please use an email account that you can access right now.

Validate your email address when you receive an email from bluemix.net.

Prerequisites

What Is Serverless Computing?

Serverless computing refers to a model where the existence of servers is simply hidden from developers. Even though servers still exist, developers are relieved of the need to care about their operation. They are relieved of the need to worry about low-level infrastructural and operational details such as scalability, high-availability, infrastructure security, and so forth. Hence, serverless computing is essentially about reducing maintenance efforts to allow developers to quickly focus on developing value-adding code.

Serverless computing encourages and simplifies developing microservice-oriented solutions in order to decompose complex applications into small and independent modules that can be easily exchanged.

Serverless computing does not refer to a specific technology; instead it refers to the concepts underlying the model described prior. Nevertheless, some promising solutions have recently emerged easing development approaches that follow the serverless model – such as OpenWhisk.

OpenWhisk Basic Concepts

OpenWhisk is an event-driven compute platform also referred to as Serverless computing or as Function as a Service (FaaS) that runs code in response to events or direct invocations.

How OpenWhisk Works

Action: an event handler — some code that runs in response to an event, and

Rule: an association between a trigger and an action.

The following figure shows the high-level OpenWhisk architecture.

High-level OpenWhisk architecture

Examples of events include changes to database records, IoT sensor readings that exceed a certain temperature, new code commits to a GitHub repository, or simple HTTP requests from web or mobile apps. Events from external and internal event sources are channeled through a trigger, and rules allow actions to react to these events.

Actions can be small snippets of JavaScript or Swift code, or custom binary code embedded in a Docker container. Actions in OpenWhisk are instantly deployed and

executed whenever a trigger fires. The more triggers fire, the more actions get invoked. If no trigger fires, no action code is running, so there is no cost.

In addition to associating actions with triggers, it is possible to directly invoke an action by using the OpenWhisk API, CLI, or iOS SDK. A set of actions can also be chained without having to write any code. Each action in the chain is invoked in sequence with the output of one action passed as input to the next in the sequence. With traditional long-running virtual machines or containers, it is common practice to deploy multiple VMs or containers to be resilient against outages of a single instance. However, OpenWhisk offers an alternative model with no resiliency-related cost overhead. The on-demand execution of actions provides inherent scalability and optimal utilization as the number of running actions always matches the trigger rate. Additionally, the developer now only focuses on code and does not worry about monitoring, patching, and securing the underlying server, storage, network, and operating system infrastructure.

Integrations with additional services and event providers can be added with packages. A package is a bundle of feeds and actions. A feed is a piece of code that configures an external event source to fire trigger events. For example, a trigger that is created with a Cloudant change feed will configure a service to fire the trigger every time a document is modified or added to a Cloudant database. Actions in packages represent reusable logic that a service provider can make available so that developers not only can use the service as an event source, but also can invoke APIs of that service.

An existing catalog of packages offers a quick way to enhance applications with useful capabilities, and to access external services in the ecosystem. Examples of external services that are OpenWhisk-enabled include Cloudant, The Weather Company, Slack, and GitHub.

High-Level Programming Model

High-level programming model of OpenWhisk

As mentioned above, OpenWhisk is an open source, distributed serverless computing platform able to execute application logic (Actions) in response to events (Triggers) from external sources (Feeds) or HTTP requests governed by conditional logic (Rules). It provides a programming environment supported by a REST API-based Command Line Interface (CLI) along with tooling to support packaging and catalog services.

Event Sources

Event sources, such as devices, queues, databases, and webhooks, emit classes of events in the form of triggers.

Triggers

Triggers are the class of events (including device readings, published messages, and data changes) that are emitted by event sources.

Actions

Actions are functions that encapsulate code – written in any supported language by implementing a single method signature – to be executed in response to a trigger.

Rules

Rules represent the declarative association between a trigger and an action, defining which action(s) should be executed in response to an event.

Packages

Packages encapsulate external services in a reusable manner and assemble them into triggers and actions.

Deep Dive into OpenWhisk Architecture: The Building Blocks

Building Block of OpenWhisk

The following diagram depicts the building blocks of OpenWhisk showing what happens behind the scenes. From Nginx to Kafka to Docker, multiple technologies are powering this serverless platform.

Just want to park this post here. If we start digging more in-depth, it takes a while to digest and we won’t be able to build our intended code sample leveraging the concept of Sequences.