Serverless book

Serverless
technology
Aki @ nekoruri
Memo-Okiba TechReport Summary #1

2
Introduction
In this document, we will clarify the essence of a technology movement called "serverless", and explain
the concepts necessary for realizing a serverless system from now on and the current state of public cloud
in the present situation.
At the time of this writing (October 2017), serverless related technology has continued to release new
services and functions with a furious momentum. In order to avoid the fact that it is not immediately useful
or inappropriate for the actual situation, I emphasize the concept behind it rather than the existing
function, but also reflect the new information as much as possible about the service to introduce. Please
make sure to hit documents of each cloud vendor and press releases in succession. Well, I think that it is
an interesting field including such places.
I hope that understanding of the new paradigm that will be the main force in 10 years will be advanced
by this book.

3
Index
Introduction..................................................................................................................................................................................................................................2
1. About Serverless.........................................................................................................................................................................................................5
Appearance of serverless idea.............................................................................................................................................................................5
Promotion of serverless by public cloud......................................................................................................................................................6
Definition of "serverless"............................................................................................................................................................................................6
Column: By the way, is it now, serverless? Serverless? ........................................................................................................................9
2. Arrangement as technical field....................................................................................................................................................................10
FaaS: Function as a Service .................................................................................................................................................................................10
Functional SaaS...............................................................................................................................................................................................................13
Summary..............................................................................................................................................................................................................................18
3. Design Points in the Serverless Era ........................................................................................................................................................19
Reactive System.............................................................................................................................................................................................................19
Identity management.................................................................................................................................................................................................20
4. Practical pattern of serverless architecture......................................................................................................................................22
Web a .....................................................................................................................................22
Cloud-based event processing.............................................................................................................................................................................22
Streaming event.............................................................................................................................................................................................................22
5. Overview of each company "serverless"...............................................................................................................................................24
AWS Lambda....................................................................................................................................................................................................................24
Azure Functions.............................................................................................................................................................................................................25
Google Cloud Functions............................................................................................................................................................................................25
IBM Cloud Functions.................................................................................................................................................................................................26
6. Comparison of FaaS...............................................................................................................................................................................................28
Function interface.........................................................................................................................................................................................................28
Development with FaaS ..........................................................................................................................................................................................31
7. Serverless application execution env other than FaaS ............................................................................................................35
Application container.................................................................................................................................................................................................35
Streaming SQL................................................................................................................................................................................................................36
Flow-based programming.......................................................................................................................................................................................36
8. Serverless operation ..............................................................................................................................................................................................37
Deploying Functions...................................................................................................................................................................................................37
Monitoring (logging, metrics)...............................................................................................................................................................................38
Managing Execution Permissions....................................................................................................................................................................38

4
Functional SaaS management.............................................................................................................................................................................39
9. AWS Lambda..............................................................................................................................................................................................................40
Characteristics of FaaS ............................................................................................................................................................................................40
Features of Functional SaaS................................................................................................................................................................................41
Management and operation..................................................................................................................................................................................43
10. Azure Functions................................................................................................................................................................................................46
11. Google Cloud Functions...............................................................................................................................................................................51
12. IBM Cloud Functions.....................................................................................................................................................................................53
Functional SaaS .............................................................................................................................................................................................53
13. Toward the Future.........................................................................................................................................................................................55
Afterword...................................................................................................................................................................................................................................56

5
1. About Serverless
In understanding the technical field called "serverless", definition is always the first topic.
This is a phenomenon often occurring in the newly appearing Buzzard, and the feature in its typical
implementation and the essential change that they bring are taken together so that the superficial meaning
of the word and the pointed point are shifted Get up. Even in serverless, there is a difference between the
superficial meaning of "serverless", that is, the server's absence, the specific services and cases raised in
marketing, and the essence of a new way of thinking that changes the world itself intermingled and
confused It is the present condition that it is doing.
First, historically chasing the word "serverless" introduces various aspects and explains what "essential
change due to being serverless" discussed in this book is.
Appearance of serverless idea
The technical term "serverless" first appeared as an article called "Why The Future Of Software And
Apps Is Serverless"1
written in 2012 (why future software and applications are serverless) I will.
In this article, we propose the idea of serverless from the viewpoint of application developers. In the
trend from on-premises to clouds, from monolithic Web applications implemented on legacy frameworks to
distributed systems that combine loose-coupled components including cloud components, smartphones and
applications on browsers doing. Among them explains that developers are supposed to think about task
units executed in units of seconds instead of server units. In response to this, the developer introduced the
serverless as not having to manage / conscious of the server, paying attention only to the computing
(computing) resource provided (service) by the cloud. And while exemplifying the reforms of the water
network and the electricity network (second industrial revolution due to the realization of mass production),
merit of cost optimization and focus on business strategy is clear, and many developers think about this
concept I am accustomed to using it and insisting that it will be used even in larger organizations.
In other words, as a result of further promoting the idea of "switching from ownership to use" of cloud
computing, it became possible to use functions (computing resources) which are abstracted results, and
various functions It is that you do not have trouble looking at the part of building = as an obligation.
The important point is that the direction of serverless is not something completely new, but it is just a
name given to a field of computer science called 'abstraction of computer functions' which has reached
1
http://readwrite.com/2012/10/15/why-the-future-of-software-and-apps-is-serverless/

6
practical use. However, there is also a side that this catchy name has been used as a driving force, so that
serverless use will proceed from here.
Promotion of serverless by public cloud
The term "serverless" is spread through the preview release of AWS Lambda at the end of 2014, but as
the origin of the service that embodies serverless on the public cloud, we picked up the Google App Engine
preview released in 2008 It can not be without it.
In Google App Engine, once deploying an application, the execution environment is scaled fully
automatically, there is no need to think about a unit called a server, and it is charged by the actually
consumed CPU usage time. It was an application execution environment that fully satisfies the serverless
nature. However, it was only at the time of preview, it was changed to billing on an instance basis at the
time of public release, and it became similar to a kind of general PaaS. In addition, there was a reason that
the data store's habit of being available is too strong (too fast for human beings), and it was a strong
impression that Google provided externally a serverless architecture execution environment designed by
himself externally. After all, although it is deeply used only in a part, it did not become widely used at all.
For six years from then, when AWS Lambda makes a spectacular debut with the word "serverless
architecture", it has been used at a stroke. After that, Azure Functions, Google Cloud Functions, IBM
Bluemix OpenWhisk, etc. have appeared, as you all know, while putting each company's strengths close to
AWS Lambda. In addition, various components indispensable for realizing a serverless system also
expanded in parallel.
It can be said that the serverless architecture on the public cloud has entered the stage where tools and
tools are ready to spread rapidly.
Definition of "serverless"
Here I would like to discuss what something "serverless" shows again. The technology movement called
"serverless" can be roughly divided into two.
Managed service not considering "server"
First, as the first definition was, the idea of not having to consider "server" in system realization, and the
service that provides such abstracted computing resources. It can be said that the way of thinking
introduced in the previous article remains unchanged.

7
More finely classified is FaaS (Function as a Service) which is an environment where small code
(function) which accepts some constraints can be executed scalably and FaaS (Function as a Service) which
is managed completely by the cloud operator and provides some concrete function Functional SaaS is made
up of two.
Both have physical servers (or virtualized servers running on them) behind them, and server processes
that work there, but they are not aware of it when using them. Even if the server exists physically and
physically like a mechanism like autoscale is running, if it is hidden as a service and you can use it as much
as you want and use it, you will be charged for the CPU time consumed, the application Developers are no
longer free from the concept of servers.
In addition to simply saying "It is well managed and hidden by cloud vendors", as a result of the large
number of users being multiplexed and used on a huge number of servers by large public clouds, it
becomes no longer a single company But it is difficult to realize with computers that manage themselves.
Services like "thin and wide" spirit balls are increasingly increasing their presence. The most famous one is
Google BigQuery. Distributing data gradually in Google's huge data store consisting of tens of thousands of
servers or more and distributing processing little by little makes it possible to instantly search from a huge
amount of data to search conditions that require a full scan It is a dreamlike system that can return results
to. In addition, the data store which can only be possible due to mega cloud, such as Azure CosmosDB
advocating scaling on a global scale, continues. The emergence of such a "thin and wide" architecture also
supports the spread of a fully managed, serverless execution environment.
System architecture for event driven connection of components
The second one is to use them, and by thinking of connecting event-driven FaaS and Functional SaaS to
loose coupling, it is a way to discard the role of server as the "conductor" of the entire system.
Components offered by cloud vendors have become multifunctional, and each has come to generate
various "events". By stitching high-level components together at events, we eliminate "application servers"
that centralized business logic implementation. Although the "application" software that I implement on my
own is not completely eliminated, it changes to a standing position as a "paste" connecting various
components.
For example, the data store provided by the public cloud has not only simple scalability but also access
control in cooperation with the framework of ID management. As an example, it is assumed that access
authority such as "Mr. A who logged in as a user of Facebook has saved his post and only himself edits the
post" is not implemented as software by himself but access control of the data store It can be assembled
with the function. Besides, we make the system by connecting the components by "gluing" with fine
software such as "Reduce posted photos and add thumbnails" "Add to mail queue for administrator".

