Learning Apache OpenWhisk Developing Open Serverless Solutions 1st Edition Michele Sciabarrà

Learning Apache OpenWhisk Developing Open
Serverless Solutions 1st Edition Michele
Sciabarrà download
https://textbookfull.com/product/learning-apache-openwhisk-
developing-open-serverless-solutions-1st-edition-michele-
sciabarra/
Download more ebook from https://textbookfull.com

We believe these products will be a great fit for you. Click
the link to download now, or visit textbookfull.com
to discover even more!
Serverless Development on AWS: Building Enterprise-
Scale Serverless Solutions 1st Edition Sheen Brisals
https://textbookfull.com/product/serverless-development-on-aws-
building-enterprise-scale-serverless-solutions-1st-edition-sheen-
brisals/
Learning Apache Kafka, Second Edition Nishant Garg
https://textbookfull.com/product/learning-apache-kafka-second-
edition-nishant-garg/
Mastering Azure Serverless Computing Design and
Implement End to End Highly Scalable Azure Serverless
Solutions with Ease 1st Edition Abhishek Mishra
https://textbookfull.com/product/mastering-azure-serverless-
computing-design-and-implement-end-to-end-highly-scalable-azure-
serverless-solutions-with-ease-1st-edition-abhishek-mishra/
Beginning Serverless Computing: Developing with Amazon
Web Services, Microsoft Azure, and Google Cloud 1st
Edition Maddie Stigler
https://textbookfull.com/product/beginning-serverless-computing-
developing-with-amazon-web-services-microsoft-azure-and-google-
cloud-1st-edition-maddie-stigler/

AI as a Service: Serverless machine learning with AWS
1st Edition Peter Elger
https://textbookfull.com/product/ai-as-a-service-serverless-
machine-learning-with-aws-1st-edition-peter-elger/
Radical Solutions and Open Science An Open Approach to
Boost Higher Education Daniel Burgos
https://textbookfull.com/product/radical-solutions-and-open-
science-an-open-approach-to-boost-higher-education-daniel-burgos/
Learning Apache Drill Query and Analyze Distributed
Data Sources with SQL 1st Edition Charles Givre
https://textbookfull.com/product/learning-apache-drill-query-and-
analyze-distributed-data-sources-with-sql-1st-edition-charles-
givre/
Jorah The Brinnswick Chronicles IV 1st Edition Michele
Notaro Notaro Michele
https://textbookfull.com/product/jorah-the-brinnswick-chronicles-
iv-1st-edition-michele-notaro-notaro-michele/
Learning Advanced Python by Studying Open Source
Projects 1st Edition Li
https://textbookfull.com/product/learning-advanced-python-by-
studying-open-source-projects-1st-edition-li/

Learning Apache OpenWhisk
Developing Open Source Serverless Solutions
Michele Sciabarrà

