Watson Service Chaining via OpenWhisk Sequence : Part 1 of 3
This 3-part series of posts helps you understand the in-depth features of Serverless Computing via OpenWhisk. OpenWhisk offers an easy way to chain services where an output of 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 an 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
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 by using an internet browser 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.
Install the below software on your machine
Let’s start with some basics of Serverless computing
Serverless computing refers to a model where the existence of servers is simply hidden from developers. I.e. that even though servers still exist developers are relieved from the need to care about their operation. They are relieved from 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 if 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 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.
- OpenWhisk hides infrastructural complexity allowing developers to focus on business logic.
- OpenWhisk takes care of low-level details such as scaling, load balancing, logging, fault tolerance, and message queues.
- OpenWhisk provides a rich ecosystem of building blocks from various domains (analytics, cognitive, data, IoT, etc.).
- OpenWhisk is open and designed to support an open community.
- OpenWhisk supports an open ecosystem that allows sharing microservices via OpenWhisk packages.
- OpenWhisk allows developers to compose solutions using modern abstractions and chaining.
- OpenWhisk supports multiple runtimes including NodeJS, Swift, and arbitrary binary programs encapsulate in Docker containers.
- OpenWhisk charges only for code that runs.
The OpenWhisk model consists of three concepts:
- trigger, a class of events that can happen,
- 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.
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.
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.
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, such as devices, queues, databases, and webhooks, emit classes of events in the form of triggers.
Triggers are the class of events (including device readings, published messages, and data changes) that are emitted by event sources.
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 represent the declarative association between a trigger and an action, defining which action(s) should be executed in response to an event.
Packages encapsulate external services in a reusable manner and assemble them into triggers and actions.
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.
If you are curious to know the role of each building block, read this article by fellow IBMer “Uncovering the magic: How serverless platforms really work!”
Also, there’s a curated list of awesome OpenWhisk things
In part-2, you will be creating Watson services on IBM Bluemix and adding them to an OpenWhisk sequence.