8
The wave of native application and SPA conversion on the front side also pushes this movement. You
can access the data store of the cloud vendor directly from the front side application and only have the
implementation on the cloud side need the black box like properties like "Gacha". Moreover, bidirectional
protocols such as Web Socket become realistic, and the front side application can be regarded as part of a
loosely coupled distributed system which exchanges asynchronous events with the cloud.
These movements can be expressed as "control inversion" in the so-called cloud era. The reversal of
control in programming was a change in the form of "calling the library from your program" to "library
(framework) calling up your program." In the cloud era, rather than the application server calling various
cloud components, each component calls a small function, or it cooperates directly with other components
by the cloud side standard event forwarding function.
This trend is a change in the design method itself from the system architecture "monolithic application",
and it seems to be expressed as a flow of micro service and choreography.
Two "serverless" one
The whole process of utilizing various SaaS with the focus on FaaS, which is the pasted part of the
discussion, is the true identity of the "serverless" technology movement that is rising in recent years.
Although the former is imaged from the word "serverless", the fact that actually changes the world is
the paradigm shift of software development itself by the latter. It can be said that the constraint for FaaS
naturally leads to a shift to a better architecture by event driven.
Depending on who you are driving FaaS and event driven is different, it seems that there will be a
situation where you will have to be conscious of which discussion is the main focus for a while for some
time.

9
Column: By the way, is it now, serverless? Serverless?
This is a column on notation method in Japanese translation
Although it is a hot topic, the Japanese notation of "Serverless" is swaying with "serverless" and
"serverless". In conclusion, "Serverless" is a more correct notation. Also in the documents of cloud vendors,
unification has advanced recently to "serverless", but there seems to be partial notation fluctuation
remaining. Previously, we have been "serverless", but from here on we will unify it as "serverless".
If there is a tremendous shaking notation, there are both "server" and "server" in the notation of the
original "server". In general, in the context of the industrial field, it is common to use "server" which omits
the long sounds in favor of the notation according to the JIS standard, and "server" conforming to the
cabinet notice of the Japanese government in the other contexts . Along with the generalization of
information technology, the latter as a whole should continue to be the latter, but "server" is strongly
supported mainly by engineers.
Based on this, the notation "serverless" that there is no "server" (less) was born. However, the JIS rule is
exactly "not attaching a long note to the end", and in the case of a word "Serverless" originally, "server less"
is a correct notation without a server .
Although it can not be helped because it is a rule that does not consider the consistency with the
compound word, there is somewhat strange feeling.
There are "Serverless Architecture" and "Serverless Computing" as derivatives of "Serverless". As a
matter of fact, the serverless architecture seems to refer to event driven architecture in many cases,
serverless computing seems to refer to FaaS in many cases, but because it is not clearly distinguished and
it is confusing, in this book, We will unite with "Les".

10
2. Arrangement as technical field
In the previous chapter, we classified and explained serverless as a way of thinking, but from the
viewpoint of services actually provided by cloud vendors in considering real design and implementation,
FaaS ( Function as Sa Service (Service as a Service) that emphasizes services provided by cloud vendors
and their functions.
I will explain concretely what each of FaaS and Functional SaaS is.
FaaS: Function as a Service
As mentioned earlier, FaaS runs small code scalably and is charged accordingly. Serverless
representatives such as AWS Lambda and Azure Functions are equivalent to FaaS.
FaaS is exactly a flower form of "serverless" movement. Deploying a small program called Function
(function) will make the cloud move it well. And to realize that, the constraints that have been cultivated in
redundant applications so far, such as "The Twelve - Factor App" are representative examples, so to speak,
so to speak, "best practices for redundancy" It is forced to accept.
Structure of FaaS
Specifically, it consists of an execution environment abstracted by a technology such as an application
container, a controller that calls functions registered by the user on the execution environment, and a
management function that performs autoscale processing of the execution environment according to
demand It is.
In a typical FaaS configuration, when a function is called, one container environment is allocated. It
extracts the file image including the function registered by the user and the library called from there from
the data store and expands it. The controller of FaaS reads the function registered as an event handler into
memory, prepares arguments according to the event, and passes it to the function. If it is asynchronous
processing, it is over here, but in the case of synchronous processing like HTTP request etc., it waits for
the return value from the function and returns it as the response to the request source. Ultimately records
the time taken to process the function and charges the user.
In addition, when the function is called many times at the same time, the FaaS management function
prepares another container environment newly, calls the function in the same way and assigns the request.
As it is, the container environment will increase, but if not invoked for a certain time, we will reduce the
container environment. The increment / decrement algorithm around this is unique to each cloud vendor.

11
In this way, it is characterized by FaaS taking care of everything including not only the autoscaling of
simply increasing / decreasing the number of VMs, but also the deployment of the program there.
For now the application will increase containers after it runs short in response to actual demand, so in
applications that take time to start container, bad luck requests will be kept waiting for a long time.
Therefore, there are some issues related to startup time. However, we anticipate that the normal era will
come from "cloud vendors" in advance, "hot pool" which speculatively and proactively activate the
container.
iPaaS (Integrated PaaS) constituting workflow
Services that combine multiple functions to create a series of workflows are being released one after the
other. Starting with "IBM Bluemix Node - RED" released in June 2014, "Azure Logic Apps" and "AWS Step
Functions" followed in July 2016, and in 2017 also "Durable Functions "IBM Cloud Functions" Composer
"has appeared.
Both Node - RED and Azure Logic Apps can connect workflows on the web UI and create a bigger
process. Even if it is a web UI, since processing is successfully encapsulated, it is possible to realize real
time processing including various inputs and outputs and complicated logic. Because Node-RED is released
by OSS and can be run by microcomputer such as Raspberry Pi, it is possible to directly handle input of
Bluetooth LE and various sensors as IoT device, edge computing such as aggregation from raw data as
IoT gateway You can use it in various ways. This field is called flow-based programming.
AWS Step Functions, Durable Functions, and Composer provide a programming model surrounding
FaaS, such as constructing a larger system by combining functions in several ways, all of which enhance
the value of FaaS with a different approach.
AWS Step Functions uses a JSON-based DSL called "Amazon State Language" to create a flow
combining multiple Steps (State as AWS), which can be said to be close to Node-RED and Azure Logic
Apps. In Step, you can simply define a branch (execute one) based on conditions, execute multiple
processes concurrently, wait until all are finished, stop until a specified time, etc. I will. In addition, since
you can check the execution history of each, you can check if the intended operation is being performed.
Azure's Durable Functions is still in the public preview stage at the time of writing, but it can
implement a workflow as a function that runs for a long time. As well as AWS Step Functions, you can
perform functions and parallel operations, and you can implement functions with "Async HTTP APIs"
patterns, states that provide APIs that track progress status against long-running processing "Stateful
Singletons" pattern (Reliable Actors pattern), "Human Interaction and Timeouts" which waits for human
confirmation and waits for a timer, etc. are offered. As of now, there are issues such as weakness in
monitoring and management that can be implemented only in C #, but it is difficult to build a system with

12
only asmall asynchronous function combinations, one of the things we can not wait for GA release. Stateful
Singletons and others, especially because there are many people who want to use it immediately.
Composer of IBM Cloud Functions provides workflow combining multiple functions like AWS Step
Functions as a library of Nodes rather than DSL. It is a stage that is difficult to evaluate because it is just
released in Serverlessconf NYC '17 that is being written, but as far as I can see it is a good competitor of
Step Functions.
Especially for the latter three, it is expected that it will become a considerably important position in the
future as it complements functions in FaaS well. I think that I can become happy when chasing with FaaS.
Difference from traditional PaaS
The difference between FaaS and existing PaaS such as Heroku is discussed well. There is not a
substantial difference as there is a definition there, but it seems to be often distinguished by the ease of
scale.
Frequently cited is "Expression that PaaS can run with less than 20 milliseconds and can be called
serverless if it can run for only 0.5 seconds"23
. As authors, I do not mind staying at that time, I feel that it
can be said to be serverless if it is autoscaled and charged with execution time around seconds.
On the other hand, there are also methods for lightening initialization processing such as applications by
Go, so I think that it will approach the area like FaaS from existing PaaS. In any case, as a full-managed
execution environment, it has a long long-term know-how.
Development of FaaS not dependent on function
A model that moves a general monolithic application in a lifecycle like FaaS has appeared without being
limited to a small particle size function. Container Instances of Azure, FastContainer of GMO Peperbo,
Fargate of AWS, and so on. You can include the application container in a serverless execution
environment if you run the application container in a short life cycle and you can charge execution time.
Because AWS Lambda made an impressive success with its ecosystem, image is being developed that
FaaS is the only and best form as a serverless application execution environment, but statelessness is the
essential constraint It is important to combine technologies and services without being caught in the form
of FaaS.
2
https://blogs.msdn.microsoft.com/appserviceteam/2017/10/10/durable-functions-and-bindings-extensibility-preview-announcement/
3
https://twitter.com/adrianco/status/736553530689998848
If your PaaS can efficiently start instances in 20ms that run for half a second, then call it serverless.

13
Advance into edge computing etc.
Actually, it is somewhat shifted from the context of serverless, but there is a trend to utilize the
programming model of FaaS not only for applications but also various places.
One is the area of edge computing in the IoT field. The primary purpose of edge computing is to
perform conversion and aggregation of data coming from IoT devices that can only output simple "raw"
data at the gateway layer on the cloud side, but it operates on the gateway A common programming
model with FaaS is being adopted, and AWS Greengrass and Azure IoT Gateway are appearing.
In addition, Lambda @ Edge which executes the function for each request on CDN edge server has
appeared. This is because there is a black magical place because the CDN side can control request and
response such as HTTP like the VCL (Varnish Configuration Language) in the cache server Varnish and
the iRules in the load balancer BIG - IP It is possible to make various uses such as "a little small
workmanship" to "innovative load reduction".
As you can see, the programming model called FaaS programming model and its interface are expected
to be utilized and diverted as abstraction layers in various places in the cloud in the future.
Functional SaaS
If you define FaaS as "rice" for meals, it is something like "side dish" that is a daily pleasure and provides
valuable nutrients, is Functional SaaS. In creating a system, it can be said that utilizing the services found
in the individual use cases is the core of "productivity improvement through serverless adoption".
There are many different things because it is "side dish", but I will take up important ones.
Message queue
When the sender (Producer) throws a message, it is a simple message queue that the recipient
(Consumer) can receive the message. Until the framework of the above-mentioned workflow was created,
we had to inter-function between functions by inserting message queues one by one. Since the world is not
the only function, there are situations where Message Queuing is still necessary.
Specific services include Amazon SQS, Azure Queue Storage, etc. In addition, it may be replaced with a
simple message queue by using the Pub / Sub queue described later. In addition, Azure Event Grid and
others that have enhanced the cooperation with functions etc. have also appeared. You can fire Azure
Functions etc directly in the later Event Grid etc, but Amazon SQS can only read from AWS Lambda
which was started by another means, so you can use Amazon SNS which is the Pub / Sub queue described
later or with a timer It is necessary to have another mechanism of periodically starting up AWS Lambda.

14
As a utilization of message queue, there is a Queue-based Load Leveling (QLL) pattern that increases
and decreases the number of worker processes according to the queue length of the queue, and it is an
important idea for scaling an asynchronous system. There seems to be no service that will stepping into
the current situation, but cloud vendors are hoping for cloud vendors to provide more services that will
operate in line with such best practices.
Pub / Sub queue
As the message queue earlier sends a message from one or more senders (Producer) to one recipient
(Consumer), one message sent by the sender (Publisher) Subscriber) is this Pub / Sub queue. Another way
to call it is to queue the Observer pattern asynchronously. Like message queues, they are used as
asynchronous buffers when combining functions and functions and other services.
Specific services include Amazon SNS, Azure Event Hubs, and Google Cloud Pub / Sub. All of these can
call the function registered as Subscriber and pass the received message.
As an interesting attempt, a project called "Event Gateway" that can exchange events with multiple
clouds is underway with the Serverless Framework. It is very interesting to vendor lock-in to pinch good
service of multiple clouds without fear of necessity more than necessary.
In addition, Amazon Kinesis Streams, etc. for big data streaming processing etc. can also be included in
one kind of Pub / Sub cue in a broad sense. In order to process a large number of messages, multiple
messages are passed to the function as arguments at the same time, gathered for a certain amount of time
and number.
Message queue and Pub / Sub queue are the foundation for realizing asynchronous applications using
FaaS. Cloud native applications based on event driven can be easily realized by fully grasping their
functions and characteristics, or by utilizing the workflow system services described above.
Database
In order to create some valuable system, it is necessary to save some data on the cloud side. In
traditional systems, RDBMS using SQL was common, but general RDBMS is based on the granularity of
server, connection model of stateful connection is not compatible with FaaS which is difficult to control
concurrent execution number It is common to use a scalable database service provided separately by cloud
vendors4
.
4
There are exceptionally scalable RDB like Google's Cloud Spanner. As expected a teacher ... ....

