4 Architecting IoT Cloud
235
Monolithic
application
Microservice
Microservice
Microservice
Microservice
Microservice
Function
Function
Function
Function
Function
Function
Function
Function
Serverless
Fig. 4.37 The main concept of serverless and FaaS
working on this idea as well. Amazon Lambda allows you to run code for
almost any backend service or application without any administration. You
upload the code and Lambda handles everything needed to run or scale
the code with high availability. The code can be automatically triggered by
another AWS service or be called from any mobile or web application. It is
expected that in a few short years, many more Cloud platforms will evolve
to facilitate serverless architecture in some form. However, despite the rapid
evolution of serverless architecture and the capability to program using highly
popular languages, current serverless computing is limited and is not governed
by a clear blueprint, technical standards, or options.
4.10.2 Behind the Scene of FaaS: OpenWhisk
In this section, we describe the detailed implementation of FaaS technology using
one of the most well-known open-source FaaS platforms. Apache OpenWhisk is
an open-source serverless platform driven mostly by IBM and Adobe. Figure 4.38
illustrates the high-level architecture as well as the programming model of OpenWhisk. Apache OpenWhisk is designed to function as an asynchronous and loosely
coupled execution environment which can execute functions (event handler) in
response to events at any scale. Events can come from any source such as datastores,
message queues, mobile and web applications, sensors, chatbots, scheduled tasks
(via Alarms), etc. In response to events, a stateless function (called action, event
handler, or code snippet) is executed in serverless mode. Actions, which encapsulate
application logic, can be invoked by the user-created APIs, command-line interface
(CLI) of OpenWhisk, or by Triggers. Triggers are created to automate actions. In
other words, triggers are endpoints and should be explicitly called by events. Rules
create a binding between serverless functions (actions) and triggers. Put differently,
235
Monolithic
application
Microservice
Microservice
Microservice
Microservice
Microservice
Function
Function
Function
Function
Function
Function
Function
Function
Serverless
Fig. 4.37 The main concept of serverless and FaaS
working on this idea as well. Amazon Lambda allows you to run code for
almost any backend service or application without any administration. You
upload the code and Lambda handles everything needed to run or scale
the code with high availability. The code can be automatically triggered by
another AWS service or be called from any mobile or web application. It is
expected that in a few short years, many more Cloud platforms will evolve
to facilitate serverless architecture in some form. However, despite the rapid
evolution of serverless architecture and the capability to program using highly
popular languages, current serverless computing is limited and is not governed
by a clear blueprint, technical standards, or options.
4.10.2 Behind the Scene of FaaS: OpenWhisk
In this section, we describe the detailed implementation of FaaS technology using
one of the most well-known open-source FaaS platforms. Apache OpenWhisk is
an open-source serverless platform driven mostly by IBM and Adobe. Figure 4.38
illustrates the high-level architecture as well as the programming model of OpenWhisk. Apache OpenWhisk is designed to function as an asynchronous and loosely
coupled execution environment which can execute functions (event handler) in
response to events at any scale. Events can come from any source such as datastores,
message queues, mobile and web applications, sensors, chatbots, scheduled tasks
(via Alarms), etc. In response to events, a stateless function (called action, event
handler, or code snippet) is executed in serverless mode. Actions, which encapsulate
application logic, can be invoked by the user-created APIs, command-line interface
(CLI) of OpenWhisk, or by Triggers. Triggers are created to automate actions. In
other words, triggers are endpoints and should be explicitly called by events. Rules
create a binding between serverless functions (actions) and triggers. Put differently,