Remote Procedure Call Approach using the Node2FaaS Framework with
Terraform for Function as a Service
Leonardo Rebouc¸as de Carvalho
and Aleteia P. F. de Araujo
Department of Computer Science, University of Bras
ılia, Bras
ılia, Brazil
Cloud Computing, Multicloud, Orchestrators, Node2FaaS, Function as a Service, Terraform, AWS Lambda,
Google Functions, Azure Functions.
Cloud computing has evolved into a scenario where multiple providers make up the list of services that process
client workloads, resulting in Functions as a Service. Because of this, this work proposes an approach of
using RPC based FaaS. Using the Node2FaaS framework as a NodeJS application converter and integrated
with Terraform as a cloud orchestrator. So, CPU, memory and I/O overhead tests were performed on a local
environment and on the three main FaaS services: AWS Lambda, Google Functions and Azure Functions. The
results showed significant runtime gains between the local environment and FaaS services, reaching up to a
99% reduction in runtime when the tests were run on cloud providers.
Cloud computing has brought a different way of han-
dling computing resources. Service-oriented clouds
deliver multiple computational capacity utilization
models, abstracting complexities according to cus-
tomer needs. Thus, the client decides what level of
involvement they want to have with the computational
resource they are using.
In this scenario it is important to study mecha-
nisms that exploit the full potential of these available
resources to obtain the best possible outcome. This
work proposes the adoption of an architecture based
on remote procedure calls, in this case Function as
a Service services, using the Node2FaaS (Carvalho
and Ara
ujo, 2019) Framework for NodeJS application
conversion and Terraform (Brikman, 2017) as a pub-
lic cloud orchestrator.
For this work a NodeJS application was devel-
oped, whose functions are intended to apply a con-
trollable stress load on the server computational re-
sources, such as CPU, memory and disk. This appli-
cation has been converted using Node2FaaS to pro-
cess its functions in FaaS services and take advantage
of all the benefits associated with the cloud computing
paradigm, especially the elasticity that allows a better
load distribution.
Programming models have been evolved over time,
driven by software optimization, as well as their main-
tainability, scalability, and business alignment (Basili
et al., 2010). Initially, the software was developed
monolithically, meaning the entire application was
contained in a single software block. This occasional
model is a tight coupling between application compo-
nents, leading to degradability of maintainability. To-
day, it is common for system architects to design their
applications in a modular fashion, separating different
complexity blocks and related feature sets (Larrucea
et al., 2018).
To meet the demand for technology platforms that
support software development paradigms, whether
monolithic or segmented, the traditional infrastruc-
ture management model needs to invest heavily in in-
stallation and configuration tasks. Enabling an envi-
ronment to receive source code and execute it prop-
erly usually takes many hours of work. To stream-
line this effort, cloud computing has defined the PaaS
(Mell and Grance, 2011) service model, whose deliv-
ery consists of a fully configured platform ready to re-
ceive source code. However, this type of service still
exposes some infrastructure details to the developer
who eventually still needs to ensure, among other
things, the elasticity of the environment. In addition,
the provisioned environment must be maintained dur-
ing the development period, and this increases the fi-
nal project cost.
Rebouças de Carvalho, L. and F. de Araujo, A.
Remote Procedure Call Approach using the Node2FaaS Framework with Terraform for Function as a Service.
DOI: 10.5220/0009381503120319
In Proceedings of the 10th International Conference on Cloud Computing and Services Science (CLOSER 2020), pages 312-319
ISBN: 978-989-758-424-4
2020 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
In this context, providers are now offering a ser-
vice model that delivers a completely encapsulated
platform for software development and charges only
for the processing effectively performed by the plat-
form. This type of service, known as Function as
a Service (FaaS) (Spoiala, 2017), has gained much
evidence recently as its approach meets the architec-
tural model that has become widespread today the mi-
croservices paradigm. Figure 1 shows how to exe-
cute modules in monolithic environments compared
to those oriented to microservices.
Figure 1: Segmentation of Features with Microservices and
2.1 FaaS Providers
Today’s leading public cloud providers have FaaS ser-
vices in their catalogs. Pioneer Amazon offers the
AWS Lambda (Amazon, 2019) service. This ser-
vice allows processing of NodeJS, Python, Java, Go,
Ruby and C# through the .NET Core and provides a
monthly package of one million free requests before
charging for the service. The provider has several
partnerships for deployment, monitoring, code man-
agement, and security.
Google offers the Cloud Functions (Google, 2019)
service. This service allows processing of functions
written in Python, NodeJS and Go and provides an
initial quota of two million requests per month and
only starts charging when this quota is exceeded.
Microsoft, through its Azure cloud service, makes
Azure Functions (Microsoft, 2019) available. This
service allows loading of functions written in C#,
F#, NodeJS, Java, Python, or PHP (Microsoft, 2019).
The provider states in its portal that the functions are
available in a Windows environment, although this is
transparent to the user. Despite this, there is a forecast
of availability of environments using Linux. It offers
the first million service calls for free each month.
Alibaba Cloud offers the Function Compute (Al-
ibaba, 2019) service, which allows processing of code
written in NodeJS, Java, Python, Go, PHP and C#.
This service also offers a free monthly starting quota
of one million requisitions, and charges different rates
in each region where it operates.
The IBM Cloud Functions (IBM, 2019) service
offered by IBM Cloud handles functions written in
NodeJS, Python, Go, Java, PHP, Ruby, Ballerina and
Swift (Apache, 2019b) through Apache OpenWhisk
containers. With OpenWhisk you can process func-
tions over Docker containers. As such, it is able
to extend the possibilities of processing languages to
any that can be installed in a Docker container. The
provider offers free processing for five million re-
quests per month.
In December 2018, the Oracle Cloud provider an-
nounced that it would launch the Oracle Function ser-
vice in 2019 along the lines of Function as a Service
(Oracle, 2019). Like IBM Cloud Functions, Oracle
Functions will be supported by an open source pro-
cessing platform, but unlike IBM, Oracle has decided
to use the Fn framework
. Since Fn runs over Docker,
it can potentially process code in any programming
To address this amount of services, as well as
all the complexity related to using FaaS services
from NodeJS applications, the Node2FaaS Frame-
work (Carvalho and Ara
ujo, 2019) was created, which
uses a remote procedure call approach to convert ap-
plications written in NodeJS with local processing to
work with processing in FaaS services.
The Node2FaaS framework processes the original
source code of a NodeJS application offered as in-
put for its execution, and converts it to an applica-
tion whose functions are performed in a FaaS service.
The internal code of the functions is converted and
deployed automatically created on the provider. FaaS
service API calls, which correspond to the original
function code, are swapped in for of the original func-
tion definitions. The product of this processing is a
Apache OpenWhisk it is an open source, distributed
platform that performs functions in response to events at
any scale. OpenWhisk manages infrastructure, servers, and
sizing using Docker (Apache, 2019b)
The Fn project is a serverless, open source platform,
container native, which can run both in the cloud and lo-
cally. It’s easy to use, supports all programming languages,
is extensible and high-performance (Fn, 2019).
Remote Procedure Call Approach using the Node2FaaS Framework with Terraform for Function as a Service
new application, based on the original, whose actual
execution of its functions does not occur in the envi-
ronment where the application is being executed, but
in an external FaaS service.
The architecture of the Node2FaaS Framework
is presented in Figure 2. It is possible to observe
in this figure that in each module of an application
there may be functions. Within each function is code
that performs some useful operation for the software.
Once submitted to Node2FaaS, this code will be pub-
lished to the cloud provider, and instead, in the con-
verted application, a URI call will appear pointing to
the provider-provided REST API during publishing.
Thus, the original function code is transferred to the
cloud service and then consumed through requests us-
ing the HTTP protocol.
Figure 2: The Node2FaaS Solution Architecture.
To accomplish its mission, Node2FaaS has been
internally segmented into modules that fulfill specific
tasks and integrate with each other. Thus, working in
a coordinated fashion, these modules receive inputs
and return results that enable the processing of appli-
cations and generation of a new application using the
proposed approach.
Figure 3 presents the internal structure of version
1.0 of the framework, and it is possible to verify the
existence of a main module, called index, whose role
is to coordinate the other modules. In addition to the
main module, Node2FaaS consists of the following
Common Functions: Concentrates a set of util-
ities that are commonly used among the other
Preparation: Ensures that the requirements for
proper framework execution are met, and are sup-
ported by the following submodules:
Output Structure: Responsible for creating
the target application directory;
Accreditation: Responsible for obtaining and
storing credential information from providers;
Provider Interface: Responsible for commu-
nicating with the providers’ services and ab-
stracting their complexities for the other mod-
ules. The version used in this work is integrated
with Terraform.
Converter: Coordinates the conversion process
and relies on the following submodules:
Code Extraction: Responsible for extracting
internal source code from functions;
Normalization: Responsible for making the
source code executable in the FaaS service;
Assembly: Responsible for assembling the
new definition of functions after publication in
the provider;
Compression: Some services advise that code
be compressed before publication, this module
is responsible for performing this task;
Publication: Responsible for requesting pub-
lication to the provider interface module and
handling its return.
Figure 3: Node2FaaS Framework Composition.
Once available in the local environment (after in-
stallation), the Node2FaaS flow is started from the
“node2faas” application. If the framework was in-
stalled via NPM, this application will be registered
in the machine path and can be run directly from
the command: node2faas –target [path to the app].
Otherwise it, will be necessary to go to the directory
where the framework was downloaded, grant execute
permission, and only then run Node2FaaS. Figure 4
presents the activity flow of the Node2FaaS execution
Having an active account with the provider is
essential because initially the framework looks for
cloud access credentials. If it does not find the cre-
dentials file, the application prompts the user to enter
their username and token for access to cloud services.
After that, the system creates the credentials file and
will no longer prompts for this in future executions.
CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science
Once the credential has been obtained, and an ap-
plication is provided for conversion by Node2FaaS, it
is subjected to a conversion process that will parse the
application code for definitions of functions to per-
form the conversion, as shown in Figure 4.
During the process, if an “include” command is
encountered, then the target file is also searched for
conversion candidate functions, and this process re-
peats recursively until no file for inclusion is found.
That way, when the application finds a role, it will
effect cloud access to create a new FaaS role. After re-
ceiving confirmation of role creation, the application
obtains the service access URI, and creates the request
within the original role definition. That way, the call
to the function remains unchanged and its operation
on the cloud platform is made completely transparent.
In the end, Node2FaaS will have generated all
the files that should make up the original applica-
tion, but with the original function code replaced by
HTTP calls to the cloud provider’s FaaS service. The
converted application maintains the same signature as
the original functions, allowing its use to remain un-
changed for the requesting processes of the functions.
This eliminates the need to make adjustments to the
In order to meet the multi-provider provisioning
requirement, as advocated by the Multicloud concept,
and that the effort to keep the framework up-to-date
with the constant updates promoted by the providers
in their APIs, it was decided to adopt an orches-
trator who could assume this assignment. Several
tools were analyzed such as Cloudformation (AWS,
2019), AriaApache (Apache, 2019a), Alien4Cloud
(Alien4Cloud, 2019), Celar (Loulloudes, 2019),
DICER (Guerriero, 2019), OpenTOSCA (TOSCA,
2019), xOpera (Borov
sak, 2019), CloudAssembly
(VmWare, 2019) and Cloudify (Cloudify, 2019),
however considering the requirements that would al-
low the Node2FaaS Framework to be incorporated de-
nies the use of Terraform (Brikman, 2017).
5 Terraform
Terraform (Brikman, 2017) is an open source tool cre-
ated by HashiCorp that allows the definition of infras-
tructure as code using a simple declarative program-
ming language (Brikman, 2017). It enables deploy-
ment and management of this infrastructure across
multiple public cloud providers (e.g. AWS, Azure,
Google Cloud, and DigitalOcean), as well as on
private virtualization platforms (e.g. OpenStack and
VMWare) using a few commands(Brikman, 2017).
Terraform currently supports over 30 different
providers. When it comes to servers, Terraform offers
several ways to configure them and connect them to
existing configuration management tools (Shirinkin,
2017). From a definition file Terraform interacts with
a cloud provider and performs the service provision-
ing according to the requested configuration. The ser-
vice can be either a virtual machine, a database, a stor-
age service, or whatever the provider supports.
Terraform tracks the momentary state of the in-
frastructure it creates and applies delta changes when
some feature needs to be updated, added, or deleted
(Shirinkin, 2017). It also provides a way to import
existing resources and target only specific resources.
It is also easily extensible with plugins (Shirinkin,
The work (Spillner, 2017) brings an approach of con-
verting Python-written applications to Python deploy-
ments in the AWS Lambda service. The application
built by Spillner, called Lambada, processes a Python
application and converts it to the appropriate code to
be instantiated in the cloud. If the user has the AWS
client installed and properly configured on the ma-
chine, Lambada automatically deploys, but the entire
client setup process is up to the user. This limits the
use of this converter to users who are able to correctly
configure the provider client in their local environ-
Furthermore, that article (Spillner, 2017) is lim-
ited to using Lambada for converting single-function
applications. In production environment applications,
it is common to have multiple functions for the execu-
tion of an application. Node2FaaS, on the other hand,
enables better use in real applications, not being lim-
ited to experimental environments such as Lambada.
Spillner and Dorodko (Spillner and Dorodko,
2017) apply the same approach as Lambada, but for
Java applications. In this paper the authors question
the economic feasibility of running a Java application
entirely using FaaS, and whether there is a possibil-
ity to automate the application conversion process.
They implemented a tool called Podilizer, and per-
formed experiments using it. The results were clas-
sified as promising, however, only for academic pur-
poses, not presenting effective application capacity,
since the authors found difficulties in using the ap-
plications resulting from the conversion. On the other
hand, Node2FaaS is not simply intended for academic
experimentation, but for effective use by NodeJS de-
The Serverless (Serverless, 2019) framework pro-
Remote Procedure Call Approach using the Node2FaaS Framework with Terraform for Function as a Service
Figure 4: Node2FaaS Application Conversion Process.
vides a platform for deploying applications to major
FaaS service providers such as AWS Lambda, Azure
Functions, Google Cloud Functions, IBM Open-
Whisk, and frameworks like Fn. It abstracts the dif-
ferences between services and allows deploys to run
on FaaS services through a CLI. Written in NodeJS,
Serverless needs to be installed directly in the local
environment and has templates for interaction with
each provider that need to be customized to the user’s
needs. It is an open source tool, however it has a paid
enterprise version that offers several additional fea-
tures such as: web dashboard, debugging tools, best
practice injection, security simplicity, among others.
Although Serverless is a robust platform for man-
aging FaaS deployments, it works with the various
programming languages that each provider has, and
so there is no specific focus on NodeJS. Thus, the
framework does not perform any assessment of the
nature of the code and its adherence to the Function as
a Service approach, leaving it to the developer to de-
cide which functionality should be leveraged for FaaS
Zeit Now (Zeit, 2019) is a global deployment net-
work built on all existing cloud providers. This makes
teams productive by removing servers and configura-
tions, providing a seamless development experience
for building scalable, modern web applications (Zeit,
2019). In practice this service acts as a layer above
FaaS providers. It allows the creation of web appli-
cations through its web platform or integration with
code versioning tools such as GitHub
The Zeit Now (Zeit, 2019) platform has a billing
model similar to the overlapping providers. It offers a
daily quota for executions and resource allocation that
allows the user to try the service for free. In addition,
it has a CLI interface and Desktop client for Windows
and MacOS. It supports a wide range of programming
languages and has several plugins that allow integra-
tion with other development tools.
Such as Serverless, Zeit Now simply receives the
code and passes it on to the provider, acting as an in-
termediary between the developer and the FaaS ser-
vice. Because it works with many languages, there
is no specific focus on NodeJS, nor is there an as-
sessment of the developer-built algorithm adherence
to the serverless paradigm implemented by FaaS ser-
Claudia.js (Claudia.js, 2019) is a framework that
makes the task of deploying NodeJS projects on AWS
Lambda easy. It automates all error-prone deploy-
ment and configuration tasks. This framework acts as
a pre-AWS Lambda layer, whose function boils down
to simplifying interaction with Amazon’s FaaS ser-
vice. By interacting with only one provider, the Clau-
dia.js framework limits the possibilities of using the
cloud model, strengthening vendor lock-in and thus
not representing significant gains for its users.
Table 1 presents a comparison between the pre-
sented solutions. In this table it is possible to observe
that two of these solutions do not have commercial ap-
plicability, only academic, and thus do not effectively
offer added value through the FaaS model. Among
the other solutions, only Node2FaaS offers evaluation
CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science
Table 1: Comparative Table of FaaS-oriented Solutions.
Feature Lambada Podilizer Serverless Zeit Now Claudia.js Node2FaaS
Supported Languages Python Java Multiple Multiple NodeJS NodeJS
Effective Applicability Academic Academic General General General General
Multicloud Support No No Yes Yes No Yes
Multicloud Orchestrator No No Hidden Hidden No Yes
FaaS Fitting Analysis No No No No No Yes
execution to classify the adherence of a code to the
FaaS approach. Using a multicloud orchestrator is
also a differential of Node2FaaS. As such, the frame-
work follows the Orchestrator’s evolution and as new
integrations with other services and/or providers are
added, Node2FaaS is also affected by these enhance-
In order to experiment with the proposed approach,
the functions presented in Listing 1, 2 and 3 were de-
veloped with the purpose of overloading the CPU, the
memory and the machine disk, respectively.
Listing 1: CPU Bound Function.
1 e x p o r t s . cp u = f u n c t i o n ( r e q , r e s ) {
2 v a r r e s u l t = 0 ;
3 f o r ( va r x i n r e q . params ){
4 f o r ( var i = 0 ;
5 i < p a r s e I n t ( r e q . p a r a m s [ x ] ) ;
6 i ++ ) {
7 r e s u l t = p a r s e I n t ( r e s u l t )1
8 +
9 p a r s e I n t ( r e q . pa r a m s [ x ] ) 1 ;
10 }
11 }
12 r e s . j s o n ( r e s u l t ) ;
13 } ;
These functions were added to a NodeJS applica-
tion that was converted to RPC approach in FaaS, us-
ing the Node2FaaS framework for the following FaaS
providers: AWS Lambda, Google Functions, and
Azure Functions. Both the original application and
the converted applications were subjected to test bat-
teries that allow the evaluation of their performance
in terms of runtime.
Listing 2: Memory Bound Function.
1 e x p o r t s . memory = f u n c t i o n ( re q , r e s ) {
2 v a r r e s u l t = new A rray ( ) ;
3 f o r ( va r x = 0 ;
4 x < p a r s e I n t ( r e q . pa r a m s [ " a " ] ) ;
5 x + +) {
6 r e s u l t [ x ] = new A r ray ( ) ;
7 f o r ( var i = 0 ;
8 i < p a r s e I n t ( r e q . p a r a m s [ " b " ] ) ;
9 i ++ ) {
10 r e s u l t [ x ] [ i ] = x+ i ;
11 }
12 }
13 r e s u l t = e v a l ( r e s u l t . j o i n ( " +" ) ) ;
14 r e s . j s o n ( r e s u l t ) ;
15 } ;
Listing 3: I/O Bound Function.
1 e x p o r t s . i o = f u n c t i o n ( req , r e s ) {
2 v a r r d = Math . rando m ( ) 1 0 0 0 ;
3 v a r p r e f i x = Math . f l o o r ( r d ) ;
4 v a r r e s u l t = 0 ;
5 c o n s t f s = r e q u i r e ( " fs " ) ;
6 f o r ( va r x = 0 ;
7 x < p a r s e I n t ( r e q . pa r a m s [ " a " ] ) ;
8 x + +) {
9 f o r ( var i = 0 ;
10 i < p a r s e I n t ( r e q . p a r a m s [ " b " ] ) ;
11 i ++ ) {
12 f s . w r i t e F i l e S y n c ( " / tm p /"+
13 p r e f i x +
14 x+ i ,
15 " N o de 2 Fa a ST e st " ,
16 f u n c t i o n ( e r r ) {
17 i f ( e r r ) {
18 r e t ur n c o n s o l e . lo g ( e r r ) ;
19 }
20 c o n s o l e . l o g ( " F il e s av ed !" ) ;
21 } ) ;
22 f s . u n l i n k S y n c ( "/ tmp /"+
23 p r e f i x +
24 x+ i ) ;
25 r e s u l t + + ;
26 }
27 }
28 r e s . j s o n ( r e s u l t ) ;
29 } ;
Table 2 shows the composition of the test parame-
ters that were performed. In all, 1080 test cases were
executed. This test suite was used to plot an average
axis for each of the 10 runs of each type (CPU, mem-
ory, and I / O).
The environment against which local tests were
run had the following configuration:
Machine: Macbook Pro 13” Mid 2012
CPU: Intel Core i5 2,5 GHz
Memory: 16GB 1600 Mhz DDR3
Operational System: MacOSX Mojave(10.14.6)
Two rounds of tests were performed, the first on
December 14, 2019 and the second on December 23,
2019. A “shell script” has been developed to com-
mand the tests and store the results. At the end,
the data were consolidated by calculating the aver-
age of the executions of each test case and then the
graphs were generated with the results obtained for
each provider and for the local environment in each
type of test (CPU, memory and I/O).
7.1 Results
The results showed a marked difference in the exe-
cution time of the local tests in relation to the times
Remote Procedure Call Approach using the Node2FaaS Framework with Terraform for Function as a Service
Table 2: Test Parameters.
Test Environment/Providers Load time Concurrence Executions
CPU Local, GCP, AWS, Azure 1s, 5s, 10s 10, 50, 120 10
Memory Local, GCP, AWS, Azure 1s, 5s, 10s 10, 50, 120 10
I/O Local, GCP, AWS, Azure 1s, 5s, 10s 10, 50, 120 10
registered by the applications adopting the RPC ap-
proach. As can be seen from Figure 5, which shows
the consolidated average times for CPU test cases,
while in local execution the average was around 183
seconds, FaaS services fared much better, reaching
9.62 seconds for AWS. Even the worst-performing
provider, Azure, still had a result that represents less
than 30% of the result from local processing.
Figure 5: CPU Bound Tests Result.
Figure 6 shows an even more discrepant result be-
tween local execution times and FaaS services times,
in this case, for tests with high memory consump-
tion. AWS and GCP recorded average times of 2.45
and 6.08 seconds, respectively. The Azure provider
recorded a higher result, with an average time of
64.04 seconds, but still much lower than the 247.03
seconds recorded as the average of the tests processed
on the local machine.
Figure 6: Memory Bound Tests Result.
The test case that aimed to stress disk activity
yielded an intriguing result. While AWS and GCP
providers recorded averages of 1.73 and 4.17 seconds
of runtime and local testing resulted in an average of
55.50 seconds, as can be seen in Figure 7, the Azure
provider was unable to finalize any test cases. Con-
sidering that the test cases ranged from 10, 50, and
120 concurrent requests and that for a single request
the Azure provider was able to successfully fulfill the
request, it can be inferred that Azure’s FaaS service
cannot satisfactorily handle situations involving writ-
ing and deleting files.
Figure 7: I/O Bound Tests Result.
These results show the effectiveness of the elas-
ticity actuation that cloud computing offers. The per-
ceived discrepancy between local and FaaS execution
is due to the queuing of processing that occurs in lo-
cal execution, while in FaaS execution there is in fact
parallel processing, as the provider is in charge of de-
livering more computational resources when these are
perceived as necessary. Table 3 shows the reduction
percentages obtained in each provider. It is possible
to observe that for the memory test, it was possible to
obtain a gain of 99% using AWS provider processing.
Table 3: Runtime Reduction Table.
Tests GCP Azure AWS
CPU 92,12% 68,55% 94,76%
Memory 97,54% 74,08% 99,01%
I/O 92,48% 0,00 % 96,89%
The tests results showed significant differences in the
execution time of local functions under stress in re-
lation to the same functions using the proposed ap-
proach. For CPU consumption tests the reduction
reached 94.75%, while for I/O tests the reduction
reached 96.88% and for memory tests there was a sig-
nificant reduction of 99%.
Given the above, the contribution of Function as
a Service services to workloads that require large
amounts of computational resources is clear. Because
running local workloads that require a lot of compu-
CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science
tational resources such as CPU, memory, or I/O con-
sumes more runtime than if they were sent for pro-
cessing in FaaS services. In addition, considering this
context, the Node2FaaS framework proved to be effi-
cient in the task of automatically converting NodeJS-
written applications to function using FaaS services
through an RPC approach. Similarly, Terraform, act-
ing as the internal orchestrator of Node2FaaS, proved
to be very efficient in bringing local application code
to the cloud.
However, it is important to note that some
provider constraints may make it impossible to use
this model in certain provider services, as evidenced
by disk stress tests performed on Azure services,
which failed in 100% of cases.
In future works it would be important to perform
the same tests with real applications that merge the
use of computational resources as it occurs in produc-
tion environments. In that kind of experiment will be
possible to see if the same approach yields such sig-
nificant results when loads are less concentrated on a
specific resource. In addition, it is hoped that in the
near future the Azure provider will mature their FaaS
solution so that disk stress test results can be obtained
and properly analyzed.
Alibaba (2019). Alibaba functions.
Alien4Cloud (2019). Alien4cloud.
Amazon (2019). Aws.
Apache (2019a). Apache aria tosca orchestration engine.
Apache (2019b). What is apache openwhisk?
AWS (2019). Aws cloudformation.
Basili, V. R., Lindvall, M., Regardie, M., Seaman, C., Hei-
drich, J., M
unch, J., Rombach, D., and Trendowicz, A.
(2010). Linking software development and business
strategy through measurement. Computer, 43(4):57–
sak, T. (2019). xopera orchestrator.
Brikman, Y. (2017). Terraform: Up and Running: Writing
Infrastructure as Code. O’Reilly Media.
Carvalho, L. and Ara
ujo, A. P. F. d. (2019). Framework
node2faas: Automatic nodejs application converter
for function as a service. In Proceedings of the 9th In-
ternational Conference on Cloud Computing and Ser-
vices Science - Volume 1: CLOSER,, pages 271–278.
INSTICC, SciTePress.
Claudia.js (2019). Claudia.js: Serverless javascript, the
easy way.
Cloudify (2019). Getting started.
Fn (2019). Fn project: Open source. container-native.
serverless platform.
Google (2019). Cloud functions.
Guerriero, M. (2019). Dicer.
IBM (2019). IBM cloud functions.
Larrucea, X., Santamaria, I., Colomo-Palacios, R., and
Ebert, C. (2018). Microservices. IEEE Software,
Loulloudes, N. (2019). The celar project.
Mell, P. and Grance, T. (2011). The NIST definition of
cloud computing. National Institute of Standards and
Microsoft (2019). Azure functions.
Oracle (2019). Announcing oracle func-
Serverless (2019). Serverless: Build apps with radically less
overhead and cost.
Shirinkin, K. (2017). Getting Started with Terraform. Packt
Spillner, J. (2017). Transformation of python applica-
tions into function-as-a-service deployments. CoRR,
Spillner, J. and Dorodko, S. (2017). Java code analysis and
transformation into AWS lambda functions. CoRR,
Spoiala, C. (2017). Pros and cons of serverless computing.
TOSCA, O. (2019). Open tosca.
VmWare (2019). Introducing vmware cloud assembly,
vmware code stream and vmware service broker.
Zeit (2019). Zeit now: The global serverless platform.
Remote Procedure Call Approach using the Node2FaaS Framework with Terraform for Function as a Service