Learning Apache OpenWhisk
by Michele Sciabarrà
Copyright © 2019 Michele Sciabarrà. All rights reserved.
Printed in the United States of America.
Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North,
Sebastopol, CA 95472.
O’Reilly books may be purchased for educational, business, or sales
promotional use. Online editions are also available for most titles
(http://oreilly.com). For more information, contact our
corporate/institutional sales department: 800-998-9938 or
corporate@oreilly.com.
Editors: Virginia Wilson and John Devins
Production Editor: Nan Barber
Copyeditor: Christina Edwards
Proofreader: Rachel Head
Indexer: Ellen Troutman-Zaig
Interior Designer: David Futato
Cover Designer: Karen Montgomery
Illustrator: Rebecca Demarest
July 2019: First Edition
Revision History for the First Edition
2019-07-01: First Release

See http://oreilly.com/catalog/errata.csp?isbn=9781492046165 for
release details.
The O’Reilly logo is a registered trademark of O’Reilly Media, Inc.
Learning Apache OpenWhisk, the cover image, and related trade
dress are trademarks of O’Reilly Media, Inc.
The views expressed in this work are those of the author, and do not
represent the publisher’s views. While the publisher and the author
have used good faith efforts to ensure that the information and
instructions contained in this work are accurate, the publisher and
the author disclaim all responsibility for errors or omissions,
including without limitation responsibility for damages resulting from
the use of or reliance on this work. Use of the information and
instructions contained in this work is at your own risk. If any code
samples or other technology this work contains or describes is
subject to open source licenses or the intellectual property rights of
others, it is your responsibility to ensure that your use thereof
complies with such licenses and/or rights.
978-1-492-04616-5
[LSI]

Foreword
Amazon Web Services changed the cloud computing landscape in
November of 2014 when it launched a new service called Lambda. It
offered developers the intriguing possibility of processing thousands
of events concurrently, simply by registering functions as event
handlers. With Lambda, functions execute on-demand and scale
instantly and costs are proportional to actual resource utilization.
This new model of computing was dubbed “serverless” because it let
developers eschew all aspects of server-side development and
operations—including infrastructure management, resource
provisioning, and scaling.
Amazon showed that in the era of managed infrastructure and
services, cloud providers can free developers from low-level
operational burdens and let them focus on what matters most:
delivering real business value to their organizations. Serverless
computing is the foundation of a cloud-native transformation that is
ongoing in the industry. It is the way cloud applications are being
built and will largely be built in the future. There are now more than
a trillion functions processed every month on Amazon alone for a
wide variety of applications from IoT, web applications, machine
learning, and high-performance computing.
At IBM Research, my group took notice of the Lambda
announcement, and we quickly realized the value of the serverless
promise. So in February 2015, we set out to build a serverless
platform for the IBM Cloud. The project was code-named Whisk, as
in “to move nimbly and quickly.” It was later branded OpenWhisk
when we open-sourced the code to GitHub, nearly a year to the day
from our first commit. Today, the project is part of the Apache
Software Foundation Incubator and it’s the premiere open-source
alternative to Amazon’s Lambda. Apache OpenWhisk is ready for
Enterprise workloads and offers a powerful programming model for
building entire serverless applications. It powers serverless product
offerings from IBM and Adobe, and it’s used in private deployments

in some of Asia’s largest mobile and internet providers. The Apache
OpenWhisk community consists of more than 215 contributors from
around the world, and is among the top 30 Apache Foundation
projects ranked by their GitHub stars. Many of the top OpenWhisk
contributors are now also shaping the future of other emerging
serverless platforms such as Google’s Knative project, which aims to
bring a serverless experience to the increasingly popular Kubernetes
platform.
In this book, Michele Sciabarrà delivers a thorough exposition of
Apache OpenWhisk tailored to the needs of developers and
operators. For developers eager to adopt a serverless methodology,
this book explains the emerging computational patterns and current
limitations. It also illustrates several examples of applying the
technology to solve real-world challenges. For operators who want to
deliver a serverless experience for their organizations, Michele
carefully reveals the OpenWhisk architecture, and provides a go-to
guide for deployment and operations, particularly for a Kubernetes-
based deployment.
Michele draws on his own contributions to the Apache OpenWhisk
project in writing this book. His work has dramatically improved the
performance of serverless functions developed in Go, PHP, Python,
Swift, and more. His insightful and practical approach is well-suited
to the developer who wants get up to speed quickly in harnessing
the power of serverless computing.
For those of us at the frontier of the serverless journey, there is no
doubt that we are witnessing the dawn of a new Cloud Computer,
with functions at the cornerstone of a new instruction set
architecture. This model of computing is powerful and disruptive,
and yet much work remains to be done. History has shown that as
new computer abstractions emerge, innovation follows.
Rodric Rabbah
CTO and Cofounder Nimbella Corporation

Preface
This book is for developers who want to learn to use Apache
OpenWhisk, a mature, multilanguage, serverless development
platform. It provides the knowledge needed to build complex, well-
structured, polyglot serverless applications that can be deployed in
any cloud or even on-premises.
Why Serverless?
For a long time, companies built their own data centers and bought
hardware to install their web applications, mobile backends, or data
processing pipelines. But the high costs of building and maintaining
data centers eventually led to people renting servers from third
parties to reduce costs. Servers are frequently partitioned to “virtual
machines,” allowing businesses to pay only for what they need (as
opposed to renting a whole server). Eventually, this concept evolved
into what today we generically call “the cloud.” The cloud at its core
is mostly a “server on demand” service. Modern cloud providers offer
a wide range of services but have also become increasingly complex.
In particular, one source of this complexity is the need to provision
and manage servers. Servers are cattle not easy to raise. They
require continuous care and control and must be monitored,
cleaned, updated, and occasionally destroyed and rebuilt. Like cattle,
they also tend to grow and multiply quickly.
Developers want to forget the server (“serverless”) and develop their
application as native citizen of the cloud (“cloud-native”). The focus
here is to push the burden of managing the servers onto the
shoulders of a platform deployed in the cloud. Most software
developers want to upload their code and immediately have it up
and running.
As a result, all the major cloud providers now offer some form of
Function as a Service that hides the servers and only needs the code

to run—in short, a way to use their cloud serverless.
Why Apache OpenWhisk?
Serverless computing was pioneered by Amazon Web Services
(AWS), with its Lambda service. Amazon Lambda is, as you might
expect, highly tailored to the AWS offering. However, serverless
computing is not (and cannot be) limited to one cloud provider. As a
natural consequence, some open source serverless projects have
emerged. Today, there are many available platforms for serverless
computing, which can run in multiple clouds. The focus of this book
is one of those: Apache OpenWhisk.
Apache OpenWhisk was originally developed by IBM but its code
base was later donated to the Apache Software Foundation and
released under a commercially friendly open source license, the
Apache License 2.0. This makes it “seriously” open source, free of
commercial limitations, friendly to commercial ventures adopting it,
and maintained in the long run.
Because any Apache project has to have a working code base as
well as an active community, adopters of Apache software can trust
they will not be alone in using it. Also, Apache-supported software
has a detailed list of compliance rules allowing everyone to use the
released software without risking getting caught in the
“noncommercial” traps that some other open source licenses have.
In addition to those advantages of being an Apache project,
OpenWhisk is used in production and powers the cloud functions of
the IBM Cloud as well as Adobe’s I/O runtime cloud services. Apache
OpenWhisk also supports many programming languages, including
Node.js, Python, Java, Go, Swift, PHP, and Ruby. More languages are
also in the works. In short, it is a stable and sophisticated
production-ready serverless platform.
What You Will Learn
This book is for developers, so you need to be familiar with coding
and programming languages. The book is split into two parts—the

first part is introductory and the other more advanced.
In the first part, I assume you only know the JavaScript
programming language and the basics of web development, like
HTML. I do not assume you have experience in serverless
development.
In this section you will learn how to create OpenWhisk applications
from scratch. After exploring the OpenWhisk architecture, we will
create a simple contact form for a static website.
Then we’ll explore the CLI and API of OpenWhisk and rebuild the
same application in a highly engineered way, splitting it into
cooperating actions and applying a bunch of design patterns. You
will learn about the building blocks you need to develop your
applications along with examples and best practices.
In this book we emphasize the importance of testing, so the first
part ends with a chapter entirely devoted to unit testing, mocking,
and snapshot testing.
The second part of the book is more advanced, and here I assume
you know more programming languages. Two chapters in the second
part use Python for coding examples, and another two chapters use
Go. We’ll discuss the peculiarities of developing OpenWhisk
applications in those programming languages.
In the second part we’ll also explore integration with essential
external services such as databases (CouchDB) and messaging
queues (Kafka). Last but not least, the final chapter covers installing
OpenWhisk in Kubernetes, including the installation of Kubernetes
itself. This last chapter is more oriented to system administrators but
could also be helpful for those unfamiliar with Linux because it
provides step-by-step installation instructions.

Conventions Used in This Book
The following typographical conventions are used in this book:
Italic
Indicates new terms, URLs, email addresses, filenames, and file
extensions.
Constant width
Used for program listings, as well as within paragraphs to refer to
program elements such as variable or function names, databases,
data types, environment variables, statements, and keywords.
Constant width bold
Shows commands or other text that should be typed literally by
the user.
Constant width italic
Shows text that should be replaced with user-supplied values or
by values determined by context.
TIP
This element signifies a tip or suggestion.
NOTE
This element signifies a general note.
WARNING
This element indicates a warning or caution.

Using Code Examples
Supplemental material (code examples, exercises, etc.) is available
for download at https://learning-apache-openwhisk.github.io.
This book is here to help you get your job done. In general, if
example code is offered with this book, you may use it in your
programs and documentation. You do not need to contact us for
permission unless you’re reproducing a significant portion of the
code. For example, writing a program that uses several chunks of
code from this book does not require permission. Selling or
distributing a CD-ROM of examples from O’Reilly books does require
permission. Answering a question by citing this book and quoting
example code does not require permission. Incorporating a
significant amount of example code from this book into your
product’s documentation does require permission.
We appreciate, but do not require, attribution. An attribution usually
includes the title, author, publisher, and ISBN. For example:
“Learning Apache OpenWhisk by Michele Sciabarrà (O’Reilly).
Copyright 2019 Michele Sciabarrà, 978-1-492-04616-5.”
If you feel your use of code examples falls outside fair use or the
permission given above, feel free to contact us at
permissions@oreilly.com.
O’Reilly Online Learning
NOTE
For almost 40 years, O’Reilly Media has provided technology and business
training, knowledge, and insight to help companies succeed.
Our unique network of experts and innovators share their knowledge
and expertise through books, articles, conferences, and our online

learning platform. O’Reilly’s online learning platform gives you on-
demand access to live training courses, in-depth learning paths,
interactive coding environments, and a vast collection of text and
video from O’Reilly and 200+ other publishers. For more information,
please visit http://oreilly.com.
How to Contact Us
Please address comments and questions concerning this book to the
publisher:
O’Reilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
800-998-9938 (in the United States or Canada)
707-829-0515 (international or local)
707-829-0104 (fax)
We have a web page for this book, where we list errata, examples,
and any additional information. You can access this page at
http://bit.ly/learn-apache-openwhisk.
To comment or ask technical questions about this book, send email
to bookquestions@oreilly.com.
For more information about our books, courses, conferences, and
news, see our website at http://www.oreilly.com.
Find us on Facebook: http://facebook.com/oreilly
Follow us on Twitter: http://twitter.com/oreillymedia
Watch us on YouTube: http://www.youtube.com/oreillymedia

Acknowledgments
I want to say thank you to Rodric Rabbah and Carlos Santana for
their support and mentoring. If it were not for them, all I would
have ended up with is the single line of code I submitted to fix the
Vagrant build on Windows, my first contribution to the OpenWhisk
project. Instead, thanks to their support and encouragement, I built
a new action proxy that now powers multiple OpenWhisk runtimes,
and I ended up writing a book on Apache OpenWhisk.
I also want to thank the reviewers. Carlos and Rodric, of course,
were the first to review my early chapters, but Rob Allen, Dragos
Dascalita, and Vincent Hou, also provided invaluable suggestions to
improve my writing and correct the errors they saw.
Last but not least, I want to thank some members of the Apache
community involved with the OpenWhisk project: Dave Grove, Justin
Halsall, James Thomas, Markus Thömmes, Matt Rutkowski, Priti
Desai, and all the others I’ve forgotten to name here.

Part I. Introducing
OpenWhisk Development
In this first part, you are going to learn how to develop OpenWhisk
applications. We’ll start with the architecture of the system and the
CLI. Then you will use the JavaScript API, debugging techniques,
and design patterns developed specifically in JavaScript.
JavaScript is undoubtedly one of the most important and widely
used programming languages available. It is also the most common
language used by frontend developers, those who may need to add
backend logic and don’t want to deal with the complexities of
managing servers. Most people that use OpenWhisk usually start
with JavaScript to keep things simple.
To hit the ground running, we’ll start by developing a simple form
application. Once you know the basics, we will rewrite the
application using design patterns. We’ll also cover unit testing and
“mocking,” used to test software that runs in the cloud.

Chapter 1. Serverless and
OpenWhisk Architecture
Welcome to the world of Apache OpenWhisk, an open source
serverless platform designed to make it simple to develop
applications in the cloud. The project was developed in the open by
the Apache Software Foundation, so the correct name is “Apache
OpenWhisk,” but for simplicity we’ll use “OpenWhisk” throughout.
Note that “serverless” does not mean “without a server”—it means
“without managing the server.” Indeed, we will learn how to build
complex applications without being concerned with installing and
configuring the servers to run the code; we only have to deal with
the servers when we first deploy the platform.
A serverless environment is most suitable for applications needing
processing “in the cloud” because it allows you to split your
application into multiple simpler services. This approach is often
referred to as a “microservices” architecture.
To begin with, we will take a look at the architecture of OpenWhisk
to understand its strengths and weaknesses. After that we’ll discuss
the architecture itself, focusing on the serverless model to show you
what it can and cannot do.
We’ll wrap up this chapter by comparing OpenWhisk with another
widely used similar architecture, Java EE. The problems previously
solved by Java EE application servers can now be solved by
serverless environments, only at a greater scale (even hundreds of
servers) and with more flexibility (not just with Java, but with many
other programming languages).

TIP
Since the project is active, new features are added almost daily. Be sure to
check the book’s website for important updates and corrections.
OpenWhisk Architecture
Apache OpenWhisk, as shown in Figure 1-1, is a serverless open
source cloud platform. It works by executing functions (called
actions) in response to events. Events can originate from multiple
sources, including timers, databases, message queues, or websites
like Slack or GitHub.
OpenWhisk accepts source code as input that provisions executing a
single command with a command-line interface (CLI), and then
delivers services through the web to multiple consumers, such as
other websites, mobile applications, or services based on REST APIs.
Figure 1-1. How Apache OpenWhisk works

Functions and Events
OpenWhisk completes its tasks using functions. A function is typically
a piece of code that receives some input and provides an output in
response. It is important to note that a function is generally
expected to be stateless.
Backend web applications are stateful. Just think of a shopping cart
application for e-commerce: while you navigate the website, you add
your items to the basket to buy them at the end. You keep a state,
which is the contents of the cart.
But being stateful is expensive; it limits scalability because you need
a place to store your data. Most importantly, you will need
something to synchronize the state between invocations. When your
load increases, this “state-keeping” infrastructure will limit your
ability to grow. If you are stateless, you can usually add more
servers because you do not have the housekeeping of keeping the
state in sync among the servers, which is complex, expensive, and
has limits.
In OpenWhisk, and in serverless environments in general, the
functions must be stateless. In a serverless environment you can
keep state, but not at the level of a single function. You have to use
some special storage that is designed for high scalability. As we will
see later, you can use a NoSQL database for this.
The OpenWhisk environment manages the infrastructure, waiting for
something important to occur. This something important is called an
event. Only when an event happens a function is invoked.
Event processing is actually the most important operation the
serverless environment manages. We will discuss in detail next how
this happens. Developers want to write code that responds correctly
when something happens—e.g., a request from the user or the
arrival of new data—and processes the event quickly. The rest
belongs to the cloud environment.

In conclusion, serverless environments allow you to build your
application out of simple stateless functions, or actions as they are
called in the context of OpenWhisk, that are triggered by events. We
will see later in this chapter what other constraints those actions
must satisfy.
Architecture Overview
Now that we know what OpenWhisk is and what it does, let’s take a
look at how it works under the hood. Figure 1-2 provides a high-
level overview.
Figure 1-2. An example deployment with actions in multiple languages
In Figure 1-2, the big container in the center is OpenWhisk itself. It
acts as a container of actions. We will learn more about the

container and these actions shortly, but as you can see, actions can
be developed in many programming languages. Next, we’ll discuss
the various options available.
NOTE
The “container” schedules the actions, creating and destroying them as needed
needed, and it will also scale them, creating duplicates in response to an
increase in load.
Programming Languages for OpenWhisk
You can write actions in many programming languages. Typically,
interpreted programming languages are used, such as JavaScript
(actually, Node.js), Python, or PHP. These programming languages
give immediate feedback because you can execute them without a
compilation step. While these are higher-level languages and are
easier to use, they are also slower than compiled languages. Since
OpenWhisk is a highly responsive system (you can immediately run
your code in the cloud), most developers prefer to use those
interpreted languages as their use is more interactive.
TIP
While JavaScript is the most widely used language for OpenWhisk, other
languages can also be used without issue.
In addition to purely interpreted (or more correctly, compiled-on-the-
fly) languages, you can also use the precompiled interpreted
languages in the Java family such as Java, Scala, and Kotlin. These
languages run on the Java Virtual Machine (JVM) and are distributed
in an intermediate form. This means you have to create a .jar file to
run your action. This file includes the so-called “bytecode”

OpenWhisk executes when it is deployed. A JVM actually executes
the action.
Finally, in OpenWhisk you can use compiled languages. These
languages use a binary executable that runs on “bare metal” without
interpreters or virtual machines (VMs). These binary languages
include Swift, Go, and the classic C/C++. Currently, OpenWhisk
supports Go and Swift out of the box. However, you can use any
other compiled programming language as long as you can compile
the code in Linux elf format for the amd64 processor architecture. In
fact, you can use any language or system that you can package as a
Docker image and publish on Docker Hub: OpenWhisk is able to
retrieve this type of image and run it, as long as you follow its
conventions.
NOTE
Each release of OpenWhisk includes a set of runtimes for specific versions of
programming languages. For the released combinations of programming
languages and versions, you can deploy actions using the switch --kind on the
command line (e.g., --kind nodejs:6 or --kind go:1.11). For single file
actions, OpenWhisk will select a default runtime to use based on the extension
of the file. You can find more runtimes for programming languages or versions
not yet released on Docker Hub that can be used with the switch --docker
followed by the image name.
Actions and Action Composition
OpenWhisk applications are collections of actions. Figure 1-3 shows
how they are assembled to build applications.

Figure 1-3. Overview of OpenWhisk action runtimes
An action is a piece of code, written in one of the supported
programming languages (or even an unsupported language, as long
as you can produce an executable and package it in a Docker
image), that you can invoke. On invocation, the action will receive
some information as input.
To standardize parameter passing among multiple programming
languages, OpenWhisk uses the widely supported JavaScript Object
Notation (JSON) format, because it’s pretty simple and there are
libraries to encode and decode this format available for basically
every programming language.
The parameters are passed to actions as JSON objects serialized as
strings that the action receives when it starts and is expected to
process. At the end of the processing, each action must produce a
result, which is returned as a JSON object value.

You can group actions in packages. A package is a unit of
distribution. You can share a package with others using bindings.
You can also customize a package, providing parameters that are
different for each binding.
Action Chaining
Actions can be combined in many ways. The simplest way is
chaining them into sequences.
Chained actions use as input the output of the preceding actions. Of
course, the first action of a sequence will receive the parameters (in
JSON format), and the last action of the sequence will produce the
final result as a JSON string. However, since not all the flows can be
implemented as a linear pipeline of input and output, there is also a
way to split the flows of an action into multiple directions. This
feature is implemented using triggers and rules. A trigger is merely a
named invocation. By itself a trigger does nothing. However, you can
associate the trigger with one or more actions using rules. Once you
have created the trigger and associated some action with it, you can
fire the trigger by providing parameters.
NOTE
Triggers cannot be part of a package. but they can be part of a namespace, as
we’ll see in Chapter 3.
The actions used to fire a trigger are called a feed and must follow
an implementation pattern. In particular, as we will learn in
“Observer”, actions must implement an Observer pattern and be able
to activate a trigger when an event happens.
When you create an action that follows the Observer pattern (which
can be implemented in many different ways), you can mark the
action as a feed in a package. You can then combine a trigger and a

feed when you deploy the application, to use a feed as a source of
events for a trigger (and in turn activate other actions).
How OpenWhisk Works
Now that you know the different components of OpenWhisk, let’s
look at how OpenWhisk executes an action.
The process is straightforward for the end user, but internally it
executes several steps. We saw before the user visible components
of OpenWhisk. We are now going to look under the hood and learn
about the internal components. Those components are not visible by
the user but the knowledge of how it works is critical to use
OpenWhisk correctly. OpenWhisk is “built on the shoulders of
giants,” and it uses some widely known and well-developed open
source projects.
These include:
Nginx
A high-performance web server and reverse proxy
CouchDB
A scalable, document-oriented NoSQL database
Kafka
A distributed, high-performing publish/subscribe messaging
system
All the components are Docker containers, a format to package
applications in an efficient but constrained, virtual machine–like
environment. They can be run any environment supporting this
format, like Kubernetes.
Furthermore, OpenWhisk can be split into some components of its
own:

Controller
Managing entities, handling trigger fires, and routing actions
invocations
Invoker
Launching the containers to execute the actions
Action Containers
Actually executing the actions
In Figure 1-4 you can see how the processing happens. We are
going to discuss it in detail, step by step.
Figure 1-4. How OpenWhisk processes an action

NOTE
Basically, all the processing done in OpenWhisk is asynchronous, so we will go
into the details of an asynchronous action invocation. Synchronous execution
fires an asynchronous action and then waits for the result.
Nginx
Everything starts when an action is invoked. There are different
ways to invoke an action:
From the web, when the action is exposed as a web action
When another action invokes it through the API
When a trigger is activated and there is a rule to invoke the
action
From the CLI
Let’s call the client the subject who invokes the action. OpenWhisk is
a RESTful system, so every invocation is translated to an HTTPS call
and hits the so-called “edge” node. The edge is actually the web
server and reverse proxy Nginx. The primary purpose of Nginx is to
implement support for the HTTPS secure web protocol, so it deploys
all the certificates required for secure processing. Nginx then
forwards the requests to the actual internal service component, the
controller.
Controller
Before executing the action, the controller checks whether it can
execute the action and initialize it correctly:
1. It needs to be sure it can execute the action, so it must
authenticate the request.

2. Once the origin of the request has been identified, it needs
to be authorized, verifying that the subject has the
appropriate permissions.
3. The request must be enriched with some additional
parameters that, as we will see, are provided as part of
action configuration.
To perform all those steps the controller consults the database,
which in OpenWhisk is CouchDB. Once validated and enriched, the
action is now ready to be executed, so it is sent to the next
component of the processing, the load balancer.
Load Balancer
The job of the load balancer, as its name implies, is to balance the
load among the various executors in the system, which are called
invokers in OpenWhisk.
We already saw that OpenWhisk executes actions in runtimes. The
load balancer keeps an eye on the available instances of the action
runtime, reuses the existing ones if they are available, or creates
new ones if they are needed.
We’ve arrived at the point where the system is ready to invoke the
action. However, you cannot just send your action invocation to an
invoker, because it may be busy serving another action. There is also
the possibility that an invoker has crashed, or even that the whole
system has crashed and is restarting.
So, because we are working in a massively parallel environment that
is expected to scale, we have to consider the possibility that we will
not have the resources we need to execute the action immediately.
In cases like this, we have to buffer invocations. OpenWhisk uses
Kafka to perform this action. Kafka is a high-performing “publish and
subscribe” messaging system that can store your requests until they
are ready to be executed. The request is turned into a message

addressed to the invoker the load balancer chose for the execution.
An action invocation is actually turned in an HTTPS request to Nginx;
then it internally becomes a message to Kafka.
Each message sent to an invoker has an identifier called the
activation ID. Once the message has been queued in Kafka, there
are two possibilities: a nonblocking and a blocking invocation.
For a nonblocking invocation, the activation id is sent back as the
final answer to the request to the client, and the request completes.
In this case, the client is expected to come back later to check the
result of the invocation.
For a blocking invocation, the connection stays open: the controller
waits for the result from the action and sends the result to the client.
Invoker
In OpenWhisk the invoker is in charge of executing the actions.
Actions are actually executed by the invoker in isolated environments
provided by Docker containers. As already mentioned, Docker
containers are execution environments that resemble an entire
operating system, providing everything needed to run an application.
So, from the actions perspective, the environment provided by a
Docker container looks like an entire computer (just like a VM).
However, execution within containers is much more efficient than in
VMs, so they are preferred.
NOTE
It would be safe to say that, without containers, serverless environments like
OpenWhisk would not be possible.
Docker actually uses images to create the containers that execute
actions. A runtime is really a Docker image. The invoker launches a

new image for the chosen runtime and then initializes it with the
code of the action. OpenWhisk provides a set of Docker images
including support for various languages. The action runtimes also
include the initialization logic. They support JavaScript, Python, Go,
Java, and similar languages.
Once the runtime is up and running, the invoker passes the action
requests that have been constructed in the processing so far. The
invoker also manages and stores the logs needed to facilitate
debugging.
After OpenWhisk completes the processing, it must store the result
somewhere. This place is again CouchDB (where configuration data
is also stored). Each result of the execution of an action is then
associated with the activation ID, the one that was sent back to the
client. Thus, the client can retrieve the result of its request by
querying the database with the ID.
Client
The processing described so far is asynchronous. This means the
client will start a request and forget about it, although it doesn’t
leave it behind entirely, because it returns an activation ID as the
result of an invocation. As we have seen already, the activation ID is
used to store the result in the database after the processing. To
retrieve the final result, the client will have to perform a request
again later, passing the activation ID as a parameter. Once the action
completes, the result, the logs, and other information will be
available in the database and can be retrieved.
Synchronous processing is also available. It works the same way as
asynchronous processing, except the client will block waiting for the
action to complete and retrieve the result immediately.

Discovering Diverse Content Through
Random Scribd Documents

PLEASE READ THIS BEFORE YOU DISTRIBUTE OR USE THIS WORK
To protect the Project Gutenberg™ mission of promoting the free
distribution of electronic works, by using or distributing this work (or
any other work associated in any way with the phrase “Project
Gutenberg”), you agree to comply with all the terms of the Full
Project Gutenberg™ License available with this file or online at
www.gutenberg.org/license.
Section 1. General Terms of Use and
Redistributing Project Gutenberg™
electronic works
1.A. By reading or using any part of this Project Gutenberg™
electronic work, you indicate that you have read, understand, agree
to and accept all the terms of this license and intellectual property
(trademark/copyright) agreement. If you do not agree to abide by all
the terms of this agreement, you must cease using and return or
destroy all copies of Project Gutenberg™ electronic works in your
possession. If you paid a fee for obtaining a copy of or access to a
Project Gutenberg™ electronic work and you do not agree to be
bound by the terms of this agreement, you may obtain a refund
from the person or entity to whom you paid the fee as set forth in
paragraph 1.E.8.
1.B. “Project Gutenberg” is a registered trademark. It may only be
used on or associated in any way with an electronic work by people
who agree to be bound by the terms of this agreement. There are a
few things that you can do with most Project Gutenberg™ electronic
works even without complying with the full terms of this agreement.
See paragraph 1.C below. There are a lot of things you can do with
Project Gutenberg™ electronic works if you follow the terms of this
agreement and help preserve free future access to Project
Gutenberg™ electronic works. See paragraph 1.E below.

1.C. The Project Gutenberg Literary Archive Foundation (“the
Foundation” or PGLAF), owns a compilation copyright in the
collection of Project Gutenberg™ electronic works. Nearly all the
individual works in the collection are in the public domain in the
United States. If an individual work is unprotected by copyright law
in the United States and you are located in the United States, we do
not claim a right to prevent you from copying, distributing,
performing, displaying or creating derivative works based on the
work as long as all references to Project Gutenberg are removed. Of
course, we hope that you will support the Project Gutenberg™
mission of promoting free access to electronic works by freely
sharing Project Gutenberg™ works in compliance with the terms of
this agreement for keeping the Project Gutenberg™ name associated
with the work. You can easily comply with the terms of this
agreement by keeping this work in the same format with its attached
full Project Gutenberg™ License when you share it without charge
with others.
1.D. The copyright laws of the place where you are located also
govern what you can do with this work. Copyright laws in most
countries are in a constant state of change. If you are outside the
United States, check the laws of your country in addition to the
terms of this agreement before downloading, copying, displaying,
performing, distributing or creating derivative works based on this
work or any other Project Gutenberg™ work. The Foundation makes
no representations concerning the copyright status of any work in
any country other than the United States.
1.E. Unless you have removed all references to Project Gutenberg:
1.E.1. The following sentence, with active links to, or other
immediate access to, the full Project Gutenberg™ License must
appear prominently whenever any copy of a Project Gutenberg™
work (any work on which the phrase “Project Gutenberg” appears,
or with which the phrase “Project Gutenberg” is associated) is
accessed, displayed, performed, viewed, copied or distributed:

This eBook is for the use of anyone anywhere in the United
States and most other parts of the world at no cost and with
almost no restrictions whatsoever. You may copy it, give it away
or re-use it under the terms of the Project Gutenberg License
included with this eBook or online at www.gutenberg.org. If you
are not located in the United States, you will have to check the
laws of the country where you are located before using this
eBook.
1.E.2. If an individual Project Gutenberg™ electronic work is derived
from texts not protected by U.S. copyright law (does not contain a
notice indicating that it is posted with permission of the copyright
holder), the work can be copied and distributed to anyone in the
United States without paying any fees or charges. If you are
redistributing or providing access to a work with the phrase “Project
Gutenberg” associated with or appearing on the work, you must
comply either with the requirements of paragraphs 1.E.1 through
1.E.7 or obtain permission for the use of the work and the Project
Gutenberg™ trademark as set forth in paragraphs 1.E.8 or 1.E.9.
1.E.3. If an individual Project Gutenberg™ electronic work is posted
with the permission of the copyright holder, your use and distribution
must comply with both paragraphs 1.E.1 through 1.E.7 and any
additional terms imposed by the copyright holder. Additional terms
will be linked to the Project Gutenberg™ License for all works posted
with the permission of the copyright holder found at the beginning
of this work.
1.E.4. Do not unlink or detach or remove the full Project
Gutenberg™ License terms from this work, or any files containing a
part of this work or any other work associated with Project
Gutenberg™.
1.E.5. Do not copy, display, perform, distribute or redistribute this
electronic work, or any part of this electronic work, without
prominently displaying the sentence set forth in paragraph 1.E.1

with active links or immediate access to the full terms of the Project
Gutenberg™ License.
1.E.6. You may convert to and distribute this work in any binary,
compressed, marked up, nonproprietary or proprietary form,
including any word processing or hypertext form. However, if you
provide access to or distribute copies of a Project Gutenberg™ work
in a format other than “Plain Vanilla ASCII” or other format used in
the official version posted on the official Project Gutenberg™ website
(www.gutenberg.org), you must, at no additional cost, fee or
expense to the user, provide a copy, a means of exporting a copy, or
a means of obtaining a copy upon request, of the work in its original
“Plain Vanilla ASCII” or other form. Any alternate format must
include the full Project Gutenberg™ License as specified in
paragraph 1.E.1.
1.E.7. Do not charge a fee for access to, viewing, displaying,
performing, copying or distributing any Project Gutenberg™ works
unless you comply with paragraph 1.E.8 or 1.E.9.
1.E.8. You may charge a reasonable fee for copies of or providing
access to or distributing Project Gutenberg™ electronic works
provided that:
• You pay a royalty fee of 20% of the gross profits you derive
from the use of Project Gutenberg™ works calculated using the
method you already use to calculate your applicable taxes. The
fee is owed to the owner of the Project Gutenberg™ trademark,
but he has agreed to donate royalties under this paragraph to
the Project Gutenberg Literary Archive Foundation. Royalty
payments must be paid within 60 days following each date on
which you prepare (or are legally required to prepare) your
periodic tax returns. Royalty payments should be clearly marked
as such and sent to the Project Gutenberg Literary Archive
Foundation at the address specified in Section 4, “Information

about donations to the Project Gutenberg Literary Archive
Foundation.”
• You provide a full refund of any money paid by a user who
notifies you in writing (or by e-mail) within 30 days of receipt
that s/he does not agree to the terms of the full Project
Gutenberg™ License. You must require such a user to return or
destroy all copies of the works possessed in a physical medium
and discontinue all use of and all access to other copies of
Project Gutenberg™ works.
• You provide, in accordance with paragraph 1.F.3, a full refund of
any money paid for a work or a replacement copy, if a defect in
the electronic work is discovered and reported to you within 90
days of receipt of the work.
• You comply with all other terms of this agreement for free
distribution of Project Gutenberg™ works.
1.E.9. If you wish to charge a fee or distribute a Project Gutenberg™
electronic work or group of works on different terms than are set
forth in this agreement, you must obtain permission in writing from
the Project Gutenberg Literary Archive Foundation, the manager of
the Project Gutenberg™ trademark. Contact the Foundation as set
forth in Section 3 below.
1.F.
1.F.1. Project Gutenberg volunteers and employees expend
considerable effort to identify, do copyright research on, transcribe
and proofread works not protected by U.S. copyright law in creating
the Project Gutenberg™ collection. Despite these efforts, Project
Gutenberg™ electronic works, and the medium on which they may
be stored, may contain “Defects,” such as, but not limited to,
incomplete, inaccurate or corrupt data, transcription errors, a
copyright or other intellectual property infringement, a defective or

damaged disk or other medium, a computer virus, or computer
codes that damage or cannot be read by your equipment.
1.F.2. LIMITED WARRANTY, DISCLAIMER OF DAMAGES - Except for
the “Right of Replacement or Refund” described in paragraph 1.F.3,
the Project Gutenberg Literary Archive Foundation, the owner of the
Project Gutenberg™ trademark, and any other party distributing a
Project Gutenberg™ electronic work under this agreement, disclaim
all liability to you for damages, costs and expenses, including legal
fees. YOU AGREE THAT YOU HAVE NO REMEDIES FOR
NEGLIGENCE, STRICT LIABILITY, BREACH OF WARRANTY OR
BREACH OF CONTRACT EXCEPT THOSE PROVIDED IN PARAGRAPH
1.F.3. YOU AGREE THAT THE FOUNDATION, THE TRADEMARK
OWNER, AND ANY DISTRIBUTOR UNDER THIS AGREEMENT WILL
NOT BE LIABLE TO YOU FOR ACTUAL, DIRECT, INDIRECT,
CONSEQUENTIAL, PUNITIVE OR INCIDENTAL DAMAGES EVEN IF
YOU GIVE NOTICE OF THE POSSIBILITY OF SUCH DAMAGE.
1.F.3. LIMITED RIGHT OF REPLACEMENT OR REFUND - If you
discover a defect in this electronic work within 90 days of receiving
it, you can receive a refund of the money (if any) you paid for it by
sending a written explanation to the person you received the work
from. If you received the work on a physical medium, you must
return the medium with your written explanation. The person or
entity that provided you with the defective work may elect to provide
a replacement copy in lieu of a refund. If you received the work
electronically, the person or entity providing it to you may choose to
give you a second opportunity to receive the work electronically in
lieu of a refund. If the second copy is also defective, you may
demand a refund in writing without further opportunities to fix the
problem.
1.F.4. Except for the limited right of replacement or refund set forth
in paragraph 1.F.3, this work is provided to you ‘AS-IS’, WITH NO
OTHER WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED,

INCLUDING BUT NOT LIMITED TO WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR ANY PURPOSE.
1.F.5. Some states do not allow disclaimers of certain implied
warranties or the exclusion or limitation of certain types of damages.
If any disclaimer or limitation set forth in this agreement violates the
law of the state applicable to this agreement, the agreement shall be
interpreted to make the maximum disclaimer or limitation permitted
by the applicable state law. The invalidity or unenforceability of any
provision of this agreement shall not void the remaining provisions.
1.F.6. INDEMNITY - You agree to indemnify and hold the Foundation,
the trademark owner, any agent or employee of the Foundation,
anyone providing copies of Project Gutenberg™ electronic works in
accordance with this agreement, and any volunteers associated with
the production, promotion and distribution of Project Gutenberg™
electronic works, harmless from all liability, costs and expenses,
including legal fees, that arise directly or indirectly from any of the
following which you do or cause to occur: (a) distribution of this or
any Project Gutenberg™ work, (b) alteration, modification, or
additions or deletions to any Project Gutenberg™ work, and (c) any
Defect you cause.
Section 2. Information about the Mission
of Project Gutenberg™
Project Gutenberg™ is synonymous with the free distribution of
electronic works in formats readable by the widest variety of
computers including obsolete, old, middle-aged and new computers.
It exists because of the efforts of hundreds of volunteers and
donations from people in all walks of life.
Volunteers and financial support to provide volunteers with the
assistance they need are critical to reaching Project Gutenberg™’s
goals and ensuring that the Project Gutenberg™ collection will

remain freely available for generations to come. In 2001, the Project
Gutenberg Literary Archive Foundation was created to provide a
secure and permanent future for Project Gutenberg™ and future
generations. To learn more about the Project Gutenberg Literary
Archive Foundation and how your efforts and donations can help,
see Sections 3 and 4 and the Foundation information page at
www.gutenberg.org.
Section 3. Information about the Project
Gutenberg Literary Archive Foundation
The Project Gutenberg Literary Archive Foundation is a non-profit
501(c)(3) educational corporation organized under the laws of the
state of Mississippi and granted tax exempt status by the Internal
Revenue Service. The Foundation’s EIN or federal tax identification
number is 64-6221541. Contributions to the Project Gutenberg
Literary Archive Foundation are tax deductible to the full extent
permitted by U.S. federal laws and your state’s laws.
The Foundation’s business office is located at 809 North 1500 West,
Salt Lake City, UT 84116, (801) 596-1887. Email contact links and up
to date contact information can be found at the Foundation’s website
and official page at www.gutenberg.org/contact
Section 4. Information about Donations to
the Project Gutenberg Literary Archive
Foundation
Project Gutenberg™ depends upon and cannot survive without
widespread public support and donations to carry out its mission of
increasing the number of public domain and licensed works that can
be freely distributed in machine-readable form accessible by the
widest array of equipment including outdated equipment. Many

small donations ($1 to $5,000) are particularly important to
maintaining tax exempt status with the IRS.
The Foundation is committed to complying with the laws regulating
charities and charitable donations in all 50 states of the United
States. Compliance requirements are not uniform and it takes a
considerable effort, much paperwork and many fees to meet and
keep up with these requirements. We do not solicit donations in
locations where we have not received written confirmation of
compliance. To SEND DONATIONS or determine the status of
compliance for any particular state visit www.gutenberg.org/donate.
While we cannot and do not solicit contributions from states where
we have not met the solicitation requirements, we know of no
prohibition against accepting unsolicited donations from donors in
such states who approach us with offers to donate.
International donations are gratefully accepted, but we cannot make
any statements concerning tax treatment of donations received from
outside the United States. U.S. laws alone swamp our small staff.
Please check the Project Gutenberg web pages for current donation
methods and addresses. Donations are accepted in a number of
other ways including checks, online payments and credit card
donations. To donate, please visit: www.gutenberg.org/donate.
Section 5. General Information About
Project Gutenberg™ electronic works
Professor Michael S. Hart was the originator of the Project
Gutenberg™ concept of a library of electronic works that could be
freely shared with anyone. For forty years, he produced and
distributed Project Gutenberg™ eBooks with only a loose network of
volunteer support.

Project Gutenberg™ eBooks are often created from several printed
editions, all of which are confirmed as not protected by copyright in
the U.S. unless a copyright notice is included. Thus, we do not
necessarily keep eBooks in compliance with any particular paper
edition.
Most people start at our website which has the main PG search
facility: www.gutenberg.org.
This website includes information about Project Gutenberg™,
including how to make donations to the Project Gutenberg Literary
Archive Foundation, how to help produce our new eBooks, and how
to subscribe to our email newsletter to hear about new eBooks.

Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade
Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.
Let us accompany you on the journey of exploring knowledge and
personal growth!
textbookfull.com

Learning Apache OpenWhisk Developing Open Serverless Solutions 1st Edition Michele Sciabarrà

More Related Content

Similar to Learning Apache OpenWhisk Developing Open Serverless Solutions 1st Edition Michele Sciabarrà (20)

Recently uploaded (20)

Learning Apache OpenWhisk Developing Open Serverless Solutions 1st Edition Michele Sciabarrà