=Paper=
{{Paper
|id=Vol-2978/saerocon-paper3
|storemode=property
|title=Cost-Aware Migration to Functions-as-a-Service Architecture
|pdfUrl=https://ceur-ws.org/Vol-2978/saerocon-paper3.pdf
|volume=Vol-2978
|authors=Adam Stafford,Farshad Ghassemi Toosi,Anila Mjeda
|dblpUrl=https://dblp.org/rec/conf/ecsa/StaffordTM21
}}
==Cost-Aware Migration to Functions-as-a-Service Architecture==
https://ceur-ws.org/Vol-2978/saerocon-paper3.pdf
Cost-Aware Migration to Functions-as-a-Service
Architecture
Adam Stafford, Farshad Ghassemi Toosi and Anila Mjeda
Senior Software Engineer, Independent Researcher
Computer Science Department at Munster Technological University, Cork Campus
Computer Science Department at Munster Technological University, Cork Campus
Abstract
Serverless functions, also known as Functions-as-a-Service (FaaS), provide the capabilities of running functional code
without the requirement of provisioning or managing the underlying infrastructure with the potential to significantly reduce
overall running costs. FaaS can provide a quick time to market, reduced server management overhead, and with the pay-per-
use model of FaaS, billing is based solely on the number of requests, execution time, and memory consumption. Although
FaaS is a popular area of cloud computing, there is a lack of industry standards for the migration process of monolithic
applications to FaaS architecture. Without this, when opting to migrate to this architecture style there is little or no roadmap
to guide with best practices. This may result in functions underperforming and incurring a higher cost than necessary. The
migration technique outlined in this paper explores the area of FaaS, proposing a new set of guidelines to rectify these
shortcomings. This research aims to find the ideal structure for running serverless functions optimised to reduce memory
consumption and running costs. Two experiments are executed, the first analyses the behaviour of serverless functions
throughout several refactoring iterations. The second experiment extracts serverless functions from a monolithic application.
A migration technique is then created for migrating a monolithic application to FaaS architecture based on these findings.
1. Introduction vices [3, 4]. Functions-as-a-Service are often seen as
A Monolithic Architecture is an architectural pattern in the next logical phase of architecture style. Taibi et al, [4]
which all functionality of a system is encapsulated into outline how in some cases FaaS is better suited to newer
a single application. This architecture style has some advancements than Microservices. That said, the area
advantages which include simple development, easy de- is quite immature in comparison to other architectural
ployment, and simple debugging compared to distributed patterns such as SOA and Microservices.
architectures [1]. However, as monolithic applications The main reason for the adoption of FaaS is to reduce
grow, the flaws of the architecture pattern become ap- costs [5]. This research aims to contribute to the server-
parent. A change to any of the layers of a monolithic less field and provide structured guidance on how to
application requires an entire system retest and deploy- decompose a monolithic application into a FaaS architec-
ment. This results in an application that is slow to adapt ture. This research also aims to provide insight into the
to change with deployments reducing the uptime of the behaviour of serverless functions during a refactoring
application [2]. Scaling also becomes an issue as a mono- process to reduce memory consumption and costs. In
lithic application requires the entire application to be doing so, the aim is to bridge the gap between this archi-
replicated despite usually only a subcomponent of the tecture and its predecessors SOA and Microservices and
system’s functionality requiring scaling [2]. As cloud ensure that functions reduce running costs and consume
computing and containerisation grow the monolithic ar- less memory.
chitecture was not suitable for these new advancements.
The problems identified with monolithic applications 2. Related Work
have been addressed with alternative architecture styles
such as Service Oriented Architecture and Microser- Castro et al. [6] identify Serverless computing and
Functions-as-a-Service to be the natural progression ar-
ECSA2021 Companion Volume
" adam.ryanstafford@gmail.com (A. Stafford); chitecture style surpassing the latest trend of Microser-
farshad.toosi@mtu.ie (F. G. Toosi); anila.mjeda@mtu.ie (A. Mjeda) vices. Eismann et al. [5] report that users tend to adopt a
~ https://www.linkedin.com/in/adam-ryan-stafford/ (A. Stafford); serverless architecture to reduce their hosting costs.
https://www.linkedin.com/in/farshad-ghassemi-toosi-428a5852/ The granularity of the architecture style that permits
(F. G. Toosi); https://www.linkedin.com/in/anila-mjeda-32a5064/ users to scale at the function level along with the pay-per-
(A. Mjeda)
0000-0002-4320-4682 (A. Stafford); 0000-0002-1105-4819
use pricing model of serverless functions are some of the
(F. G. Toosi); 0000-0003-1311-6320 (A. Mjeda) reasons for the architecture style’s continued popularity
© 2021 Copyright for this paper by its authors. Use permitted under Creative
Commons License Attribution 4.0 International (CC BY 4.0).
growth. Considering this and the continued growth of
CEUR
Workshop
Proceedings
http://ceur-ws.org
ISSN 1613-0073 CEUR Workshop Proceedings (CEUR-WS.org)
the architecture style, more companies are foreseen to the workload across multiple servers in the cloud.
migrate their existing applications to a serverless archi- Bardsley et al. [13] analyse the performance of FaaS
tecture. However, FaaS architecture lacks the migration functions to create a set of strategies that play to the
techniques that come with other architectural styles such strengths of the FaaS service. The researchers analysed a
as Microservices and currently there are no established single serverless function which was called 1,000 times at
migration techniques which consider the migration of a a rate of two requests per second for the duration of the
monolithic application to a FaaS architecture style. test run. However, the focus of the work carried out by
Cost Analysis of FaaS – The main focus of this migra- Bardsley et al. [13] was on optimising the performance of
tion technique is to reduce hosting cost of the serverless a serverless environment. Implementing a circuit breaker
functions. Varghese and Buyya [7] compared traditional pattern is one of the strategies proposed.
hosting on virtual machines to serverless hosting. With Nupponen & Taibi [14] identify several good and bad
traditional hosting, the owner pays for the entire time the practices when developing a FaaS architecture. The bad
virtual machine is running, even when the application practices include overuse of asynchronous calls increas-
lies idle. With serverless, the owner is no longer required ing complexity, functions calling other functions leading
to pay for computing resources that are not in use (e.g., to complex debugging and additional costs, and the adop-
when a function lies idle). tion of too many technologies such as libraries, frame-
Eivy [8] warns of the hidden cost implications that works, languages resulting in maintenance issues.
need to be fully understood to use FaaS to its full poten- Drawbacks of FaaS – A known drawback to server-
tial and reap the benefits of the service, since the cost less functions is the issue of cold starts [15]. When a
benefits heavily depend on the execution behaviour and function is deployed to the underlying infrastructure of
the volumes of the application workload. Highlighting the cloud service provider, it runs on a container. If a func-
that contrary to popular belief FaaS is not always cheaper tion has not been triggered in some time, these containers
than provisioning alternative infrastructure. If a server- can go idle and the function will release any resources.
less function has a very high transaction per second rate When a serverless function is executed after being idle,
it may be cheaper to explore alternatives such as virtual a gateway component checks if a container capable of
machines, container hosting, etc. However, considera- serving the request exists. If no container is available,
tions also need to be in place regarding the operation the gateway allocates a new one and directs the request
costs of managing the infrastructure provisioned. The to the respective machine. This process causes a delay
migration technique outlined in this paper ensures that in the request execution time. This delay is commonly
the application is optimised to avoid the hidden costs known as cold start time [16].
outlined by Eivy [8]. Each cloud service provider restricts the functions to
Cost and performance optimisation is a well- a limited execution time. AWS Lambda offers one of
researched area of FaaS. Mahajan et al., [9] propose en- the highest execution times of 15 minutes [17]. This
hancements into serverless cost optimisation by splitting limitation of serverless functions running in the cloud
the workload between virtual machine rental and server- means that any long-running function or algorithm such
less functions using a hybrid system of virtual machines as machine learning or big data process are not suitable
and serverless functions. for serverless functions. The execution time also affects
Existing Industry Standards & Best Practices for the overall cost of running functions. Therefore, it is in
FaaS – Hong et al. [10] propose six design patterns (Pe- the user’s best interest to have the functions running for
riodic Invocation Pattern, Event-Driven Pattern, Data as short time as possible. FaaS pricing model is discussed
Transformation Pattern, Data Streaming Pattern, State further in Section 4.
Machine Pattern, and Bundled Pattern) to model a server-
less architecture in the cloud based on security services.
Rabbah et al. [11] propose a patented technique for deal- 3. Research Contribution
ing with composing serverless functions to build new
Research Questions – This research focuses on three
applications. Their patent describes the use of a proces-
research questions:
sor which determines the primary function of a query
sent by the user and identifies if that function is to be • How does refactoring several different serverless
broken into subsidiary functions. This use of function functions for better performance1 affect the run-
chaining gives a FaaS environment the capabilities to ning costs of the functions?
host entire backend applications. Bernstein et al. [12] This was addressed by preparing several refac-
propose a virtual actor model as an ideal platform to toring iterations based on common best practices
build a stream processing system. Using the virtual ac-
tor model as opposed to the traditional actor model on 1
Performance optimisation was based on recommended prac-
assigned servers provides the capabilities of distributing tices identified in this research.
and analysing the behaviour of the functions be- a real-world scenario is presented in the experiments
fore and after refactoring. stage of this paper.
• What are some of the best practices that server- For the sake of brevity, the details of calculations can
less functions should adhere to that reduce the be seen on Github 2 and the results of the use-case cost
running cost of the functions? analysis are displayed in Table 1. For all the four CSP
After analysing the functions after each refactor- providers the common factors affecting the running costs
ing iteration, the memory usage and execution du- were found to be memory consumption and execution du-
ration metrics identified whether the refactoring ration. This element of the pay-per-use model is the basis
had a positive or negative impact when running for the migration technique proposed in this research.
in a FaaS environment. Based on this analysis, By improving the performance and reducing memory
several best practices were discovered to reduce consumption the serverless functions will run at a re-
memory consumption, execution duration and duced cost compared to functions running without the
thus cost when hosting serverless functions in a implementation of the migration technique.
FaaS architecture.
• How can a monolithic application be decomposed Table 1
into serverless functions which are optimised to Use-Case Cost Summary
reduce running costs in a FaaS architecture?
Based on the previous findings, the best practices
Cloud Service Provider Total Cost
for reducing cost were used in a migration process
AWS Lambda $6.60
from Monolithic to FaaS architecture. Implement-
Azure Function $6.40
ing the best practices during the migration phase Google Function $8.75
optimised the application for reduced cost while IBM Functions $5.10
running in a FaaS architecture.
Contribution to Field – This research examines sev-
eral research breakthroughs in the area of FaaS. These
include research into cost optimisation, industry pat- 5. Experiments and Evaluation
terns, and migration techniques of alternative architec- Azure Functions was the chosen service to host the server-
ture styles. We contribute to the existing literature by less function throughout this research. Two Function
considering the decomposition from monolithic to a FaaS Apps were required, each had a runtime of .Net Core 3.1,
architecture. Application granularity was also identi- specified the consumption plan and hosted the serverless
fied as a trend with architecture styles progressing from functions. A single VM was provisioned to run the ex-
monolithic to SOA to Microservices and the future of periments. The purpose of the Azure VM was to host a
FaaS. The migration technique outlined in this paper pro- docker image containing a benchmark application that
poses a technique for decomposing a monolithic appli- would generate traffic to the Azure Function endpoints.
cation into serverless functions while reducing memory An Azure SQL Database was used during the experimen-
consumption and execution duration. Therefore, reduc- tal phase of this research. Both experiments required a
ing the overall hosting costs consumed by the serverless database in which the serverless functions could interact.
functions. Considering the gap in the field of study when A single Azure SQL Server was used to host both the
it comes to migration techniques and best practices, this database used in the experiments.
research bridges the existing software architectural gap Application Insights was used to analyse the perfor-
for FaaS. mance of the Azure Functions. Data was exported from
Application Insights by querying the logs for the relevant
4. Cost Breakdown Analysis data. The analytical data of interest during the experi-
ment was the duration of the requests and the memory
We analysed the cost implications of hosting serveries
consumption of the serverless functions on the host ma-
functions by four major cloud providers (CSP). All four of
chine.
the major cloud service providers of FaaS provide a pay
per execute model [17, 18, 19, 20]. More specifically we 5.1. Experimental Design
analysed the pricing models of AWS Lambda, Azure Func-
tions, Google Functions and IBM Functions. A simple use Analysis of Serverless Functions experiment –
case was applied to each pricing model: A function with Analysed the memory consumption of a group of server-
128MB of memory, invoked 8 million times per month and less functions. Every iteration, the functions were refac-
running for 300ms each time. 2
https://github.com/adam-stafford1/Cost-
In a real-world scenario, calculating costs would not be Aware-Migration-to-Functions-as-a-Service-
as straightforward as the running time may vary, hence, Architecture/blob/main/CostBreakdownAnalysis.pdf
tored in an attempt to reduce memory usage, execution
duration and ultimately reduce the running costs. Re-
quests were sent to the serverless functions hourly for
24 hours with varying payloads. After three runs, the
mean average was calculated for that iteration and the
serverless functions were analysed, in terms of memory
consumption, execution duration and cost before refac-
toring and conducting further analysis. The findings Figure 1: Experiment Design Diagram
were used to develop a set of serverless function best
practices. These practices facilitated the development of
a migration technique.
Iteration 1 - Baseline – The initial iteration of this group of serverless functions from the monolith. The
experiment produces a baseline to which other iterations decomposed functions are analysed for cost in a FaaS
could be compared before refactoring. environment before the discovered best practices from
Iteration 2 - Combining Serverless Functions – the Analysis of Serverless Functions experiment were
The serverless functions DatabaseQuery and Database- applied. After applying the best practices the functions
QuerySingle are combined into a single function. The are analysed a second time to evaluate the quality of the
newly created function executed the appropriate func- change and the reduction in price the implementation
tionality for each of the endpoints based on the param- had on the serverless functions.
eters provided. The parameters passed to the function The application used for this experiment was a sample
specified if the request was to execute the DatabaseQuery application developed by Microsoft, eShopLegacyMVC
or the DatabaseQuerySingle functionality. and publicly available on Github3 . The application was
Iteration 3 - Asynchronous Functions – In this itera- developed as part of a series of tutorials in which Mi-
tion, the serverless endpoints are refactored to run asyn- crosoft guides on best practices and modernising applica-
chronously. The purpose of this is to increase the per- tions and is publicly available. This particular application
formance of the serverless function by introducing the was developed as a starting point in a tutorial for mod-
asynchronous programming model and best practice. ernising legacy .net framework applications to the Azure
Iteration 4 - Dependency Injection – During this it- Cloud and Windows Containers and comes with an ac-
eration, the serverless functions are refactored to use companying PDF document4 .
dependency injection for the creation and disposal of the
database context. The database context is registered with 5.2. Analysis of FaaS Serverless
the scope lifetime. Once the database context was set up Functions Results
it is injected into each of the required serverless function
classes. For this experiment, the data provided for the Total Mem-
Iteration 5 - GET vs POST – For this iteration, two ory usage is presented by the total number of Private
serverless functions are refactored to accept data via a Bytes consumed on that given day for all serverless func-
GET request instead of POST. CalculateTotal and Dis- tions. The Total Execution Duration is presented by the
tance are both refactored to accept data via a GET re- total execution time in milliseconds for the given day.
quest. The data exported represents the combined sum of all
Iteration 6 - Changing the ORM – It is discovered that running serverless functions. All cost estimations were
the out-of-the-box .Net ORM, Entity Framework Core based on 8 million requests per month.
was not the most efficient ORM in terms of performance. Iteration 1 - Baseline – This initial iteration is exe-
An alternative ORM was discovered known as Dapper. cuted to set a baseline for comparison with future iter-
Dapper boasted better performance in comparison to ations. Memory consumption and execution duration
Entity Framework Core. Basheleishvili et al. [21] identi- metrics of the serverless functions were exported daily.
fied the performance improvements of Dapper over the As these metrics do not show consistent results on each
standard Entity Framework. Enetity Framework Core is run the average of the three days was calculated and used
replaced with Dapper as part of this iteration. for comparison.
Figure 1 presents an experiment design diagram il- Iteration 2 - Function Combination – The purpose
lustrating the experimental process for the Analysis of of this iteration is to analyse the behaviour of the server-
Serverless Functions experiment. less functions when the functionality of two functions
was combined into a single function. In combining the
Decomposition of Monolithic to Serverless Func-
tions experiment – Analysed a monolithic application
3
and created a decomposition technique to produce a https://github.com/dotnet-architecture/eShopModernizing/
4
https://aka.ms/liftandshiftwithcontainersebook/
Table 2 ommended best practice for Azure functions to be asyn-
Iteration 1 Results chronous non-blocking calls [22]. When analysing the
Date of Run Total Memory Usage Total Execution Duration
22/02/2021 544,871,743,488 2,472,551.827 functions, several were identified which did not adhere
18/03/2021 527,623,954,432 2,634,156.957 to this best practice. Ensuring that the functions ran
19/03/2021 567,170,166,784 2,564,192.976
asynchronous non-blocking calls was the next refactor-
Average 546,555,288,235 2,556,967.25333 ing iteration of this research. DatabaseQueryForReport,
Cost Estimation $36.80
DatabaseQuerySingle, DatabaseWrite, DatabaseQuery,
DownloadFile, and GenerateBarcodeImage were all up-
dated to run asynchronously using the async/await oper-
ators of the C# language [23].
Table 4
Iteration 3 Results
Date of Run Total Memory Usage Total Execution Duration
27/02/2021 565,889,548,288 2,545,098.398
14/03/2021 601,180,618,752 2,716,128.474
30/03/2021 649,217,093,632 3,336,305.686
(a) Total Memory Usage (b) Total Execution Duration
Average 607,729,938,432 2,865,844.186
Cost Estimation $40.00
Figure 2: Iteration 1 Line Chart Baseline Comparison +61,174,650,197 +308,876.93267
functions, this iteration aimed to eliminate the perfor-
mance implications of cold starts on a single function.
This newly created function handled the network traffic
for both of the previous functions.
Table 3
Iteration 2 Results
Date of Run Total Memory Usage Total Execution Duration
24/02/2021 565,889,548,288 2,641,953.29 (a) Total Memory Usage (b) Total Execution Duration
25/03/2021 639,237,783,552 2,716,128.474 Figure 4: Iteration 3 Line Chart
28/03/2021 618,846,830,592 2,724,818.97
Average 607,991,387,477 2,694,300.24467
Cost Estimation $40.00
Baseline Comparison +61,436,099,242 +137,332.99134
As shown in Table 4, there is an increase in the memory
consumption and the execution duration compared to the
baseline run of the experiment. After further inspection
into the results and researching the best practice, it is
discovered that serverless functions were charge for the
time that the function waits for the results of an async
request [24].
These results demonstrate that enforcing functions to
run asynchronously can increase memory consumption
and duration. However, the serverless functions pro-
(a) Total Memory Usage (b) Total Execution Duration
duced for this experiment have no external dependencies.
Using asynchronous programming in cases where the
Figure 3: Iteration 2 Line Chart
function does not require a response from an external
As shown in Table 3, there is an overall increase in dependency and can continue to execute calling multi-
memory consumption and execution duration compared ple dependencies asynchronously should have a positive
to the baseline iteration. Although this increase was not impact on the performance. Although, as demonstrated
substantial in the experiment, it would be quite substan- in this experiment enforcing the synchronous functions
tial on a larger scale. This enforces what is already a to run asynchronously has had a negative impact on
recommended best practice, to implement the single re- performance.
sponsibility pattern. Enforcing the single responsibility Iteration 4 - Dependency Injection Pattern – De-
pattern during the migration process is a recommended pendency injection is a commonly utilised best practice
best practice during the construction of the migration in which classes are decoupled from their dependencies
technique. to provide better modularisation of software [25]. For
Iteration 3 - Asynchronous Functions – It is a rec- this iteration, the dependency injection pattern is applied
to the serverless functions to abstract the initialisation Table 6
of the database context. The goal of this iteration is to Iteration 5 Results
remove this initialisation from the serverless functions Date of Run
04/03/2021
Total Memory Usage
595,949,375,488
Total Execution Duration
2,446,181.996
to reduce the duration in which the functions executed 06/03/2021 610,399,891,456 2,621,606.274
and increase the performance of the functions. The 07/03/2021 597,077,692,416 2,509,399.675
Average 601,142,319,787 2,525,729.315
Cost Estimation $36.80
Table 5 Baseline Comparison +54,587,031,552 -38,463.661
Iteration 4 Results
Date of Run Total Memory Usage Total Execution Duration
01/03/2021 578,505,195,520 2,663,114.111
22/03/2021 616,094,019,584 2,645,294.872
23/03/2021 549,142,319,104 2,549,578.342
Average 581,247,178,069 2,619,329.10833
Cost Estimation $36.80
Baseline Comparison +34,691,889,834 +62,361.855
(a) Total Memory Usage (b) Total Execution Duration
Figure 6: Iteration 5 Line Chart
requests. However, POST requests perform better in
terms of memory consumption.
(a) Total Memory Usage (b) Total Execution Duration
Figure 10 presents a comparison of the two refactored
Figure 5: Iteration 4 Line Chart function. Since the memory consumption of individ-
ual functions is not a supported metric exportable from
results displayed in Table 5 shows that although the de-
Azure Application Insights, the function duration was
pendency injection pattern increased modularity and
used for comparison. The bar chart displays the duration
testability it has a negative impact on the running costs
of the two modified functions from the fifth iteration
of the serverless functions. Dependency injection has
compared to the baseline iteration. The bar chart in fig-
its own merits, including the testability of functions. It
ure 10 highlights the reduction in duration when using
is a known best practice in the industry. However, this
GET over POST for these functions. Following this dis-
research is focused solely on optimising costs. Therefore,
covery, the migration technique favours GET over POST
this research recommends that before implementing the
methods were applicable.
dependency injection pattern in a FaaS environment, the
change should be evaluated to identify the impact on the
hosting costs.
Iteration 5 - GET vs POST – In this iteration, the
serverless functions are modified to examine the effect of
different HTTP methods. Several endpoints were modi-
fied from accepting data via a POST request to accepting
via a GET request. This change also affected the function
code as the different HTTP methods required different
parsing functionality. With a GET method, the data is
taken straight from the query parameters but required
manual parsing of integers or decimals. With the POST
method, data in the body of the request is parsed using
a stream reader. Therefore, this iteration tested the ef-
ficiency of the HTTP methods and the parsing method Figure 7: Iteration 5 Duration Comparison
required with each. Table 6 presents the findings of this Iteration 6 - Changing the ORM – The Object Rela-
iteration. tional Model (ORM) is replaced from Entity Framework to
Table 6 presents the results of the GET vs POST it- Dapper. The Dapper ORM boasted performance improve-
eration. The iteration produced interesting results. As ments compared to the Entity Framework ORM. Several
shown, the average memory consumption has increased. serverless functions are refactored to use the improved
However, the average execution duration has decreased ORM and tested to identify how this change affected the
compared with the baseline iteration. It is gathered from performance in a FaaS architecture.
these results that GET requests execute faster than POST Table 7 shows an overall improvement in performance
compared to the baseline iteration. This is the first itera- identified that some of the industry recommended pat-
tion to demonstrate a successful improvement in memory terns may have benefits in other aspects of software con-
consumption and execution duration. Figure 9 presents struction however, they increased the memory consump-
the duration of the serverless functions which had been tion of the serverless function group and therefore, would
refactored to use the Dapper ORM. increase the overall hosting costs. These results demon-
The results in Figure 9 show a significant improvement strate unclarity regarding cost implications of CSPs rec-
in the duration of the serverless functions as a group and ommended best practices. This experiment is successful
individually. For each of the four functions, the duration in producing best practices based on these two factors.
dropped by more than half. This is a very clear indicator Although some of the best practices may go against in-
that this refactoring iteration is successful in improving dustry recommendations, this experiment was focused
the performance and reducing the costs. When construct- solely on memory consumption and the execution dura-
ing the migration technique, the ORM was analysed and tion of the serverless function. As discussed in section
replace with the Dapper ORM due to its improvements 4, these two metrics contribute to the costs of running
in performance when running in a FaaS environment. serverless functions across all of the leading CSPs.
Table 7
Iteration 6 Results
Date of Run Total Memory Usage Total Execution Duration
30/03/2021 498,894,196,736 2,234,666.598
31/03/2021 561,415,585,792 2,102,961.566
01/04/2021 580,808,814,592 2,177,295.468
Average 547,039,532,373 2,171,641.21067
Cost Estimation $33.60
Baseline Comparison +484,244,138 -385,326.04266
Figure 10: Summary of the Discovered Best Practices
5.4. Decomposition of Monolithic to
Serverless Functions Results
In this section, the results of the Decomposition of Mono-
lithic to Serverless Functions experiment are presented
and evaluated. The functions suitable for migration to
(a) Total Memory Usage (b) Total Execution Duration a FaaS architecture are identified from a monolithic ap-
plication and extracted into serverless functions. Once
Figure 8: Iteration 6 Line Chart extracted, the functions are deployed to an Azure Func-
tion app. The performance of the serverless functions
was monitored over three days to estimate the hosting
cost. Next, the previously discovered best practices were
implemented and the functions redeployed to the Azure
Function app where they were monitored for a further
three days. The experiment provided the data required to
evaluate the effectiveness of the best practices discovered
in the Analysis of FaaS Serverless Functions experiment
and were used to construct the migration technique.
Function Extraction – The Data Access Layer was
identified as suitable for extraction to a FaaS environment
during this experiment. The functions were identified
by understanding the limitations and suitability of FaaS.
Once identified, an Azure Function app was created and
Figure 9: Iteration 6 Duration Comparison all function dependencies were migrated into the new
function app. This included the database context used
by the functions to manipulate the database as well as
5.3. Discovered Best Practices any data model object classes. The functions were refac-
The experiment successfully produced several best prac- tored to run in a FaaS environment, accepting data via
tices (Figure 10) to adhere to when migrating functions to RESTful endpoints instead of direct dependencies. Fi-
a FaaS environment. Throughout the experiment, it was nally, the functions were migrated and deployed to the
Azure Function app. Table 9
Setting a Baseline – The serverless functions ex- Best Practices Applied
tracted from the monolithic application are deployed to
the Azure Function app. With the functions running in Best Prac- Changes Applied
Azure, the benchmark application is deployed to a virtual tice
machine to generate traffic to the endpoints. This experi- Single Re- Each of the functions extracted performed
ment demonstrated the cost implications of the migration sponsibility some form of CRUD operation on the
technique by comparing the memory consumption and Pattern database and each had a single purpose.
execution duration before and after the best practices are For that reason, the function had already
implemented. The total memory consumption and total adhered to the single responsibility pat-
execution duration exported from Azure Application In- tern.
sights. Table 8 presents the results of the serverless func- Async Func- Each of the extracted functions ran syn-
tions chronously, the second best-practice iden-
tions before the best practices were implemented. This
tified that running synchronous functions
initial iteration shows the average memory consumption asynchronously had a negative impact on
of 531,748,489,899 bytes per day and an average execution the performance of the functions. There-
duration of 631,612.481 milliseconds per day. fore, for the extracted functions, no asyn-
Table 8 chronous code was introduced.
Experiment 2 Before Best Practices Dependency The dependency injection pattern was re-
Date Total Memory Usage Total Execution Duration Injection moved and replaced with the C# using
28/03/2021 531,556,438,016 642,659.234 statement to instantiate and dispose of the
29/03/2021 531,175,735,296 615,578.125 database context within the function code.
30/03/2021 532,513,296,384 636,600.084 Favour GET Due to the complex data type being sent
Average 531,748,489,899 631,612.481 over POST in each request, the endpoints could not
be changed to use the GET method over
POST.
Applying Best Practices – Table 9 presents the Changing The Entity Framework ORM and that was
changes made to the application when applying the best the ORM replaced by the Dapper ORM
practices
Evaluating Best Practices – After the initial execu-
tion, the serverless functions were refactored to imple- Table 10
ment the previously discovered best practices outlined Experiment 2 After Best Practices
in section 5.3. After refactoring, the functions were re- Date Total Memory Usage Total Execution Duration
deployed and analysed a second time to demonstrate 22/04/2021
23/04/2021
497,534,685,184
513,865,043,968
392,567.499
416,414.657
any performance. Table 10 presents the results of this 26/04/2021 500,492,288,000 360,939.096
experiment. Table 10 displays a significant improve- Average 503,964,005,717 389,973.750667
ment in performance across the three days. The average Compared to Baseline -27,784,484,182 -241,638.730333
was compared to the average prior to the best practices
being implemented. The results show the number of
bytes consumed per day on average by the functions was
reduced by 27,784,484,182 bytes or 27.78 GB, and the to- the experiments didn’t run for a consecutive month, a
tal execution duration was reduced by 241,638.730333 value of 8 million requests per month was used to calcu-
milliseconds or 241.64 seconds. This simple refactoring late the costs. This value was purely for demonstration
experiment identifies the importance of optimisation in purposes and didn’t impact the differences in costs since
a serverless environment. The results demonstrate a sig- it was the same for both the before and after best practices
nificant improvement in memory consumption and exe- calculations. Table 11 presents the exported data.
cution duration with a simple implementation of several
best practices. Table 11
Evaluating the Cost Reduction of the Migration Additional Exported Metrics
Technique – The cost presented in Azure only displayed Request Count Memory Usage Execution Duration
Before Best Practices 8,000,000 229 MB 0.44208 s
the overall cost for the monthly billing period and not a After Best Practices 8,000,000 224 MB 0.25 s
detailed breakdown. For that reason, a manual calcula-
tion must be performed to present the cost analysis. Ad-
ditional data was required to calculate the cost. This data The formula for calculating the cost is given as:
exported from Azure Application Insights included the
average allocated memory per execution in megabytes 𝑇 𝑜𝑡𝑎𝑙𝐶𝑜𝑠𝑡 = (𝑇 𝑜𝑡𝑎𝑙𝐺𝐵𝑠 × $0.000016)
and the average duration per execution in seconds. Since + (𝑅𝑞𝑠𝑡.𝐶𝑜𝑢𝑛𝑡 × $0.00000020)
𝑇 𝑜𝑡𝑎𝑙𝐺𝐵𝑠 = (𝑅𝑞𝑠𝑡.𝐶𝑜𝑢𝑛𝑡 × 𝐸𝑥𝑒.𝐷𝑢𝑟𝑎𝑡𝑖𝑜𝑛) Similar to the identification of functions from a mono-
× (𝑀 𝑒𝑚𝑜𝑟𝑦𝑈 𝑠𝑎𝑔𝑒 ÷ 1024) lithic application outlined in this research, Mazlami et al.
[27] identified a technique for identifying Microservices
Using the data and formulas presented in this section, in a monolithic application. In the five phase migration
the costs of hosting the serverless functions could then be technique outlined in this research, the serverless func-
calculated. Firstly, the cost of hosting the functions was tions are identified by simply understanding the applica-
calculated before the best practices were implemented. tion and the FaaS environment. In addition, the mono-
lithic application was categorised in terms of the multiple
𝑇 𝑜𝑡𝑎𝑙𝐺𝐵𝑠 = (8000000 × 0.44208) layers before the extraction was applied. In the research
× (256 ÷ 1024) = 884160 carried out by Mazlami et al., they discuss a much more
𝑇 𝑜𝑡𝑎𝑙𝐶𝑜𝑠𝑡 = (884160×$0.000016)+(8×$0.20) = $15.75 in-depth technique of identifying the Microservices. The
formal model proposed in the research uses a clustering
Next, after the serverless function had been refactored
algorithm to generate recommendations for potential mi-
to implement the best practices, the hosting costs were
calculated again. croservice candidates throughout the refactoring process.
The migration technique proposed in this paper, provides
𝑇 𝑜𝑡𝑎𝑙𝐺𝐵𝑠 = (8000000 × 0.24) a more hands-on approach and focuses more on the code
× (224 ÷ 1024) = 480000 refactoring and performance optimisation of the migra-
tion. However, this comparison opens up future work to
𝑇 𝑜𝑡𝑎𝑙𝐶𝑜𝑠𝑡 = (480000×$0.000016)+(8×$0.20) = $9.28
identify a formal model for the extraction of functions
As shown from the calculations, the total charge after from a monolithic application.
implementing the best practices was calculated as $9.28.
This shows a reduction in overall running costs of the 6. Conclusions
serverless functions of $6.25. The experiment was con- FaaS currently lacks the industry standards of its estab-
ducted on a relatively small scale and reduced the cost by lished architectural predecessors and this research pro-
40%. This hugely significant cost reduction was produced poses a technique to help bridge this gap.
by simply understanding the FaaS environment and how We propose several best practices which feed into a mi-
code refactoring can impact the memory consumption gration technique. The proposed five-phased technique
and duration of the functions. It also illustrates the im- facilitates the migration of a monolithic architecture to a
portance of optimisation to reduce costs when hosting FaaS environment with a focus on optimizing for reduc-
serverless functions. ing hosting costs.
Evaluating & Comparing Migration Techniques Furthermore, in our experiments we identified several
– To the best of our knowledge, no established migration industry standards or recommendations that although
techniques of monolithic to the FaaS architecture exist in have their own merits, had a negative impact on cost. We
the field of FaaS. In this section, the migration technique identified several functions suitable for migration from a
outlined in this research is evaluated against similar tech- monolithic application to the FaaS architecture. When
niques from alternative architectures. As part of this extracting the functions according to the proposed best
evaluation, two techniques from the Microservices archi- practices, our experiments point towards significant sav-
tecture style have been identified as suitable comparisons ings in terms of the overall hosting cost of the serverless
to the technique outlined in this research. functions.
Agarwal & Lakshmi [26], identify the shortcomings This research opens the area of FaaS in terms of mem-
of some Microservices deployments and focus their re- ory consumption and optimisation and provides insights
search on optimising costs in terms of sizing and scaling into the behaviour of this architecture. Future work will
of the Microservices. Although with FaaS the scaling focus in identifying additional refactoring methods and
is taken care of by the cloud services providers, this re- analyse different types of applications and use cases for
search has similarities in terms of the consumption of serverless functions to refactor and develop this migra-
additional unused resources. Agarwal & Lakshmi pro- tion technique into a pattern verified across different
pose an algorithm for enabling real-time scaling deci- application types.
sions to reduce the amount of unused resources occupied The migration technique completed as part of this
by the Microservices. In comparison, the Migration of research encourages the adaptation of FaaS architecture
Monolithic Applications to Functions-as-a-Service Ar- and identifies the cost implications of code refactoring
chitecture for Reduced Hosting Cost technique outlined when working working with the architecture style.
in this research goes slightly further than the size and
scaling and identifies code refactoring techniques which
ultimately reduce the amount of resources consumed by
the functions.
References start influencing factors in function as a service, in:
2018 IEEE/ACM International Conference on Utility and
[1] S. Li, H. Zhang, Z. Jia, Z. Li, C. Zhang, J. Li, Q. Gao, J. Ge, Cloud Computing Companion (UCC Companion), IEEE,
Z. Shan, A dataflow-driven approach to identifying mi- 2018, pp. 181–188.
croservices from monolithic applications, The Journal [16] D. Bermbach, A.-S. Karakaya, S. Buchholz, Using ap-
of systems and software 157 (2019) 110380. plication knowledge to reduce cold starts in faas ser-
[2] M. Abdullah, W. Iqbal, A. Erradi, Unsupervised learning vices, in: Proceedings of the 35th Annual ACM Sym-
approach for web application auto-decomposition into posium on Applied Computing, SAC ’20, Association
microservices, The Journal of systems and software 151 for Computing Machinery, New York, NY, USA, 2020, p.
(2019) 243–257. 134–143. URL: https://doi-org.cit.idm.oclc.org/10.1145/
[3] N. Serrano, J. Hernantes, G. Gallardo, Service-oriented 3341105.3373909. doi:10.1145/3341105.3373909.
architecture and legacy systems, IEEE software 31 (2014) [17] AWS, Aws lambda, 2021. URL: https://aws.amazon.com/
15–19. lambda/, [Accessed 21-February-2021].
[4] D. Taibi, J. Spillner, K. Wawruch, Serverless computing- [18] Microsoft, Azure functions, 2021. URL: https://azure.
where are we now, and where are we heading?, microsoft.com/en-us/services/functions/, [Accessed 21-
IEEE Software 38 (2021) 25–31. doi:10.1109/MS.2020. February-2021].
3028708. [19] Google, Google cloud functions, 2021. URL: https:
[5] S. Eismann, J. Scheuner, E. van Eyk, M. Schwinger, //cloud.google.com/functions, [Accessed 21-February-
J. Grohmann, N. Herbst, C. L. Abad, A. Iosup, IT- 2021].
fakulteten, d. G. Institutionen för data-och information- [20] IBM, Ibm functions, 2021. URL: https://cloud.ibm.com/
steknik, D. of Computer Science, C. S. G. Engineering, functions/, [Accessed 21-February-2021].
G. universitet, G. University, I. Faculty, Serverless appli- [21] D. Zmaranda, L.-L. Pop-Fele, C. Gyorödi, R. Gyorodi,
cations: Why, when, and how?, IEEE software 38 (2021) G. Pecherle, Performance comparison of crud methods
32–39. using net object relational mappers: A case study, In-
[6] P. Castro, V. Ishakian, V. Muthusamy, A. Slominski, ternational Journal of Advanced Computer Science and
The rise of serverless computing, Commun. ACM Applications 11 (2020).
62 (2019) 44–54. URL: https://doi-org.cit.idm.oclc.org/10. [22] Microsoft, Best practices for performance and re-
1145/3368454. doi:10.1145/3368454. liability of azure functions, 2021. URL: https:
[7] B. Varghese, R. Buyya, Next generation cloud //docs.microsoft.com/en-us/azure/azure-functions/
computing: New trends and research directions, functions-best-practices/, [Accessed 17-March-2021].
Future Generation Computer Systems 79 (2018) [23] A. Santhiar, A. Kanade, Static deadlock detection for
849–861. URL: https://www.sciencedirect.com/ asynchronous c# programs, volume 128414, ACM, 2017,
science/article/pii/S0167739X17302224. doi:https: pp. 292–305.
//doi.org/10.1016/j.future.2017.09.020. [24] Microsoft, Estimating consumption plan costs,
[8] A. Eivy, Be wary of the economics of "serverless" cloud 2019. URL: https://docs.microsoft.com/en-us/azure/
computing, IEEE Cloud Computing 4 (2017) 6–12. azure-functions/functions-consumption-costs/, [Ac-
[9] K. Mahajan, D. Figueiredo, V. Misra, D. Rubenstein, cessed 01-April-2021].
Optimal pricing for serverless computing, in: 2019 [25] R. Laigner, M. Kalinowski, L. Carvalho, D. Mendonça,
IEEE Global Communications Conference (GLOBE- A. Garcia, Towards a catalog of java dependency injec-
COM), 2019, pp. 1–6. tion anti-patterns, in: Proceedings of the XXXIII Brazil-
[10] S. Hong, A. Srivastava, W. Shambrook, T. Dumitras, ian Symposium on Software Engineering, SBES 2019,
Go serverless: Securing cloud via serverless design pat- Association for Computing Machinery, New York, NY,
terns, in: 10th USENIX Workshop on Hot Topics USA, 2019, p. 104–113. URL: https://doi-org.cit.idm.oclc.
in Cloud Computing (HotCloud 18), USENIX Associa- org/10.1145/3350768.3350771. doi:10.1145/3350768.
tion, Boston, MA, 2018. URL: https://www.usenix.org/ 3350771.
conference/hotcloud18/presentation/hong. [26] P. Agarwal, J. Lakshmi, Cost aware resource sizing
[11] R. Rabbah, N. M. Mitchell, S. Fink, O. L. Tardieu, Server- and scaling of microservices, in: Proceedings of the
less composition of functions into applications, 2021. US 2019 4th International Conference on Cloud Comput-
Patent 10,896,181. ing and Internet of Things, CCIOT 2019, Association
[12] P. Bernstein, T. Porter, R. Potharaju, S. Venkatara- for Computing Machinery, New York, NY, USA, 2019,
man, W. Wu, Serverless event-stream processing p. 66–74. URL: https://doi-org.cit.idm.oclc.org/10.1145/
over virtual actors, in: Conference on Innovative 3361821.3361823. doi:10.1145/3361821.3361823.
Data Systems Research (CIDR), 2019. URL: https: [27] G. Mazlami, J. Cito, P. Leitner, Extraction of microser-
//www.microsoft.com/en-us/research/publication/ vices from monolithic software architectures, IEEE,
serverless-event-stream-processing-over-virtual-actors/. 2017, pp. 524–531.
[13] D. Bardsley, L. Ryan, J. Howard, Serverless performance
and optimization strategies, IEEE, 2018, pp. 19–26.
[14] J. Nupponen, D. Taibi, Serverless: What it is, what to do
and what not to do, IEEE, 2020, pp. 49–50.
[15] J. Manner, M. Endreß, T. Heckel, G. Wirtz, Cold