15
There are various data stores such as Amazon DynamoDB, Azure CosmosDB, etc., but all have
characteristics different from general RDBMS, and some restrictions are imposed to make it scalable. On
the other hand, it has its own function to use it like a cloud, so it is not necessarily inconvenient.
Object store
An object store for storing mainly files etc. is also important as a component of a serverless system. By
considering a pair of a path (Key) and a stored file (Value) as a kind of database (KVS), it is used as
intermediate transfer of large files and input / output with other systems.
In addition to providing a function for long-term archiving, regardless of the context of serverless,
Amazon Athena and Azure Data Lake Analytics, which provide search functions for data on the object
store, etc., for big data processing It is also used as a data storage destination.
API management
In exposing processing by FaaS as an HTTP API, various management configuration requirements come
out in addition to the request / response. An API management function responsible for these is provided.
Also, in the case of AWS Lambda which does not have the public function of HTTP endpoint itself by FaaS
itself, it is essential.
The first thing you need is authentication over HTTP. Simply, if you can do general authentication
processing in HTTP such as verification of the API header attached to the request header, the query
string, or the JWT token specified in the authorization header if it is ima dokki, if possible, please do it to
the cloud side Thing. API management functions provide such things. If it is an AWS API Gateway, even
A proprietary authentication process can be implemented as AWS Lambda as a Custom Authorizer.
There are various other functions such as API response cache, throttling that limits the number of
requests within a certain period of time, and access log storage. With Azure API Management, functions
based on a series of OpenAPI (Swagger) such as SDK, document, API test screen to support API economy
are provided. From the efforts of each company, we can see where FaaS is provided.
Cryptographic key management
Passwords for connecting to databases, certificates for external services, or personal information of users,
etc. Recent systems treat various confidential information. In order to properly protect them
cryptographically, each cloud vendor provides HSM5
based encryption key management framework.
5
Hardware Security Module: Tamper resistant hardware that cannot retrieve the data even if it breaks
down

16
In cryptographic key management, it is possible to decrypt data according to the authority possessed by
each function, and even if there is vulnerability in FaaS function by using it successfully, it is possible to
minimize the damage is. For this reason, it is essential to use the framework of cryptographic key
management for saving confidential information.
ID base / external ID linkage
In developing services that actually have users, the ID infrastructure for correctly identifying users is
important. Regardless of whether you have an authentication function by ID and password etc. on your
own, you need to manage it even on your own system even if you log in with ID or Google account like
Facebook or a Google Account. The requirement for the ID infrastructure is getting worse so far that it is
extremely difficult to implement itself, such as FIDO that changes to a password and popularization of
multi-factor authentication and recovery by mail etc. Therefore, each cloud provides ID infrastructure as a
service.
In the case of Amazon also has historical circumstances, as it is provided as a framework different from
AWS IAM framework for managing AWS itself and Cognito which provides ID infrastructure for service
users, it is easy to understand Dual management challenges remain. Meanwhile, Azure and Google use
their Azure AD and Google account in common as both ID infrastructure service and cloud management
itself, and it is first required to grasp the relationship correctly at first, but technology It is systematically
correct, even if it is large scale natural management can be done.
Media-related services
Although it comes down to a lot of uses from this point, it is something that is easy to understand as a
serverless system realization example, and media relations are putting in the power of each company.
Streaming servers, etc. are also provided mainly focusing on video and audio encoding and format
conversion.
Cognitive / machine learning
The most advanced in this one or two years is the technical area called AI and cognitive.
Services are broadly divided into two technological areas, one of which is an application specialized
service typified by cognitive. For example, analyze images and sounds, perform face recognition, emotion
analysis, text conversion, etc. It is easy to use for chat service that is compatible with serverless, and
seems to be actively used even at hands-on etc in various places. Because each cloud vendor assumes a
learning model that it owns independently, it is one of the difficult areas realized on its own.
The other is a service for more versatile machine learning. Provide an integrated development
environment including its development on the premise of combining various algorithms, whether

