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-peruse 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.
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 serverparent. 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 architecment. 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 archireplicated 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
Functions-as-a-Service to be the natural progression architecture style surpassing the latest trend of Microservices. Eismann et al. [5] report that users tend to adopt a serverless architecture to reduce their hosting costs.
The granularity of the architecture style that permits users to scale at the function level along with the pay-peruse pricing model of serverless functions are some of the reasons for the architecture style’s continued popularity growth. Considering this and the continued growth of 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 increaslies 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 adopwhen 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 servertial 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 functhat 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 ofers 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 afects
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 serverless 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 applications. Their patent describes the use of a proces- Research Questions – This research focuses on three sor which determines the primary function of a query research questions: sent by the user and identifies if that function is to be • How does refactoring several diferent serverless broken into subsidiary functions. This use of function functions for better performance1 afect the runchaining 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 refacpropose a virtual actor model as an ideal platform to toring iterations based on common best practices build a stream processing system. Using the virtual actor model as opposed to the traditional actor model on 1Performance optimisation was based on recommended pracassigned 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 afecting the running costs ing iteration, the memory usage and execution du- were found to be memory consumption and execution duration 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 rememory 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 for reducing cost were used in a migration process Cloud Service Provider Total Cost from Monolithic to FaaS architecture. Implement- AAzWurSe LFaumncbtdioan $$66..6400 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.
We analysed the cost implications of hosting serveries functions by four major cloud providers (CSP). All four of 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 Functions, Google Functions and IBM Functions. A simple use case was applied to each pricing model: A function with 128MB of memory, invoked 8 million times per month and running for 300ms each time. 2https://github.com/adam-staford1/Cost
In a real-world scenario, calculating costs would not be Aware-Migration-to-Functions-as-a-Serviceas straightforward as the running time may vary, hence, Architecture/blob/main/CostBreakdownAnalysis.pdf
Analysed the memory consumption of a group of serverless functions. Every iteration, the functions were refacContribution to Field – This research examines several research breakthroughs in the area of FaaS. These include research into cost optimisation, industry patterns, and migration techniques of alternative architecture styles. We contribute to the existing literature by considering the decomposition from monolithic to a FaaS architecture. Application granularity was also identiifed as a trend with architecture styles progressing from monolithic to SOA to Microservices and the future of FaaS. The migration technique outlined in this paper proposes a technique for decomposing a monolithic application into serverless functions while reducing memory consumption and execution duration. Therefore, reducing the overall hosting costs consumed by the serverless functions. Considering the gap in the field of study when it comes to migration techniques and best practices, this research bridges the existing software architectural gap for FaaS.
less function throughout this research. Two Function Apps were required, each had a runtime of .Net Core 3.1, specified the consumption plan and hosted the serverless functions. A single VM was provisioned to run the experiments. The purpose of the Azure VM was to host a docker image containing a benchmark application that would generate trafic to the Azure Function endpoints.
An Azure SQL Database was used during the experimental phase of this research. Both experiments required a database in which the serverless functions could interact.
A single Azure SQL Server was used to host both the database used in the experiments.
Application Insights was used to analyse the performance of the Azure Functions. Data was exported from Application Insights by querying the logs for the relevant data. The analytical data of interest during the experiment was the duration of the requests and the memory consumption of the serverless functions on the host machine. tored in an attempt to reduce memory usage, execution duration and ultimately reduce the running costs. Requests 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 refactoring 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 Mition, the serverless endpoints are refactored to run asyn- crosoft guides on best practices and modernising applicachronously. 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 modasynchronous 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 aceration, 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 funcGET 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 eficient ORM in terms of performance. Iteration 1 - Baseline – This initial iteration is exeAn alternative ORM was discovered known as Dapper. cuted to set a baseline for comparison with future iterDapper 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. ifed 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 serverServerless Functions experiment. less functions when the functionality of two functions was combined into a single function. In combining the
tions experiment – Analysed a monolithic application and created a decomposition technique to produce a
(a) Total Memory Usage
(b) Total Execution Duration functions, this iteration aimed to eliminate the performance implications of cold starts on a single function.
This newly created function handled the network trafic for both of the previous functions. ommended best practice for Azure functions to be asynchronous non-blocking calls [22]. When analysing the functions, several were identified which did not adhere to this best practice. Ensuring that the functions ran asynchronous non-blocking calls was the next refactoring iteration of this research. DatabaseQueryForReport, DatabaseQuerySingle, DatabaseWrite, DatabaseQuery, DownloadFile, and GenerateBarcodeImage were all updated to run asynchronously using the async/await operators of the C# language [23].
Total Memory Usage Total Execution Duration 565,889,548,288 2,641,953.29 639,237,783,552 2,716,128.474 618,846,830,592 2,724,818.97 607,991,387,477 2,694,300.24467 $40.00 +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. Figure 3: Iteration 2 Line Chart Using asynchronous programming in cases where the 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 multimemory 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 – Depattern 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 of the database context. The goal of this iteration is to remove this initialisation from the serverless functions to reduce the duration in which the functions executed and increase the performance of the functions. The
Total Memory Usage Total Execution Duration 578,505,195,520 2,663,114.111 616,094,019,584 2,645,294.872 549,142,319,104 2,549,578.342 581,247,178,069 2,619,329.10833 $36.80 +62,361.855
Total Memory Usage Total Execution Duration 595,949,375,488 2,446,181.996 610,399,891,456 2,621,606.274 597,077,692,416 2,509,399.675 601,142,319,787 2,525,729.315 $36.80
-38,463.661 (a) Total Memory Usage requests. However, POST requests perform better in terms of memory consumption.
Figure 10 presents a comparison of the two refactored function. Since the memory consumption of individual functions is not a supported metric exportable from Azure Application Insights, the function duration was used for comparison. The bar chart displays the duration of the two modified functions from the fifth iteration compared to the baseline iteration. The bar chart in figure 10 highlights the reduction in duration when using GET over POST for these functions. Following this discovery, the migration technique favours GET over POST methods were applicable. compared to the baseline iteration. This is the first iteration to demonstrate a successful improvement in memory consumption and execution duration. Figure 9 presents the duration of the serverless functions which had been refactored to use the Dapper ORM.
The results in Figure 9 show a significant improvement in the duration of the serverless functions as a group and individually. For each of the four functions, the duration dropped by more than half. This is a very clear indicator that this refactoring iteration is successful in improving the performance and reducing the costs. When constructing the migration technique, the ORM was analysed and replace with the Dapper ORM due to its improvements in performance when running in a FaaS environment. identified that some of the industry recommended patterns may have benefits in other aspects of software construction however, they increased the memory consumption of the serverless function group and therefore, would increase the overall hosting costs. These results demonstrate unclarity regarding cost implications of CSPs recommended best practices. This experiment is successful in producing best practices based on these two factors.
Although some of the best practices may go against industry recommendations, this experiment was focused solely on memory consumption and the execution duration of the serverless function. As discussed in section 4, these two metrics contribute to the costs of running serverless functions across all of the leading CSPs.
Total Memory Usage Total Execution Duration 498,894,196,736 2,234,666.598 561,415,585,792 2,102,961.566 580,808,814,592 2,177,295.468 547,039,532,373 2,171,641.21067 $33.60 -385,326.04266 5.4. Decomposition of Monolithic to
Serverless Functions Results
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 PracAzure, the benchmark application is deployed to a virtual tice machine to generate trafic to the endpoints. This experi- Single Rement demonstrated the cost implications of the migration sponsibility technique by comparing the memory consumption and Pattern execution duration before and after the best practices are implemented. The total memory consumption and total execution duration exported from Azure Application Insights. Table 8 presents the results of the serverless func- Async Functions before the best practices were implemented. This tions initial iteration shows the average memory consumption of 531,748,489,899 bytes per day and an average execution duration of 631,612.481 milliseconds per day.
Applying Best Practices – Table 9 presents the Changing changes made to the application when applying the best the ORM practices
Evaluating Best Practices – After the initial execution, 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 2223//0044//22002211 459173,,583645,,608453,,198648 349126,,546174..469597 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 calcumilliseconds 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 diferences 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
Technique – The cost presented in Azure only displayed Request Count Memory Usage Execution Duration the overall cost for the monthly billing period and not a BAeftefroBreesBtePsrtaPcrtaiccetsices 88,,000000,,000000 222249 MMBB 00..42452s08 s detailed breakdown. For that reason, a manual calculation must be performed to present the cost analysis. Additional 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 funccalculated. Firstly, the cost of hosting the functions was tions are identified by simply understanding the applicacalculated before the best practices were implemented. tion and the FaaS environment. In addition, the monolithic 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 tNoeimxtp,laefmteernthtethseerbveesrtlepsrsacfutincecsti,otnhehhadosbtienegn croesfatsctworeerde algorithm to generate recommendations for potential micalculated 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 migration. 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 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 estabducted on a relatively small scale and reduced the cost by lished architectural predecessors and this research pro40%. 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 micode 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 reducserverless 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 savtecture 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 memof 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 diferent types of applications and use cases for search has similarities in terms of the consumption of serverless functions to refactor and develop this migraadditional unused resources. Agarwal & Lakshmi pro- tion technique into a pattern verified across diferent 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.