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

Keywords:

Cloud Computing, Multicloud, Orchestrators, Node2FaaS, Function as a Service, Terraform, AWS Lambda,

Google Functions, Azure Functions.

Abstract:

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 signiﬁcant 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.

1 INTRODUCTION

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 beneﬁts associated with the cloud computing

paradigm, especially the elasticity that allows a better

load distribution.

https://orcid.org/0000-0001-7459-281X

https://orcid.org/0000-0003-4645-6700

2 FUNCTION AS A SERVICE

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 conﬁguration 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 deﬁned the PaaS

(Mell and Grance, 2011) service model, whose deliv-

ery consists of a fully conﬁgured 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 ﬁ-

nal project cost.

312

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

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

Monolithic.

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 ﬁrst 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 ﬁve 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

language.

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.

3 Node2FaaS FRAMEWORK

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 deﬁnitions. 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

313

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 ﬁgure 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 fulﬁll speciﬁc

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

modules:

• Common Functions: Concentrates a set of util-

ities that are commonly used among the other

modules;

• 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 deﬁnition 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.

4 EXECUTION FLOW

Once available in the local environment (after in-

stallation), the Node2FaaS ﬂow 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 ﬂow of the Node2FaaS execution

process.

Having an active account with the provider is

essential because initially the framework looks for

cloud access credentials. If it does not ﬁnd the cre-

dentials ﬁle, the application prompts the user to enter

their username and token for access to cloud services.

After that, the system creates the credentials ﬁle and

will no longer prompts for this in future executions.

CLOSER 2020 - 10th International Conference on Cloud Computing and Services Science

314

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 deﬁnitions of functions to per-

form the conversion, as shown in Figure 4.

During the process, if an “include” command is

encountered, then the target ﬁle is also searched for

conversion candidate functions, and this process re-

peats recursively until no ﬁle for inclusion is found.

That way, when the application ﬁnds a role, it will

effect cloud access to create a new FaaS role. After re-

ceiving conﬁrmation of role creation, the application

obtains the service access URI, and creates the request

within the original role deﬁnition. 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 ﬁles 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

application.

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 deﬁnition 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 conﬁgure them and connect them to

existing conﬁguration management tools (Shirinkin,

2017). From a deﬁnition ﬁle Terraform interacts with

a cloud provider and performs the service provision-

ing according to the requested conﬁguration. 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 speciﬁc resources.

It is also easily extensible with plugins (Shirinkin,

2017).

6 RELATED WORKS

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 conﬁgured 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

conﬁgure the provider client in their local environ-

ment.

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-

siﬁed as promising, however, only for academic pur-

poses, not presenting effective application capacity,

since the authors found difﬁculties 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-

velopers.

The Serverless (Serverless, 2019) framework pro-

Remote Procedure Call Approach using the Node2FaaS Framework with Terraform for Function as a Service

315

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 speciﬁc 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

services.

Zeit Now (Zeit, 2019) is a global deployment net-

work built on all existing cloud providers. This makes

teams productive by removing servers and conﬁgura-

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

https://github.com.

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 speciﬁc focus on NodeJS, nor is there an as-

sessment of the developer-built algorithm adherence

to the serverless paradigm implemented by FaaS ser-

vices.

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 conﬁguration 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 signiﬁcant 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

316

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-

ments.

7 METHODOLOGY

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 conﬁguration:

• 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 ﬁrst 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

317

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 ﬁnalize 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 fulﬁll the

request, it can be inferred that Azure’s FaaS service

cannot satisfactorily handle situations involving writ-

ing and deleting ﬁles.

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%

8 CONCLUSION

The tests results showed signiﬁcant 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-

niﬁcant 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

318

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 efﬁ-

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 efﬁcient 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-

niﬁcant results when loads are less concentrated on a

speciﬁc 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.

REFERENCES

Alibaba (2019). Alibaba functions.

http://alibabacloud.com/products/function-compute.

Alien4Cloud (2019). Alien4cloud.

http://alien4cloud.github.io.

Amazon (2019). Aws. https://aws.amazon.com/.

Apache (2019a). Apache aria tosca orchestration engine.

https://ariatosca.incubator.apache.org/.

Apache (2019b). What is apache openwhisk?

https://openwhisk.apache.org/.

AWS (2019). Aws cloudformation.

https://aws.amazon.com/pt/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–

65.

Borov

sak, T. (2019). xopera orchestrator.

https://github.com/xlab-si/xopera-opera.

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. https://claudiajs.com/.

Cloudify (2019). Getting started.

https://cloudify.co/getting-started/.

Fn (2019). Fn project: Open source. container-native.

serverless platform. https://fnproject.io/.

Google (2019). Cloud functions.

https://cloud.google.com/functions/.

Guerriero, M. (2019). Dicer.

https://github.com/DICERs/DICER.

IBM (2019). IBM cloud functions.

https://www.ibm.com/br-pt/cloud/functions.

Larrucea, X., Santamaria, I., Colomo-Palacios, R., and

Ebert, C. (2018). Microservices. IEEE Software,

35(3):96–100.

Loulloudes, N. (2019). The celar project.

https://github.com/CELAR/c-Eclipse.

Mell, P. and Grance, T. (2011). The NIST deﬁnition of

cloud computing. National Institute of Standards and

Tecnology.

Microsoft (2019). Azure functions.

https://azure.microsoft.com/pt-br/services/functions/.

Oracle (2019). Announcing oracle func-

tions. https://blogs.oracle.com/cloud-

infrastructure/announcing-oracle-functions.

Serverless (2019). Serverless: Build apps with radically less

overhead and cost. https://serverless.com.

Shirinkin, K. (2017). Getting Started with Terraform. Packt

Publishing.

Spillner, J. (2017). Transformation of python applica-

tions into function-as-a-service deployments. CoRR,

abs/1705.08169.

Spillner, J. and Dorodko, S. (2017). Java code analysis and

transformation into AWS lambda functions. CoRR,

abs/1702.05510.

Spoiala, C. (2017). Pros and cons of serverless computing.

https://assist-software.net/blog/pros-and-cons-

serverless-computing-faas-/comparison-aws-lambda-

vs-azure-functions-vs-google.

TOSCA, O. (2019). Open tosca.

http://www.opentosca.org/.

VmWare (2019). Introducing vmware cloud assembly,

vmware code stream and vmware service broker.

https://blogs.vmware.com/management/2018/08/introducing-

cloud-automation.html.

Zeit (2019). Zeit now: The global serverless platform.

https://zeit.co.

Remote Procedure Call Approach using the Node2FaaS Framework with Terraform for Function as a Service

319