17
supervised or unsupervised, against Amazon Machine Learning, which provides automated simple
prediction specialized for supervised learning We are proposing various approaches that make use of
"strengths" of each company such as Azure ML, Google Cloud ML aiming at dissemination as an entire
ecosystem based on open source machine learning library TensorFlow.
In the field of cognitive and machine learning, characteristics and specialty fields of each company are
greatly different, and it seems that multi-vendor "kneading good service" will become the most popular.
Quantum computing
As a bit of a future story, quantum computing is gradually coming with a specific form.
In the first place it is a quantum computer that it is difficult for even individuals and general
corporations to have hardware, but in addition to IBM being already experimentally offering it, Azure and
Google seem to be starting efforts as well. These will also become one of "things that can not be realized
without the cloud".
Third party service
I talked about multi vendors, but it is also important to make use of third party services without sticking
to cloud vendors.
For example, as an ID infrastructure, Auth0 is a specialized business operator and provides excellent
service that fully demonstrated its expertise. As basic technology, JWT is used, and SDK for SPA and web
application framework is also provided, so development can be greatly facilitated.
Besides, there are SendGrid, Mailgun which have many achievements if sending and receiving mail, and
Twilio is stable if it is phone or SMS. It is a shortcut to improvement of productivity to reduce the part
owned by using third party that has been proven as cloud ecosystem like this in this way.

18
Summary
We divided the technology field of serverless into FaaS and Functional SaaS and explained each technical
element.
In order to actually realize the system, the "sommelier" ability to find and combine items that meet the
requirements from these is tried. Although it is "rice cake shop", it is himself who finds which rice cake is
good and which kind of rice cake meets this dish.
As an engineer who realizes the system, it is necessary to try various services on its own, but it is
necessary to further develop usage patterns and others as industry. As the design pattern of GoF is found
in programming and emphasized, design pattern in the cloud era is necessary. Fortunately, top vendors
AWS and Azure have released the "cloud design pattern" based on their services. Things that are based on
serverless, VM premises are still in confusion, but future recognition and utilization of design patterns will
advance with serverless standards.

19
3. Design Points in the Serverless Era
In order to design a serverless system, it is necessary to successfully combine FaaS and Functional SaaS
while exploring possibility and reality. Among them, it is important to know important concepts in a
distributed system which is essence of serverless.
In this document, we will cover the "Reactive System" which shows the design principles of scalable
systems in an easy-to-understand manner and "Identity Management" which supports the realization.
Reactive System
Technical term "Reactive " has been heard in recent years. The most known one will be reactive
programming such as RxSwift. As for organizing this reactive clan, it is easier to understand "Why
Reactive is Important"6
because it is easy to understand, so the important thing here is "Reactive System".
The reactive system is a set of design principles for realizing a modern system, and four features are
introduced as "Reactive Declaration"7
. For the convenience of the page, the following are roughly shortened,
but by all means read the full text of the reactive declaration (translated into Japanese by volunteers)!
Responsiveness (value to realize)
In order to make such a system that keeps the response time fast and stable as the whole
system ... ....
Fault tolerance (nonfunctional requirement)
Even if a failure occurs, it isolates the influence inside the component, thereby maintaining the
responsiveness as the whole system. For that reason, suicide bombs if abnormality occurs. Then
the message remaining in the queue will be handled by another worker process. Funny messages
on other workers will be transferred to Dead Letter Queue and exception handling will be done.
Elasticity (nonfunctional requirement)
Even if there is an increase or decrease in the load, eliminate the bottleneck and adjust the
resources to be allocated to keep quick response. Therefore, as the number of messages waiting to
be processed in the queue increases, we will increase the number of worker processes. There is no
interdependence between side-by-side workers, so you can easily scale in and out by increasing the
number of processes.
6
http://www.slideshare.net/okapies/scalamatsuri-58141520
7
http://www.reactivemanifesto.org/ja

20
Message driven (architectural configuration requirement)
In order to realize these, we make such an architecture that keeps the message queue between
each component loose coupled, multiple worker processes asynchronously fetch from the queue and
process.
By designing while considering these four features, it is possible to realize a high quality and large scale
system. It is not a completely new concept, rather it is a result of organizing the items that would be
considered natural if it were a large-scale system without knowing this reactive declaration. If the well-
introduced "The Twelve Factor App" is a best practice in application development, this reactive declaration
is a best practice when considering the architecture of the entire system.
The essence of so-called "serverless", "a system that realizes a combination of various components, mainly
in serverless application execution environments" is well organized under the concept of this reactive
system. In order to realize a large-scale system, the nature of the reactive system is necessary, and a
suitable server-less application execution environment is provided as a tool for that.
Identity management
If it is a traditional monolithic application, the application itself is responsible for all user access control,
and both user authentication and processing access authorization are completed within it. So, the database
and file system on the back side of the application, and the components of the external cooperation part are
all sufficient for one application authority.
On the other hand, in the case of a serverless architecture in which various components directly interact
with each other, sometimes the application itself does not intervene, all components correctly identify the
user and authorize access to the respective resources Is required. It is the ID management that becomes
important here.
As a representative example, I will address ID management and access management in AWS.
The AWS IAM (Identity and Access Management) framework is centered on access management in
AWS. IAM manages access to AWS in two ways. One is a general user and group framework, which sets
"policy" which defines direct access authority to users registered on IAM. Another is "role", not only for
users on IAM, but also for users on external ID infrastructure linked with SAML 2.0 and OpenID Connect,
instances of Amazon EC 2, applications such as Lambda function of AWS Lambda can.
AWS Security Token Service (AWS STS) realizes control by this role. AWS STS is a service that issues
an access key with a short lifetime (1 hour) called "temporary security authentication information" based on
ID based tokens and Amazon EC 2 metadata. By using this access key, users can directly use various

21
components of AWS. In addition, each component can properly perform access control based on the policy
set for the role.
In addition, it is hard to understand because it is branding as for mobile, but in the service called
Amazon Cognito, the ID infrastructure called Cognito User Pools and ID cooperation function called
Cognito Identity are provided. By combining these, we realize a process where users authenticated on
Facebook save files directly to Amazon S3 and access control so that they can not be operated by others,
without using EC 2 or Lambda can do.
In this way, by placing multiple components on the ID infrastructure, you do not have to deal with
"implementation of dirty access control", which in turn improves the scalability of the entire system.

22
4. Practical pattern of serverless architecture
So far we have introduced the serverless architecture, the service of each cloud provider and the way of
thinking behind it. Based on these, we will look at the pattern of serverless architecture.
This pattern is imagined immediately.
Not only the mobile application, which is an application from the former to the front side but also the
web application on the browser, the backend has only the API and the pattern of implementing the
rendering with browser side JavaScript has spread. By accessing the data store etc. directly, it is possible
to reduce the number of items to make and maintain scalability.
As a sample, examples of file uploaders are often introduced with concrete source code, and this is the
pattern I would like to suppress as a sample of serverless architecture.
Cloud-based event processing
Asynchronously performs various processes with 'Event' on the cloud infrastructure as a trigger.
As an illustration, when a movie file is uploaded to Amazon S3, it is triggered to make asynchronous
processing that takes time such as conversion of file format, or analyze flow logs to find a specific log by e-
mail Sending, increasing the number when the load on the server becomes over a certain amount, various
use is found.
AWS Lambda got a lot of attention at once because I thought that because of its serverless nature, I got
a lot of triggered "events" in various components of AWS.
Streaming event
It is a pattern that processes queued events sequentially by streaming.
For example, when pushing to the master branch of GitHub, an event is thrown to Amazon SNS, AWS
Lambda which received it executes the deployment process, receives new arrival message from Slack from
webhook and realizes so-called ChatOps, recently, LINE An example of implementing Bot can also be seen.
For such a chat system, since the communication frequency is low, the cost saving effect by FaaS is also
clear, and it is a perfect pattern for those who want to make something serverless quickly.

23
Especially this field is expected to grow in the future because it can be used to analyze sensor data
collected from IoT devices. For example, everyone Sorachi has a function called SORACOM Funnel which
pours data into Amazon Kinesis and Azure Event Hubs, and instead of a low-function IoT device, AWS and
Azure authentication, credential management, and encryption She takes care of me. The IoT device side
can use this kind of thing anyway to pour sensor data into the queue on the cloud side and compile it in
real time with AWS Lambda or Azure Functions.
It is charged at the execution time based on the flow rate and maintains the scalability well, so if you
imagine that this was done on a large scale by increasing the number of servers one by one in the past, it
is a good world I feel that it became.

