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