24
5. Overview of each company "serverless"
FaaS and Functional SaaS are released from each cloud vendor with "serverless" as the key word, but
first we will look at the efforts of each company as a whole.
AWS Lambda
Whatever the circumstances, anyone can recognize that AWS, the biggest public cloud player, was a key
player in the spread of serverless. AWS Lambda released at the end of 2014 by that AWS. With AWS
Lambda as the core, we position the various components as "AWS serverless platform" as a whole. Many
achievements are many, and the biggest feature is that there are many information.
In AWS Lambda, the application is managed in units of "Lambda function" as its name implies. This
Lambda function can be described in JavaScript (Node), Python, Java8, C #, it is charged as the sum of the
computing fee according to the secured memory amount and the actual execution time and the request fee
corresponding to the number of times of execution It will be. The amount of secured memory can be
specified in units of 64 MB from 128 MB to 3 GB, and since the execution time is measured in units of 100
msec, it can be said that it is almost "the amount used". By default, the number of concurrent executions is
restricted to "Safety Limit" to 100, but you can request a raise to support if necessary. Contrary to the
name of "memory amount", CPU time actually allocated seems to be proportional to this, "If you finish it in
a short time by allocating it to abundance rather than taking time to stick with memory In some cases it
will be cheaper ".
Based on the actual use case, it is the strength of the leading group that the necessary framework of
cooperation has already been established. "We have everything we need for the moment" is the strength,
and we can call AWS Lambda from most of the services of AWS to be able to throw various events, so the
impression that you can realize what you want to do in a brief shortly there is.
In terms of ecosystems such as deployment tools, they are already mature, and tools with sufficient
functions and achievements such as Serverless Framework, Apex, or Terraform are available. There is
nothing to worry about, it is important to take a new field.
Although AWS Lambda itself has been in existence for nearly three years since its appearance, detailed
features such as implementation of Dead Letter Queue and correspondence to Node.js v6.10 and external
maintenance such as SAM (Serverless Application Model) and Step Functions Although it is being carried
out continuously, there are points that I feel inconvenient in the basic part when compared with other
company's FaaS. In general, AWS tends to devote itself to building blocks until a pattern is established to
some extent by the ecosystem, but we are looking forward to a big update soon.

25
Azure Functions
While AWS is the champion of the public cloud, Microsoft Azure is catching up with that AWS furiously,
at least in terms of vision. The application execution environment that Azure provides is Azure Functions.
It was officially released in November after a preview release in March 2016.
I
execution time) and the number of requests similar to AWS Lambda, the charging model is a dedicated
VM as well as the old PaaS service "App Service" There is also an "App Service Plan" secured and charged
in that number of hours. It seems to be taken into consideration when you want to use Azure Functions
with surplus capacity when using App Service already. Nonetheless, since the App Service plan is
somewhat off as serverless, once forgotten it is basically the same as AWS Lambda.
Unlike AWS Lambda, which specializes in pure function execution and assumes simultaneous use of
other services and tools, Azure Functions allows external publication as HTTP API, integration with CI,
debugging from Visual Studio, etc. as FaaS Are integrated and can be executed as it is without thinking
too deeply. I feel the advantage of the late generation, such as the mechanism of input and output binding
added to the trigger, integration with the development environment (Visual Studio, VS Code, etc.), the
number of languages supported.
By preparing a mechanism to save the internal state of the function, it is possible to stop / restart in the
middle like coroutine, Durable Functions that can implement the entire workflow in a long time as a
function, custom bindings that can cooperate with your own service, FaaS Expansion of itself is actively
carried out.
Not only FaaS, but also cooperation with other services has been released like every month, but instead
of directly linking each service and FaaS, you can use Event Grid, which is a generic event routing
(message queue) Such as CosmosDB which can handle not only KVS model but also RDB table and graph
DB etc, are well-designed and attractive services are gathered.
Among latecomers, there are impressions that are specifically designed with emphasis on ease of
development.
Google Cloud Functions
Google, which continues to drive large-scale data processing technology on the Internet, is also the origin
of "serverless architecture" in the first place.

26
The Google App Engine preview released in 2008 fully satisfies it as a serverless application
environment that the execution environment is scaled fully and there is no need to consider a unit called a
server and it is charged with CPU usage time It was. However, the impression that Google provided
externally a serverless architecture execution environment designed by himself externally for reasons such
as being changed to billing on an instance basis at the time of public release and the data store's usability is
too strong It was a strong one. After all, although it is deeply used only in a part, it did not become widely
used at all.
Seven years later, while competing AWS succeeded in Lambda, this "Google Cloud Functions" appeared
in February 2016, incorporating its success factors.
In addition to the original serverless Google App Engine (GAE), Google Cloud Platform (GCP) is
preparing Google Cloud Functions that looks like Lambda. Although it is still in beta at the time of this
writing, unlike the alpha era, general users can also try it. The biggest feature is that it provides both GAE
which can be scalable even for relatively large applications and FaaS model as rediscovered in AWS
Lambda. As for GAE, there is information already dead, so we will not cover it in this book. The
characteristic of GCP is that Google himself holds the top share on Android mobile platform and has one of
Firebase's most powerful mBaaS with it. Firebase Realtime Database, which is a distributed data store that
can synchronize data with the terminal of Firebase in particular, is extremely powerful, and it seems that
it will spread rapidly as the foundation of mobile application already using Firebase.8
As for the direction of GCP itself, I think that there is a strength in the execution environment for each
application container rather than FaaS, but a serverless data store such as BigQuery has a day length, and
one day yesterday Even if one sees it, I feel like I am advancing the royal road as computer science. It is
no doubt that it is one of the companies doing the business that utilizes the most data in all the world.
To Google of the original serverless architecture, I want you to keep sticking while giving another charm
different from other companies.
IBM Cloud Functions
IBM Cloud Functions is providing open source Apache OpenWhisk on the public cloud. It was officially
released in December 2016 to line up with other companies.
IBM Cloud Functions was called Bluemix OpenWhisk until August 2017. In order to differentiate its
brand from Apache OpenWhisk which is an open source execution environment, the name of the cloud side
service has been changed. The biggest feature is that the execution environment is open source as above.
We have also integrated with Docker, so we can consider the HTTP request as a function and use the
8
AWS Cognito Sync

27
Docker container like FaaS. Even with Node - RED, the approach of making the execution engine body
open source from the beginning and providing it as a cloud service seems to be the direction of the whole
IBM.
Although IBM is one step behind as both serverless and cloud vendor, it is showcasing "server-less form
to be seen" that exploits the advantage of later generations such as "Composer" which proposes a
programming model in FaaS I think that I want it.

28
6. Comparison of FaaS
First of all, we will compare each service, centering on FaaS which is a serverless initiator.
In order to build a system without server using FaaS, you need to know the nature of FaaS and
Functional SaaS used in combination. Instead of a program implemented in a general-purpose language,
there is a "coding-less" wave that can define its behavior only with DSL (SQL, configuration file, etc.), but
redesigning all common applications with FaaS It would be difficult for FaaS to replace it with DSL alone,
as it is difficult. It is not a DSL if it is possible, it is a generic language anymore.
Speaking of the function, I think that many people now have images in functional languages such as
subroutines without side effects with arguments, but in the context of serverless, the "function" in the
context of the server is the whole program and In contrast, it seems to have only the meaning of "unit of
small subroutine".
Although there is a tendency that the later generations are thought well as a tendency, since everyone is
good at cloud originally, it is not necessarily which one is better. In this chapter, we will look at differences
of serverless environments of each company from several viewpoints.
Function interface
What is common to each company FaaS is that only events are passed as arguments to some functions,
the contents of their arguments, handling of return values, etc. are the points where each company's
"sense" comes out.
AWS Lambda, Google Cloud Functions, and IBM Cloud Functions are almost the same, and the caller's
event is passed as an argument as it is, and when it is called via API, HTTP request, etc., the return value
becomes synchronous in response, When called asynchronously by driving, the return value does nothing in
particular. On the other hand, it is Azure Functions that the interface is built considerably, and it is
possible to set multiple input bind / output binds in addition to "trigger" which calls the function. I will
introduce this in detail later in the column of Azure.
Handling of arguments and return values when using as HTTP API is also various. In AWS, Lambda
alone has no processing capability for HTTP request, and it is necessary to set yourself how to handle
requests and responses with API Gateway together. While the flexibility is high, the format of the
argument / return value largely changes depending on the setting of API Gateway, which is also a
disadvantage that it is hard to generalize. With Google Cloud Functions, the language is currently only
e object is passed as it is. Although it can be said to

29
be a kind of division, it is a good thing to be able to implement it in a way that is familiar to experienced
users of web application development.
However, "heresy" is the Docker-action of IBM Cloud Functions. You can execute your own binary built
on it using FaaS, using the container image created on Alpine Linux based template image.
In the case where there is a business logic exceeding just the format conversion, it is important not to
directly implement it for each individual interface of each cloud, but also from the viewpoint of software
engineering such as improving portability across well abstracted adapter layers is also important It will
come.
Function trigger
The following table compares with "trigger" which can activate the function.
AWS
Lambda
Azure
Functions
Google
Cloud Functions
IBM
Cloud Functions
Direct
execution
Built-in Built-in Built-in Built-in
HTTP With API Gateway,
CloudFront(Lambda@Edge)
Built-in
With Functions Proxies
With API Management
Built-in Built-in
Periodic CloudWatch Events Built-in Built-in
Message queue SNS
Kinesis Streams
Storage Queue
Service Bus
Event Hubs
Event Grid
Cloud Pub/Sub Message Hub
Data store S3
DynamoDB
Cognito Sync
Storage BLOB
Storage Table
CosmosDB
Cloud Storage Cloudant
Management CloudWatch Logs
CloudWatch Events
CloudFormation
AWS Config
CodeCommit
Kinesis Firehose
(webhook) (webhook) (webhook)
Chat bot Amazon Lex Bot framework
Mobile/IoT Smart speaker(Alexa)
IoT Button
Firebase Mobile-app
(Push Notification)
other Mail(SES) Office365(Graph)
The big difference is that AWS Lambda does not receive HTTP requests on its own, so it can be called
relatively closely with various services, there is not much difference other than that. However, as you look
closely, you will see what sort of companies want to build serverless systems in what fields.

30
Data Store
Since FaaS can not store data for a long time due to the constraint, it is necessary to use another data
store. Since the program itself can run without FaaS serverlessly, if the database server is tied to "server",
there will be no merit, so we will use a natural and serverless Functional SaaS database. At this time, it is
difficult for everyone to satisfy the CAP theorem, which satisfies the properties of general RDBMS,
serverlessness scaled internally, and generally required availability. Therefore, a serverless data store is
unique as it is constrained by some restrictions compared with a general RDBMS.9
Each company provides a data store for serverless architecture. One of the oldest and simple ones is
Amazon S3, which is also the catalyst for the spread of cloud computing. Such object storage is a kind of
KVS that can be accessed by path name, and although it is different in the other functions even in other
clouds, it is provided in roughly the same feeling.
On the other hand, it is safe to save and use the data store that is good at full scan from the whole like
Gig BigQuery, Amazon DynamoDB and Azure Cosmos DB of document type KVS like MongoDB, secret
key of public key cryptography Choose what you see in the requirements from the data store with various
features such as AWS Key Management Service (KMS), Azure Key Vault, Firebase Realtime Database
suitable for data synchronization with mobile terminals, Amazon Cognito Sync I can.
One aspect of the "serverless" technology movement is to positively promote the "rice cake shop"
strategy that combines the function-specific components provided by the cloud in this way. Compared to
the combination of general-purpose RDBMS and applications created on a general-purpose framework,
there are risks of individual component learning costs and vendor lock-in, but on the other hand, the
amount of development that you can not go without first creating It reduces the risk of malfunction due to
it, which has the merit of reducing it drastically. As for the data store, this judgment will be especially
demanded.
Messaging service
The most important point is how to combine FaaS with the messaging service provided by the cloud to
build the system based on message driving.
Each cloud provides messaging services with various properties like datastores, but it can be roughly
divided into two types. The first is message queue. Message Queuing basically guarantees that the
message sent by the sender (Producer) to the queue will surely reach someone (Consumer). The other is
9
In the case of access from FaaS where the number of concurrently executing tasks changes as necessary,
it is difficult to manage the number of connections in a typical RDBMS.

31
the Pub / Sub queue, and the message sent by the sender (Publisher) reaches all systems (Subscribers)
subscribing to Pub / Sub. In addition, it may be provided as several different services for different use
cases.
For example, in AWS, two mechanisms of Pub / Sub are prepared. One is Amazon SNS. Lambda will be
invoked separately each time an event occurs. Ten e-mail form processing is affordable and realistic, but if
you try to process an event that occurs once a second, for example, you will be running 2,592,000 Lambdas
individually in 30 days, It is inefficient. For that, another Pub / Sub queue called Kinesis Streams is
provided. Kinesis Streams is designed to process continuously generated streaming data, and when calling
Lambda, it can be passed together with the amount of data specified at the time of setting.
Also, rather than using your own direct messaging service, there are more cases of being internally
messaged within a higher level framework. AWS Step Functions can realize one workflow by combining
multiple functions, but messaging that hands out the output of one function to another function is done.
Mechanisms like Azure's Durable Functions that can implement message collaboration between functions
as higher-level functions are also appearing.
The messaging mechanism that links FaaS and Functional SaaS like this supports the serverless
architecture behind the scenes. This understanding is the most important part in order to realize a large-
scale system cheaply in a serverless architecture.
Development with FaaS
Anyway, unlike traditional software development which had only prepared the execution binary of Linux
x86_6410
and even the dynamic library called from there, FaaS which directly calls the function, the
language to be implemented, how to deploy it, etc. must obey each cloud style there is.
Available languages
Selection of languages is one major challenge when actually developing on FaaS. We compiled the
languages available for each FaaS.
10
Needless to say there are cases of Windows, BSD, JavaVM etc ... ....

32
AWS
Lambda
Azure
Functions
Google
Cloud Functions
IBM
Cloud Functions
JavaScript
(Node)
Node v4.3.2
Node v6.10
Node 6.5.0 Node LTS release
(v6.11.1)
Node v6.9.1
Python Python 2.7 [experimental]
Python 2.7
Python 2.7.12
Python 3.6.1
Java Java 8 Java
C# .NET Core 1.0.1
(2.0 at future)
.NET Framework 4.6
(Go at future) [experimental]
F#
PHP 5.6
Batch(.bat)
Bash(.sh)
PowerShell(.ps1)
Swift 3.1
PHP
Docker
It is interesting that both correspond to Node, but Python and C # have expanded the operating
environment after that. As introduced in the whole picture, IBM Cloud Functions corresponds to the
Docker container, so it is distinctive that it supports FaaS like variety of binaries. However, since details of
its execution environment are made public in other clouds, it is possible to bring binaries that work there,
from Node etc. In that case, it is a realistic assumption that the startup of Go etc etc is a light language as
the process starts up newly every request.
Also the range of corresponding languages in Azure Functions where the execution environment is open
source is also interesting. In Bash and Batch, it seems that arguments are included in the file name passed
as a variable. Like Docker of IBM Cloud Functions (Apache OpenWhisk), efforts are made to successfully
incorporate what is not a function into the world of FaaS.
Deployment
In the case of general software so far, the entire package is organized as one package, but in FaaS, the
management unit on the cloud side becomes a small function, and it is necessary to manage multiple
functions constituting one software collectively Is required.
Depending on the function, management of dependency libraries, etc. will be done for each function, but
later generations such as Aquire, GCP, IBM, for example, importing dependent packages such as Node's
npm install etc are automatically executed as part of the deployment. Particularly in Azure, coordination
with GitHub is built in, so it is possible to easily realize the automatic deployment of a specific branch in
the repository on GitHub by clicking on the control panel. GCP can also do the same with Google's Git
repository service, Cloud Source.
On the other hand, at AWS Lambda, when deploying, you run your own work such as running npm
install etc and packing it into a ZIP file for each node_modules. There are CI services such as CodePipeline
in AWS, but even when using them, it is necessary to set up processing of dependency packages yourself.

33
These parts are regrettable because the starting AWS Lambda looks old. Nonetheless, the ecosystem of
frameworks with deployment capabilities is well developed due to the starting stages, and this itself does
not constitute a barrier to AWS Lambda.
Application framework
Apart from administrative tools such as Serverless Framework and Apex, AWS is primarily appearing
as a framework for easily implementing serverless applications that have stepped into code contents.
One is Chalice11
which AWS himself publishes. It is provided as a library for Python, and based on the
Python source code like a general web application, it performs various settings such as AWS Lambda, API
Gateway, IAM, and takes care of calling Python code as a handler function of Lambda I will see.
Another is Zappa12
. Although it is also based on Python, it automates the management of a wider area
than Chalice. Internally I am on WSGI, a common HTTP request handling mechanism in Python, so if I
want to move to a location that is not AWS Lambda, I can port it to Python's application server as it is.
Zappa developers themselves seem to be interested in responding to OpenWhisk.
ClaudiaJS13
is the last one to introduce. Contrary to the name is for AWS, not Azure. It is a framework
for Node that will automatically set API Gateway and other settings by defining handlers for HTTP path
similarly as ExpressJS. It is also powerful that various sample codes14
are released.
Debugging
In the past, the cloud side directly called the function call of individual processing which was handled by
the library on the software side such as web application framework. Therefore, you need to put debugging
and testing on the cloud side, or reproduce the cloud side FaaS execution environment locally.
Personally, I think that it is straightforward that the flow of integration test by actually deploying it to
the test environment on the cloud while checking finely with the unit test that mocked the interaction with
Functional SaaS.
By combining Azure CLI with VS Code or Visual Studio, Azure Functions seems to be able to perform
normal debugging using breakpoints etc. by attaching locally executed functions. It is said that Microsoft is
11
https://aws.amazon.com/jp/blogs/developer/preview-the-python-serverless-microframework-for-aws/
12
https://github.com/Miserlou/Zappa
13
https://claudiajs.com/
14
https://github.com/claudiajs/example-projects

34
the only one that has its own development environment with a long history. Local debugging can also be
done from VS code for Mac, I feel that the times have changed considerably.
On the other hand, AWS has begun to acquire Cloud 9 of the cloud type development environment and
started to offer it as AWS's own service, release competition set in the development environment is
beginning to intensify. Competition in this field seems to be the most interesting in 2018.

35
7. Serverless application execution env other than FaaS
FaaS is not the only environment that can run applications without a server. Here we will introduce the
use of such things.
Application container
As we have written in the Concepts section, we introduce the Azure Container Instances and
FastContainer architecture as an environment that can run applications without a server, based on
application containers.
Azure Container Instances allows you to launch Docker's application container in seconds and charge it
in seconds of execution time. It satisfies the serverless nature that the registered code is executed as much
as necessary and the required environment is managed by the cloud vendor. Although the serverless
application execution environment requires various constraints, you can see that "being a small code called
a function" that is derived from the name FaaS is never a condition in serverless. It is quite interesting to
take into consideration whether it is serverless if the start-up processing is sufficiently sufficient in
discussing "difference with PaaS" earlier.
The Azure Container Instances can not scale out by itself, it must be an application that requires only
one simultaneous execution, but it can also be scaled by combining with other orchestration tools. Indeed
aci-connector-k8s that can use Azure Container Instances as pods on Kubernates is released.15
As AWS also follows, we released AWS Fargate which can run the Docker container elaborately in full
managed as well as Azure Container Instances. In addition to being combined with the container
management service Amazon ECS already provided by AWS, cooperation with the Kubernates Managed
Service EKS which is announced at the same time is scheduled.
GMO Peperbo also advocated a FastContainer architecture not dependent on the unit called function, and
released the closed alpha version of "Lollipop! Managed Cloud" based on it. It is an architecture that
dynamically controls the operation of the application container based on the HTTP request, and it can be
said that the autoscale processing which AWS Lambda etc actually performs internally has been
rearranged without regard to the function form I will. Because it is a general HTTP container-based
application container, it is possible to move legacy applications such as Wordpress as they are.
15
https://github.com/azure/aci-connector-k8s

36
Streaming SQL
Those used by the application container were so-called "full-featured" execution environment to run
serverlessly, but as a truth opposite to that, services for moving specific applications for applications using
DSL are appearing . We will introduce Amazon Kinesis Analytics and Azure Stream Analytics as a live
environment to be driven event driven using SQL which is the most used DSL in the world.
By using SQL of a type called streaming SQL, it is possible to output consolidated results one by one for
consecutive events flowing from the message queue, or aggregate results for each unit delimited by time
etc. I can do it. There are also open source processing engines such as Spark Streaming and Norikra in this
field.
One use case is format conversion. In order to recognize standard formats such as JSON and CSV, you
can convert from it to another JSON format, convert the unit by arithmetic operations etc. to values. You
can also JOIN values from more than one data source, so you can give the result of fetching from the
master data to the flowing data.
The other is aggregation processing every fixed time. For example, counting the number of tweets that
flowed on the Twitter timeline, you can see that something big happened, such as an earthquake, if the
number of people who wrote in the last 5 minutes was large. Up to now it was necessary to compile with
batch processing, micro batch with shorter cycle, etc. However, with streaming SQL like this you can get
results in almost real time. The tallying window also has a tumbling window such as 00: 00-04: 59, 05: 00-09:
59, 00: 00-04: 59, 01: 00-05: 59, 02: 00-06: 59 You can choose several methods, such as sliding windows like.
Since it is impossible to do anything beyond what is defined in DSL (in this case, streaming SQL), it
reduces the possibility that problems will be misplaced during design and implementation. Utilizing such
"rice cake shop" supports productivity improvement in the context of serverless.
Flow-based programming
As an application by DSL, there is flow-based programming also covered in the concept section. Combine
parts such as Azure's Logic Apps and IBM's Node-RED to create a data flow and build up a system.
Although it looks like a bit, it looks like "toy", for example, IoT's PoC (demonstration experiment), etc. It
is used as a tool to realize something easily, and even a somewhat complicated system is restricted by DSL
Because it can realize few defects, it is worth considering.

37
8. Serverless operation
With the "rice cake shop" strategy, there are various points in operation in serverless which leaves most
of the software execution to the cloud side.
Deploying Functions
For example, if it is AWS Lambda, we will also use the following components other than Lambda before
actually executing the program.
Access privilege of the side calling Lambda function is set by AWS IAM
The access authority when the Lambda function itself is executed is set by AWS IAM
Set up each component used by Lambda function
Locally packaging libraries etc required for Lambda function operation
Deploy packages containing Lambda functions with AWS Lambda
The API Gateway sets authentication and call limit when the Lambda function provides as an
HTTP API
Debugging by retrieving the log output by the Lambda function with CloudWatch Logs
To be honest, there is nothing nearly as easy as typing them in the management console or CLI, so there
are administrative tools for managing them.
Serverless Framework
The most used is this Serverless Framework.
It targets the entire system that assembles with serverless, such as setting the endpoint of HTTP API
with API Gateway, and matching plug-in with detailed settings other than Lambda.
As the huge name "serverless framework", you can deploy to various FaaS environments such as Azure
Functions, Google Cloud Function as well as AWS Lambda.
Apex
Anyway Apex is the one that hides the muddy processing necessary to deploy and execute the Lambda
function in AWS Lambda. The function of Apex itself is simple, but it can also be combined with

38
Terraform of HashiCorp, and if it is a small project you can manage the configuration of dependent
components as well.
I use Apex primarily, but at least in current AWS it is merely masochistic to operate Lambda based
applications without tools so let's try the tool before getting tired.
Monitoring (logging, metrics)
It is often said that even if you do not think about a server without server, it does not mean that the
operation monitoring itself will not go away. However, unlike the era we saw on a per-server basis, we
need a different viewpoint of monitoring as a whole system.
For example, metrics such as logs and resources of applications are not saved by themselves, they are
first incorporated in the cloud side saving function and referred to, retrieved and processed. Also, although
you do not need to look at the CPU, memory, and disk free resources for each server, you need to check
the amount of resources used in the cluster as a whole and the aggregated logs. Even if there are
unnecessary processing due to trouble etc, if it keeps the constraint as much as it is scaled, it will be
uselessly moved and cost will be multiplied.
This part is strong is GCP which acquired Azure with piling up from the PaaS era and Stackdriver
company of the watch SaaS by acquiring it all. On the other hand, in the case of AWS, although there is
the minimum function of log preservation and metric display, we will use external NewRelic etc etc for
stepped application monitoring (APM) etc. In addition, AWS X-Ray which can track processing between
components is released, and there are also IOpipe etc. as third party.
Since we are entering the era of building large systems by combining functions, whether we can
comprehensively monitor the whole is an important point in the future operation of serverless architecture.
Perhaps in the next few years, the ecosystem will be expanded, or the cloud operator will be involved in
large-scale uptake and enclosure.
Managing Execution Permissions
The fact that the software becomes a function unit makes it possible to assign only the necessary
minimum privileges according to processing individually for each function. Therefore, it is necessary to
fully understand the role (role) based authority management mechanism prepared by each company.
First of all, AWS prepares a framework called IAM, and in Lambda it controls with two types of
authority. One is the execution role of the Lambda function itself and assigns a role called IAM Role. The
other is a function policy on who can call when another component calls Lambda by message driving.

39
Although it is complicated, because there is a framework of function policies, you can also allow calls to
cross AWS accounts. Even Azure Functions seems to have a similar framework as Role-Based Access
Control of Azure as a whole.
On the other hand, Google Cloud Functions does not yet implement separate access controls, and
automatically grants Editor rights for the entire account. Therefore, it is possible to access the components
in the same account without setting in particular. It is still last year that detailed IAM management was
prepared for the entire GCP, so at the time of official release of Cloud Functions, it seems that GCP's
service account and role control framework will be prepared.
Functional SaaS management
FaaS is inseparable from the management of Functional SaaS including data stores and queues.
There are two main approaches. One is to use the resource management framework provided by each
cloud. CloudFormation for AWS and Azure Resource Manager template for Azure are provided as a cloud
side function. As a matter of course, we can respond quickly to new functions and it is easy to start using
it because it closely cooperates with the control panel etc. On the other hand, it is not possible to describe
everything with "external" components of the cloud or with one definition when "clutching" multiple
clouds.16
Another approach is to use a third party configuration management tool such as HashiCorp Terraform.
Because it is developed as open source as a configuration management tool, there are abundant support
functions such as collective management including multiple clouds and external services, complicated
conditional branching and so on. On the other hand, it takes time to respond to clouds other than AWS
developed ahead of time and new services. Cooperation between Azure and HashiCorp was announced the
other day, but the cooperative relationship between cloud vendor and ecosystem becomes important.
Although both have advantages and disadvantages, I personally feel that if you use it for your own
service Terraform, if you deploy it to a third party as a template, it is better to use the template function
on the cloud side.
16
It is basic AWS, but I will use BigQuery, I listen carefully to examples.

40
9. AWS Lambda
Characteristics of FaaS
Execution environment
The Lambda function runs on an application container based on Amazon Linux. Since it is possible to
create temporary files and execute other programs, it is also possible to bring libraries and execution
binaries that need to be compiled for each architecture. As it may take seconds to initialize containers and
Lambda functions, the container will not be terminated immediately after a single request but will be
reused as well. The time of "waiting for reuse" or "initialization processing" is not basically charged, but in
order to avoid misuse by avoiding accounting by making heavy processing in "initialization processing", a
certain timeout It seems to be charged if it exceeds the time.17
This binary bring-in is compatible with light languages such as Go that have libraries as languages with
few dependent libraries, and Apex of Lambda deployment tool builds Go and calls parts called from Node I
hide it well so that I can make it available as well, even as Go supports Lambda.
trigger
You can also call the Lambda function directly using the SDK, but you can also trigger "events" that
occurred in various components of AWS. By integrating this whole AWS into Lambda, various systems can
be realized with minimal code. This trigger event source has a wide variety as I have already written.
This is also an inside out that Lambda itself does not directly correspond to HTTP and can not receive
webhook.
Billing system
It is apt to overlook the fact that CPU quota is also proportional to memory allocation, so if you are using
a function that hardly uses memory, if you set it to 128 MB etc, the CPU performance is also much lower,
It will happen that it will increase. It is necessary to adjust while viewing the execution log output to
CloudWatch Logs around here.
17
http://d.hatena.ne.jp/cero-t/20160106/1452090214
Why is AWS Lambda + Java heavy in the first and third processing?

41
Features of Functional SaaS
DynamoDB
As a database that can be used from AWS Lambda, you will basically use DynamoDB. This DynamoDB
is a very simple distributed KVS. Throughput capacity parameter is prepared, and you can secure "total
throughput" for each writing and reading. It will be charged according to this secured throughput capacity.
Throughput capacity is defined as the amount of data per second, and it is consumed for each writing
(reading). If the capacity is insufficient, calling the API will result in an error. It is a part that needs
monitoring for operation.
If you increase the amount of data or secure a large value for throughput capacity, the data is
distributed in units of partitions. Conversely, it is said that while the data volume is small and the
throughput capacity is small, it is not distributed and the performance itself does not improve. Although it
tends to overlook here, even though performance can be ensured in parallel requests in parallel, the time
limit of one process (in particular, when executing Lambda via API Gateway, there is iron rule of 30
seconds) If there is, there are cases where it can not be improved. It is necessary to design this whole
system by folding this part.
Since the autoscaling was implemented in 2017, it became possible to dynamically secure several times
as much as it was based on the actually consumed throughput. Previously, I could do the same thing by
myself by controlling with AWS Lambda etc, but it became much easier as it became possible only by
setting to DynamoDB. Internally it seems to be based on CloudWatch's alarm function.
DynamoDB itself is a service that is fully redundant, but backups are necessary to prepare for mistake
operations. There is no function like a standalone backup / restore, it exports to S3 via EMR using AWS
Data Pipeline. In some cases, it is also an option to save it to S3 etc etc at the same time before entering
DynamoDB.
In addition, it is troubling that BatchWriteItem operation which makes multiple updates at the same
time up to 25 requests at one time, the result set size of Query and Scan is unexpectedly small to 1 MB. If
you repeat the "refilling" process, you will also be stuck with the 30-second limit on the API Gateway. It is
not suitable for dealing with such large data at once, and it is necessary to incorporate raw data storage
into S3 and use of Redshift from the design stage.
"DynamoDB Streams" which delivers the change history made to DynamoDB to AWS Lambda is quite
effective in a bit of event processing which is not so high as to use Kinesis Streams introduced later. Also,
since DynamoDB can access directly from mobile applications, etc., you can also perform black box
processing etc. on the cloud side based on the result received by DynamoDB. Although it has a habit

42
compared to a general queue, I think that it is an interesting function that you can easily combine
persistent data store and queue.
By the way, there was a scalable NoSQL data store named Amazon SimpleDB long ago, but it seems to
be also deleted from the service list and integrated into DynamoDB.
Amazon S3
Although DynamoDB is a relatively new data store, on the other hand, S3, which is the oldest service of
AWS, is also excellent as a data store in a serverless system. When considering S3 as a general-purpose
KVS, rather than considering it as a mere Internet-enabled file server, the range of feasible systems will be
expanded.
Although both can be said to be a kind of distributed KVS, DynamoDB has two stages, a hash key and a
range key, and it is possible to perform order search with the range key for the data group of the same
hash key. S3 is a simple KVS, and you can only search data by prefixing the path name. Instead, for
DynamoDB which is thinner in cooperation with other services, S3 can be used as a more general
distributed data store, for example as an input / output of Elastic MapReduce, or directly to the file group
on S3 at Amazon Athena You can throw queries or use huge as a storage place for media files and so on,
so you can use it in various ways.
Since S3 can also call AWS Lambda when saving data in the same way as DynamoDB, it can be used as
the starting point of "Pythagora device" which connects various processes based on files uploaded directly
from mobile applications etc. It seems to be large.
Also as a billing system, the concept of "securing" like DynamoDB is unnecessary, and it is extremely
good to just use it if used purely.
Kinesis Streams
In order to handle real-time data in Lambda it will be combined with Kinesis Streams.
This Kinesis Streams can be load balanced into multiple "pipes" in units of shards and associates one
Lambda process with each shard when calling Lambda. The "partition key" at input time is used for
dividing into shards, so the degree of dispersion of this partition key is important. In other words, the
concurrency number of Lambda is limited by the partition key when entering data, so it is necessary to
take the whole into control of the bottleneck.
In this way, the degree of parallelization of Lambda is limited by the degree of distribution of the
partition key at the time of input to Kinesis Streams. Although you can control if you are submitting it to
Kinesis Streams yourself, in cases like directly inputing from an external cloud adapter like SORACOM

43
Funnel, you may not be able to fully control the partition key, Actually asking SORACOM to change the
specification so that the partition keys can be distributed.
As a reverse case, things like streaming MapReduce can be realized with Kinesis Streams and Lambda.
Also in this case the handling of the partition key is important.
It is the most important point in dealing with Kinesis Streams to balance the bottleneck by distributing
the partition keys as much as possible and balancing the same partition key for the data you want to
receive in the same Lambda .
API Gateway
Since AWS Lambda alone has no function to accept requests with HTTP, it is necessary to combine API
Gateway in order to link with external systems.
In addition to simply passing HTTP requests to AWS Lambda calls, various processing such as caching
and throttling necessary for API release are prepared. In addition, there is a mechanism called Custom
Authorizer that can independently carry out authentication processing, and you can call Lambda function
for authentication.18
Besides, the API Gateway can also connect to AWS components other than AWS Lambda, for example,
it can say that it will throw the request accepted by API into Amazon SQS (message queue service)
without going through AWS Lambda. It can be used for CQRS architecture which makes asynchronous
"command" with side effects. Combined with the Custom Authorizer, it is possible to say that it
authenticates to AWS components from another cloud or on-premises environment using its own JWT
token and throws the data. I think that this will be the key to the future of the multi-cloud era based on ID
infrastructure.
Management and operation
Because AWS Lambda is specialized in executing functions, even one making of management console is
basically used together with existing AWS service. For example, metrics such as execution times are
output to CloudWatch, logs output by functions are output to CloudWatch Logs. Instead, there is only AWS
that is well-established in the ecosystem, and there are abundant tools for management.
18
You can also cache the authentication result for a certain time.

Serverless book

Recommended

Recommended

More Related Content

Similar to Serverless book

Similar to Serverless book (20)

More from Masahiro NAKAYAMA

More from Masahiro NAKAYAMA (20)

Recently uploaded

Recently uploaded (20)

Serverless book