Institute of Architecture of Application Systems,University of Stuttgart, Germany,

{yussupov, breitenbuecher, hahn, leymann}@iaas.uni-stuttgart.de

Serverless Parachutes: Preparing Chosen Functionalities for Exceptional Workloads

© 2019 IEEE Computer Society. Personal use of this material ispermitted. However, permission to reprint/republish this material foradvertising or promotional purposes or for creating new collective worksfor resale or redistribution to servers or lists, or to reuse any copyrightedcomponent of this work in other works must be obtained from the IEEE.

@inproceedings{Yussupov2019_ServerlessParachutes,author = {Vladimir Yussupov and Uwe Breitenb{\"u}cher and Michael Hahn

and Frank Leymann},title = {{Serverless Parachutes: Preparing Chosen Functionalities for

Exceptional Workloads}},booktitle = {Proceedings of the 2019 IEEE 23rd International Enterprise

Distributed Object Computing Conference (EDOC 2019)},publisher = {IEEE},year = 2019,month = oct,pages = {226--235},doi = {10.1109/EDOC.2019.00035}

}

:

Institute of Architecture of Application Systems

Vladimir Yussupov, Uwe Breitenbücher, Michael Hahn, Frank Leymann

Serverless Parachutes: Preparing ChosenFunctionalities for Exceptional Workloads

Vladimir Yussupov, Uwe Breitenbucher, Michael Hahn, and Frank LeymannInstitute of Architecture of Application Systems

University of Stuttgart, Universitatsstraße 38, Stuttgart, GermanyEmail: [vladimir.yussupov, uwe.breitenbuecher, michael.hahn, frank.leymann]@iaas.uni-stuttgart.de

Abstract—Function-as-a-Service (FaaS) is an emerging cloudservice model that enables composing applications using arbi-trary, small, and event-driven code snippets managed by cloudproviders and that can be scaled to zero. The scalability proper-ties of FaaS look attractive for handling rare or unexpected highloads that affect only particular functionalities of the application.However, deciding on the component granularity upfront orreengineering the architecture of an entire application for rareworkloads is often a very difficult challenge or even infeasible.In this work, we introduce a method that prepares annotatedfunctionalities for handling rare workloads by automaticallyextracting them from the source code of the application andadditionally deploying them as FaaS functions, while keeping theoriginal application’s functionalities and architecture unchanged.In this way, the benefits of FaaS can be leveraged without theneed to reengineer the application only for rare cases. We validateour method by means of a prototype, evaluate its feasibility in aset of experiments, and discuss limitations and future work.

Keywords-Serverless, FaaS, Function-as-a-Service, Scalability,Failover, Annotation

I. INTRODUCTION

Cloud computing is an essential building block in the ITlandscape of many modern enterprises [1]. The widespreadadoption of cloud computing is the result of its substantial ben-efits, such as elasticity and continuous deployment at globalscale [2]. One typical example is the usage of cloud computeresources instead of buying the hardware. Unlike traditionalinfrastructure investments, it is notably easier to deal with re-dundant compute resources in the cloud, which helps reducingcosts. Likewise, using higher abstraction layers, e.g., platformor software, helps further reducing the maintenance burdenand optimizing development and operations processes. In thecontext of cloud, the serverless computing paradigm furtherabstracts away the infrastructure by focusing on developingapplications using only provider-managed components. Whilebeing a broader concept, the term serverless is often used todescribe a particular cloud service model, called Function-as-a-Service (FaaS). FaaS hides the infrastructure by allowing todeploy arbitrary, fine-grained, event-driven code snippets [3],[4], which are fully managed by providers. As a result, thescaling is automatically performed by providers, and, more-over, FaaS deployments can be scaled to zero, allowing to payonly for the actual usage of functions, without considering theidle time [5]. The prominent examples of public FaaS offeringsare AWS Lambda [6] and Microsoft Azure Functions [7].

Event-driven, FaaS-hosted functions are attractive for deal-ing with rare or unpredictable high workloads, since functionsare automatically scaled by providers without limits. However,(i) deploying every functionality to FaaS is not often appro-priate and can result in complex, unmanageable applicationarchitectures with thousands of components. For example,deploying two functionalities interacting via local calls to FaaSresults in a communication overhead, as both now need tointeract in an event-driven manner. Additionally, (ii) choosingthe right components granularity, e. g., whether it is a FaaS-hosted function or the part of a PaaS-hosted component, isa highly non-trivial challenge [8]–[10]. Moreover, (iii) oftenit is even not possible to use FaaS for certain function-alities as it strongly impacts the application’s architecture.Therefore, keeping crucial application functionalities availablevia FaaS requires big efforts and comes with far-reachingdesign decisions—ironically, only to prepare the applicationfor hypothetical workloads that might never occur.

In this paper, we tackle this issues and present a methodfor preparing crucial application functionalities for exceptionalworkloads by leveraging the advantages of the FaaS cloud ser-vice model without the need to change the actual architectureof the application. In our method, parts of the application’ssource code are first enriched with annotations, which enablesthe automated extraction and generation of FaaS-deployablefunction bundles called serverless parachutes. These bundlesare deployed to FaaS offerings as backup routes for handlingexceptional workloads, whereas original functionalities of theapplication and the application itself are used as-is in regularcases. The most important benefit of the method is thatit does not require reengineering the original application’sarchitecture or deciding on the right granularity of scalablecomponents upfront. To validate our method, we implement aprototype supporting the automatic extraction, generation, anddeployment of serverless parachutes. Furthermore, we performan evaluation by conducting a set of experiments, discuss theresults, and outline future research directions.

The remainder of this paper is structured as follows. In Sec-tion II, we define the problem statement, introduce a runningexample, and discuss the related work. We introduce theserverless parachutes method in Section III and elaborate onthe prototype and results of the evaluation in Section IVand Section V. Finally, Section VI concludes this paper.

II. PROBLEM STATEMENT AND RELATED WORK

In this section, we describe the relevant background, definethe problem statement and introduce a running example. Fur-thermore, we elaborate on the related work and its applicabilityto the highlighted problems.

A. Serverless Computing and Function-as-a-Service

Historically, the term serverless has been used in differentcontexts, from peer-to-peer communication and client side-only software to RFID protocols [11]–[13]. In the context ofcloud, the concept of serverless computing describes a pro-gramming model and architecture that focus on building ap-plications by composing functionalities that are executed in thecloud without the need to manage the underlying infrastruc-ture [3]. For example, (Mobile) Backend-as-a-Service (BaaS)and Function-as-a-Service (FaaS) service models fit into thiscategory. While the former focuses on combining third-partyAPIs to avoid having a traditional backend system, FaaSfocuses on using provider-managed, arbitrary, event-driven,and typically, stateless, code snippets as application buildingblocks. Both BaaS and FaaS abstract away the infrastructureand reduce the management effort and complexity, which givesthe impression that servers do not exist. However, the reducedmanagement efforts in no way mean that servers are absent.Instead, tasks such as resource provisioning, monitoring, scal-ing, and fault tolerance become a burden of cloud serviceproviders [3], [4]. Another important property of FaaS is thatthe application logic can be scaled to zero resulting in a newcost model where the application owner is not charged for idleperiods, which is not the case, e.g., in Platform-as-a-Servicedeployments. Despite the advantages, the FaaS service modelis typically not enough on its own for composing serverlessapplications and has certain limitations [14], [15]. For instance,stateless and ephemeral FaaS functions have limited lifetimeand often need store the state in shared storage systems such asAWS S3. These limitations are among the factors influencingthe decision on choosing the optimal component granularityand the cloud service model.

B. Problem Statement

Failures are imminent for software at any scale [16]–[18].Problems such as hardware failures or workload changes leadto resource exhaustion [18] and might cause a sudden systemoutage. Ironically, fault tolerance and recovery strategies mightalso lead to a system failure [17], e. g., Amazon’s outage,which happened in 2017 due to increased time of AWS S3services recovery, affected recovery strategies of other AWSservices. Often, crucial functionalities must remain availablein exceptional cases, which lead to sudden, unrecoverableresource exhaustion, e. g., disasters or improper infrastructureplanning. For instance, in cases of disasters, functionalities ofdisaster management systems supporting assistance operationsduring or after disasters must be available [19]. Dealing withunexpected resource exhaustion is also important for hybridclouds, e. g., the cloud bursting [20] approach allows burstingresources into public clouds to handle high load spikes.

Interestingly, several research works [19], [21] describe theauto-scaling and scale-to-zero features of FaaS as a suitable so-lution for withstanding exceptional workloads, due to the factthat availability and reliability are guaranteed by providers.If important functionalities could be made available as FaaS-hosted functions, the unexpected loads can be handled by ex-ecuting these functionalities at FaaS provider’s side. However,despite the scaling and availability advantages of FaaS, severalimportant factors can complicate the process of moving chosenfunctionalities to FaaS or even prevent it completely. Firstly,adoption of FaaS requires developers to employ a specificprogramming model where chosen functionalities interact inan event-driven fashion and comply with the requirementsof FaaS providers, e. g., limited execution time. Thus, partsof the original application’s architecture related to chosenfunctionalities need to be changed to comply with the newrequirements, which introduces implementation overhead onlyfor handling rare, exceptional workloads. Additionally, movingcertain functionalities to FaaS might not be feasible cost- andeffort-wise, e. g., moving tightly-coupled and stateful compo-nents introduces implementation and performance overhead.

Another important factor that increases the developmentcomplexity is the need to decide on application componentsgranularity upfront, which is a non-trivial challenge [8],[22]. For instance, several studies investigated challenges formigrating applications to microservice architectures [23] inindustry [24], [25] and the described big issues include decom-posing existing systems, identifying proper context boundaries,and finding the right component granularity. Moreover, usingfiner-grained components for every functionality increases thearchitecture’s complexity and introduces the communicationoverhead, e. g., microservice architectures typically have com-munication overhead compared to monoliths [26]. In complexsystems consisting of multiple fine-grained components, thecommunication overhead is even higher due to a larger numberof endpoints, which results in more intermediary hops needed.Likewise, applying the FaaS paradigm to every possible func-tionality or deciding on the right granularity upfront can beproblematic and might cause additional problems instead ofsolving existing ones. Therefore, the decision which function-alities can be moved to finer-grained service models needs tobe taken carefully as it may harm the system in the future.

Since choosing the right granularity for components upfrontand reengineering an entire application only to prepare a subsetof crucial functionalities for exceptional workloads requiresconsiderable efforts from development and operations, it isoften not feasible to tackle rare loads or failures. Therefore,the research question underlying this work is “How to supportdevelopers in preparing crucial application functionalities forhandling exceptional workloads by utilizing the FaaS cloudservice model, without the need to change the application’sarchitecture?”. Our goal is to keep the original application as-is for regular cases, while using FaaS only in exceptional cases.To keep the entry barrier for developers as low as possible andto minimize the development overhead, the proposed methodhas to provide automation support where it is possible.

purchase

OrderService

ShipmentService

PrintingService

…PrintInvoice PrintCatalogueprintInvoice

GeneratePDF

ProductService

Fig. 1. Excerpt of a system architecture with four components

C. Motivating Scenario

A simplified UML component diagram in Figure 1 demon-strates an excerpt of a system architecture consisting offour loosely-coupled components, namely OrderService, Ship-mentService, ProductService, and PrintingService that com-municate, e. g., via REST API calls. For the sake of brevity,we omit the details about the internal structure of all com-ponents except the PrintingService component, which groupstogether all printing-related functionalities such as PrintIn-voice, PrintCatalogue, and the internally-used GeneratePDFfunctionality. The PrintingService component is not statefuland does not require a resource layer for processing variousprinting-specific requests via respective exposed interfaces.Furthermore, since the PrintingService component comprisesinterdependent functionalities related only to printing domain,it is not further split into finer-grained, loosely-coupled com-ponents. For instance, to produce respective PDF documents,both PrintInvoice and PrintCatalogue functionalities depend onthe internal GeneratePDF functionality, which provides meansto generate PDF documents based on the given input.

In practice, this generic example can reflect a part of anapplication dealing with, e. g., processing orders in a webstore which has all components implemented, e. g., as Javaweb applications. As an example, the purchase operationcan be invoked via the interface called purchase providedby the OrderService component. This interface can be usedonly if the three remaining components are available and oneof the required interfaces, namely printInvoice, is providedby the PrintingService component. In case of an unexpectedfailure of the PrintingService component, e. g., sudden spike ofpurchase requests on Christmas, further processing becomesnot possible, leading to a full system failure. However, ifthe printInvoice interface, which depends on the PrintInvoiceand GeneratePDF functionalities, is available in an eventof failure, orders can still be processed. In the followingsections, we introduce a method for automatically preparingchosen functionalities, e. g., the functionality provided viathe printInvoice interface, for unexpected loads using theFaaS service model and without reengineering the originalapplication, which allows it to function as-is in regular cases.

D. Related Work

In this subsection, we elaborate on related work and discussits applicability to the discussed problem statement.

Khadka et al. [27] introduce serviciFi, a comprehensivemethod for migrating legacy code to SOA. This methodcomprises multiple phases, including (i) project initiation,(ii) identification of candidate services and their further spec-ification, (iii) a construction and testing phase, and (iv) adeployment, monitoring, and management phase. The overallmethod is assembled from multiple fragments of existing SOAdevelopment methods and combines numerous manual andautomated activities. While the phases of this method can serveas a good basis, the overall method focuses on a differentproblem and is too complex for applying it to our use case.Moreover, the presence of manual activities in phases, e. g., anextracted service might need to be refactored before the nextphase, makes it infeasible to apply this method for certainfunctionalities in rare cases.

Frey and Hasselbring [28] address the problem of migratingexisting software to the cloud. A model-based approach calledCloudMIG begins with extracting the model of an existingapplication, selecting the target provider’s model, i. e., a so-called Cloud Environment Model (CEM), and generating threeartifacts, namely a target architecture, a mapping model, and acloud environment’s constraints violation model. Afterwards,the generated artifacts can be adapted, evaluated, and used foractual transformation of the existing application for the cloud.This approach is not suitable for our needs due to several rea-sons: (i) the approach focuses on migrating the entire systemwithout the intention to keep the original application workingas-is, (ii) the transformation from the generated architecture tothe chosen cloud environment is not discussed, and, accordingto authors not planned to be implemented in the near future.

Kwon and Tilevich [10] introduce a collection of cloudrefactoring techniques which help to automate the processof moving centralized applications to the cloud. Two maincomponents underlying presented techniques are recommen-dation and refactoring engines. The former is responsible forproviding recommendations for suitability of functionalitiesusing dynamic and static code analysis techniques. The latterhelps to refactor functionalities, including extracting, wrappingthem, and adding fault-handling logic. This approach focuseson extracting the functionalities and reengineering the originalapplication’s code, which is not suitable for our use case.However, the recommendation strategies can serve as a basisfor our future work about functionality’s suitability.

Several works [29], [30] focus on FaaSification approachesfor different programming languages. The general processinvolves code analysis and decomposition into functional unitsand code that is not suitable for FaaS. Next, the functionalunits are translated into FaaS units followed by compila-tion and assembling of their dependencies. While providingsome insights about the FaaS-related code extraction, theseapproaches are not suitable due to the focus on migratingall application’s functions and modification of the original

exceptional path

OrderServiceShipmentService

PrintingService

…PrintInvoice PrintCatalogue

GeneratePDF

ProductService

<<proxy>>

regular pathprintInvoice

PrintInvoice Parachute

PrintInvoice

GeneratePDF

purchase

purchase

OrderService

ShipmentService

PrintingService

…PrintInvoice PrintCatalogueprintInvoice

GeneratePDF

ProductService

Fig. 2. The Serverless Parachutes method applied to the PrintInvoice functionality

project’s structure. For Java applications, the prototypical im-plementation has limitations, e. g., methods located in classesthat have inner classes cannot be extracted.

Perera and Perera [31] present TheArchitect, a tool forgenerating high-level, serverless and microservice-based archi-tectures. The tool’s input wizard collects system requirements,maps it to predefined models, generates a high-level architec-ture, and provides a visual representation of the result. Thisapproach is not suitable due to several reasons: (i) the tool’soutput is a high-level architecture with no real implementationbehind it, (ii) and analyzing and migrating chosen functional-ities of an existing system is not possible.

Asghar et al. [19] discuss suitability of serverless computingfor Disaster Management Information Systems (DMSI) basedon their specific load characteristics. During the high activityphase, when relief operations happen after the disaster, DMSIis overloaded with a huge number of requests, whereas duringthe low activity phase, DMSI is almost idle. Such loadcharacteristics make FaaS a good deployment target, since theQoS consistency will only be affected right in the beginningof the spike due to the so-called cold start [3] problem. Inaddition, this will allow saving time, which is required forinstantiation of virtual machines or pools of containers.

The strangler pattern [24], [32] describes how to grad-ually migrate the original application to a chosen, moderntarget platform, while keeping it functioning as-is without themigrated functionalities. Eventually, the gradual removal offunctionalities leads to application being migrated completely.Modifications of the original application makes implementa-tions of this pattern not suitable for our stated problem.

The term code mobility [33] is used to describe a capa-bility to dynamically modify bindings between the locationof code and the actual code snippet. There are two forms ofcode mobility, namely weak and strong mobility. The formeris concerned with moving the code between computationalenvironments without moving the execution state, whereas thelatter allows migrating both, the code and its execution state.In this paper, we focus on the problem of weak mobility, morespecifically, on how the chosen functionality can be shippedto a new service model in an asynchronous fashion.

Hendrickson et al. [34] present OpenLambda, an open-source serverless computing platform. The authors mentionthat annotations identifying web resource handlers in Python’sframeworks like Flask can be seen as a good starting point fordecomposing legacy applications for FaaS deployments.

Numerous works [35]–[38] describe applicability scenariosfor serverless computing, and FaaS in particular. The researchtargets various fields such as high-performance computing,artificial intelligence, or scientific workflows. While FaaS isa relatively new cloud service model, the described results ofapplying it to different problem domains are mainly positive.

III. THE SERVERLESS PARACHUTES METHOD

In this section, we describe the method for preparingimportant functionalities of existing applications to withstandrare or unexpected high loads caused by exceptional cases,without changing the architecture of the original application.

The serverless parachutes method’s main idea is to providedevelopers with an intuitive and automated way of preparingcrucial application functionalities for unexpected loads, with-out reengineering or redeveloping the original application aswell as without deciding on the component granularity up-front. In the serverless parachutes method, the chosen crucialfunctionalities of an application are duplicated to FaaS de-ployments, while keeping the original application functioningas-is. A generated proxy component, which is decoupled fromthe original application and is capable of conditional routing,then redirects requests to this FaaS-hosted functionalities onlyin exceptional, high workload cases.

Figure 2 depicts how the method can be applied to thefunctionality provided via the printInvoice interface from therunning example described in Section II-C. The generatedPrintInvoice Parachute is a FaaS-hosted function that combinesthe logic of PrintInvoice and GeneratePDF sub-componentsto make the functionality provided via the printInvoice in-terface available for exceptional cases. In the meantime, reg-ular cases are handled by the original Printing component,whose architecture remains unchanged. This approach avoids(i) reengineering the original application, i. e., the architectureof the Printing component in this example, only for exceptional

IdentifyFunctionality

optional step

Source Code Annotated Source Code

Parachute Descriptors

1

ParachuteDeployment

Bundle

Test & Refine

RefinedDeployment

Bundle

AnnotateFunctionality

2Extract

Parachutes

3

AutomaticallyDeploy

56Generate

Deployment Bundle

4

Manual step

Automated step

Fig. 3. A stepwise diagram of the serverless parachutes method

cases, and (ii) scaling the entire application, which leads tocost optimizations. We refer to the deployed FaaS functionalityas a serverless parachute emphasizing on the backup natureof the duplicated deployment.

Serverless parachutes enable an efficient, fine-grained scal-ing by utilizing the benefits of the FaaS cloud service modelfor handling exceptional workloads as described in Section II.A simple example of a suitable candidate for extraction asa serverless parachute is a stateless Java servlet with nointernal dependencies. To achieve such deployment duplica-tion, both the original and the newly-created FaaS versionof the functionality must conform to the original interfaceand be accessible by means of rerouting using a separateproxy component. The rerouting happens only if a certaincondition is fulfilled, e. g., when the number of requests isabove a certain threshold or when the original functionality iscurrently not available. The overall method of creating server-less parachutes consists of six steps, namely (i) identifyingsuitable functionalities, (ii) annotating them on the level of thesource code, (iii) extracting the required information about thefunctionality, (iv) generating parachute deployment bundlesfor the provider of choice, (v) refining and testing resultingdeployment bundles, and (vi) deploying them automatically.Figure 3 demonstrates this process including the descriptionsof inputs and outputs for each step. In the following, wedescribe every step in more detail.

A. Step 1: Identifying Suitable Functionalities

The first step of the method, as shown in Figure 3, is to iden-tify functionalities suitable for parachute deployments. Theproblem of finding suitable functionalities is not in the scopeof this work. However, we briefly discuss which functionalitiescan be potential candidates for parachute deployments. Inthe next steps, we assume that the functionality is alreadyidentified and available for further processing.

Clearly, not all functionalities are suitable for migration tocloud [10]. The most suitable functionalities for a parachutedeployment have several common characteristics, which cor-relate with the properties of the FaaS service model. More

specifically, they are: (i) independent or easy to decouple, i. e.,proper bounded contexts, (ii) stateless, and, (iii) preferably,finer-grained components, e. g., having small amount of dis-tinct functionalities. A good example is a stateless Java servletthat handles requests and has no internal dependencies.

On the other hand, functionalities not suitable for parachut-ing, for example, (i) cannot be decoupled without introducingadditional components, e. g., duplicate the used storage, or(ii) are too expensive to decouple due to critical dependencieson the source application. One example of less-suitable func-tionality is related to code snippets, which, when decoupled,still depend on the main application, e. g., the try-catch blocksfor fault handling. Extracting such code snippets and deployingthem to FaaS for handling main application’s faults wouldrequire integration with the main application, which makesconditional FaaS routing in exceptional cases not feasible:the source application must be available and, moreover, willbecome a scaling bottleneck. In general, such tightly-coupledexamples require additional reengineering and maintainingefforts, which neglects the advantages of generating parachutesfor such functionalities.

B. Step 2: Annotate Functionalities

The second step of the method, as depicted in Figure 3,is responsible for enriching identified functionalities withadditional meta-data by means of source code annotations.Various additional information can be specified for definingthe parachutes behavior, e. g., desired routing conditions. Al-though the conceptual model of annotations is uniform, theactual implementations are language-specific. Depending onthe programming language, annotations can be implementeddifferently, e. g., using Java annotations, C# attributes, orstandardized commentary-based annotations. An example ofsuch parachute annotations in Java is shown in Listing 1. TheParachuteMethod annotation marks the serverless parachutefunctionality. Routing condition properties describe at whichpoint requests have to be rerouted to the parachute, e. g., whenthe main path is not available, at a specific date or certainavailability threshold. Of course, this is extensible as various

Listing 1. Example usage of parachute annotations in Java

@ParachuteMethod(failover = true,overUtilizationFactor = "80%",routeOnDate = "20191224", ...)public Response handler(Request data) {...}

routing conditions are possible and not limited to the discussedones. Moreover, depending on the desired level of controlduring the next steps, annotations might contain more specificdirectives, e. g., mapping rules for input and output parametersin typed programming languages or a custom endpoint namefor a parachute deployment.

C. Step 3: Extract Functionalities

Step 3 shown in Figure 3 is responsible for extractingthe annotated functionalities into self-contained parachutedescriptors. Note that the parachute descriptor is still provider-agnostic as it only contains the function’s source code withrelated data such as class or method dependencies, buildscripts, or annotations specified for the next steps. For ex-ample, a plain Java function typically cannot be deployeddirectly to a provider of choice and requires additional post-processing, e. g., AWS Lambda has specific requirementsfor authoring Java functions. Parachute descriptors can bereused for generating serverless parachutes for other supportedproviders. The parachute annotations, e. g., proxy configura-tion directives, are not retained in the extracted functionality,but stored separately in the descriptor. The extraction processis language-specific, hence corresponding extraction pluginsare needed to support different programming languages. Forexample, extraction logic varies due to differences in typesupport, e. g., strong and weak typing, or the use of differentbuild tools. During extraction, various information is capturedin the descriptor, including: (i) endpoint path, (ii) input andoutput types, also, if needed, with the corresponding typedefinitions, (iii) class, method, and variable dependencies, and(iv) library dependencies, e. g., a naıve superset of the buildscript dependencies. The resulting descriptor is self-containedand allows generating provider-specific FaaS deploymentswithout performing the extraction step again.

D. Step 4: Generate Serverless Parachutes

Step 4 shown in Figure 3 is responsible for generatingparachute deployment bundles that contain extracted function-alities in provider-specific format, e. g., AWS Lambda deploy-ment packages, together with the corresponding deploymentmodels, e. g., modeled by means of AWS CloudFormationtemplates or using TOSCA [39]–[41] cloud modeling lan-guage. In this step, previously created parachute descriptorsserve as input for generating the packaging format of a chosenprovider. To generate a provider-specific format from thedescriptor, the extracted method and its dependencies needto be adapted, e. g., creating correct packages and classes,adding specific import statements, changing method signaturesas required by the provider. Moreover, the build script mightneed to be enriched with provider-specific dependencies. In

Deployment Orchestration Engines

Extraction Manager

Business Logic Layer

Resource Layer

REST API

Presentation Layer

Web UI...

Generation ManagerDeployment Manager

Language Annotation Libraries

Plu

gin

s

Artifacts Repository

Fig. 4. The architecture of the serverless parachutes framework

cases where compilation is required, it needs to be trig-gered, e. g., to provide an AWS-deployable JAR. Resultingartifacts become a part of a generated deployment modelfor automating the parachutes deployment. For example, anAWS Serverless Application Model (SAM) template can begenerated to automatically deploy all generated AWS Lambdafunctions. The parachute deployment bundle also includes thegenerated proxy configuration files and corresponding deploy-ment models to automate the creation of the proxy component.Conditional routing is configured based on the annotationsprovided in the second step by mapping them to supportedunderlying router types such as Nginx, Envoy, or customrouters, e. g., relying on Envoy’s extensibility mechanisms.

E. Steps 5&6: Test, Refine, and Deploy

In Step 5 and Step 6 shown in Figure 3, the generatedartifacts can be first tested and refined and then automaticallydeployed. To avoid repetition, deployment automation is usedto simplify the deployment of all generated artifacts, e. g., anAWS Cloud Formation template for proxies and an AWS SAMtemplate for all generated serverless parachutes. If needed, thedeployment model also includes required provider’s services,e. g., configuration of an API Gateway to expose AWS Lambdafunctions. In some cases, the generated deployment modelmight require refinements such as modifying the API specifi-cation, changing the application’s entry point, or reconfiguringexisting proxies instead of using newly-generated ones. Whilethere are various ways to test the deployment, includingautomated solutions [42], in this paper we do not focuson the deployment testing. Afterwards, the refined parachutedeployment bundles can be automatically deployed using asupported deployment orchestration engine.

F. Framework Architecture

An extensible, plugin-based system architecture of theparachutes framework is depicted in Figure 4. The presentationlayer enables user interaction by means of an REST API and/ora Web UI. The business logic layer comprises four major

components implementing and orchestrating the introducedmethod steps while supporting the extensibility through thecorresponding plugins. Language Annotation Libraries areprovided to developers for annotating the crucial functionali-ties in application’s source code as described in Section III-B.The Extraction Manager uses language-specific extractionplugins for analyzing the source code and extracting parachutedescriptors as discussed in Section III-C. For generatingparachute deployment bundles, as discussed in Section III-D,the Generation Manager component utilizes required provider-specific generation plugins, e.g., for AWS Lambda or Mi-crosoft Azure Functions. Finally, the Deployment Manager isresponsible for handling the automatic deployment of refinedparachute bundles as discussed in Section III-E by utilizingrespective deployment orchestration engines.

The resource layer consists of a set of supported De-ployment Orchestration Engines, e. g., Terraform or AWSCloud Formation, used by the Deployment Manager and anArtifact Repository which allows storing the artifacts producedby the method for future reuse, e. g., to generate parachutedeployment bundles for multiple providers.

IV. PROTOTYPICAL VALIDATION

As a proof of technical feasibility, we prototypically imple-mented the framework architecture described in Section III-Fusing Java [43]. Therefore, the prototype provides an imple-mentation of the three manager components, i. e., Extraction,Deployment and Generation Manager, to conduct and auto-mate the different steps of the parachute method presentedin Section III. Furthermore, a language annotation library andan Extraction Manager plugin for applying our method toJava applications, as well as corresponding Generation andDeployment Manager plugins for AWS cloud provider areimplemented. The prototype exposes its functionality over aREST API which is implemented using Jersey, an implemen-tation of the JAX-RS specification. An OpenAPI specificationof the implemented REST API is generated using respectiveSwagger tools, and a web-based visualization is accessiblethrough the prototype’s interface.

To enable the application of our parachute method, devel-opers need to import the provided Java language annotationlibrary into their Java project for annotating desired function-alities. Afterwards, the prototype can be used for extractingparachutes from the annotated source code. Thus, a developerneeds to provide a link to the repository containing the sourcecode, which in our prototype’s case is done through providinga GitHub URL. The respective extraction plugin clones therepository and analyzes the source code. All found parachutefunctionalities are extracted together with their dependenciesand meta-data. More specifically, all class and method depen-dencies including the input and output types, inner classesand methods are extracted together with the functionalityand stored in a parachute descriptor file. Furthermore, thebuild scripts are extracted and included in the descriptor too.The resulting parachute descriptor is serialized using a JSONformat which is then used as an input by the respective AWS

generation plugin. Java functions for AWS Lambda must con-form to certain requirements, e. g., implement RequestHandlerinterface, which requires importing specific AWS packagesand modifying the build script’s dependencies, e. g., a Mavenpom file’s dependency list. The AWS generation plugin createsAWS Lambda packages for every extracted parachute bycreating a package with all related classes and build scripts,and running the build. Afterwards, an AWS Serverless Ap-plication Model (SAM) template is generated for automateddeployment of all generated AWS Lambdas. In addition, anAWS Cloud Formation Template is generated for creating aproxy component together with custom configurations basedon the provided annotations. As an example of a routingcondition, we use serverless parachutes as failover routes whenthe main application is not available. To implement this routingcapability, we use Nginx web server and its configurationof backup routes. Resulting templates are ready for testing,refining, and deployment. We use a file system as an artifactrepository for reusing created artifacts within the prototype,i. e., parachute descriptors and deployment bundles.

V. EVALUATION

In this section, we describe the evaluation of our approach.First, we present the underlying evaluation methodology ap-plied, followed by a description of the experimental setup, and,finally, a discussion of the evaluation results.

A. Evaluation Methodology and Experimental Setup

The focus of the evaluation is to empirically analyze theperformance variation when introducing serverless parachutescompared to the original application deployment. Based onthe running example described in Section II-C, for evaluationwe use a functionality that generates an invoice in PDFformat by taking a JSON object containing the order dataas an input. This functionality is implemented as part ofan example Java web application1 and is exposed via aREST API. The goal of evaluation is to identify the overheadintroduced by adding a custom proxy component, and analyzethe exceptional path activation time in cases when the originalfunctionality becomes unavailable and the parachute takes overthe processing responsibility. To achieve this, we measurevariations in response times, which are perceived by a usercalling a function based on the six scenarios discussed below.

In an application-plain scenario, the function is provided aspart of the example Java web application that is deployed to anApache Tomcat version 8.5 to serve incoming requests throughits REST API, without applying the serverless parachutesmethod. In the second scenario called application-proxy, aproxy in the form of an Nginx server with a simple reverseproxy configuration is introduced to measure the response timefor the plain example application if requests are routed througha reverse proxy, but without applying the serverless parachutesmethod. The third scenario, application-failover-proxy, mea-sures the response time for the plain example application

1https://github.com/v-yussupov/parachutesmethod-exampleapp

Load Driver

Application

Parachute

Proxy

scenario (1)

scenario (4)

scenarios (2) & (3)

scenario (5)

API Gateway

Fig. 5. Experimental setup and evaluation scenarios in AWS infrastructure,using EC2 and Lambda services

accessed via the custom proxy introduced by our method(cf. Section III-D), which is configured to support exceptionalcases rerouting for the serverless parachutes method basedon an Nginx server. The required custom proxy configurationis generated as a part of the parachute deployment bundle.In the fourth scenario called parachute-plain, the responsetimes are measured for the direct communication with thefunctionality extracted and deployed as a serverless parachute.The extraction, generation, and deployment to AWS Lambdaare performed using the prototype, with manual refinement ofthe endpoints information and API Gateway requests mapping.In the fifth scenario, parachute-failover-proxy, we measure theresponse time for the parachute via the introduced customproxy configured to support rerouting to serverless parachutes.

In the sixth scenario, exceptional-path-activation, we eval-uate the times needed to switch from the regular path to ex-ceptional path and vice versa in cases when the application isnot available. In this scenario, we measure the response timesduring the following steps: (i) the functionality is accessedvia the regular path (cf. application-failover-proxy scenario),(ii) after four minutes, the failover is triggered by stoppingthe Tomcat to route incoming requests to the parachute (cf.parachute-failover-proxy scenario), (iii) after additional fourminutes, the Tomcat is started again to restore the regularpath. The response times are analyzed to identify the averageactivation time needed for parachutes to take over. In addition,we analyze the average deactivation time needed to return tothe regular path when the application becomes available again.

The experimental environment is set up in the AWS cloudand comprises three AWS EC2 t2.micro (1 vCPU, 1 Gb RAM)instances and one AWS Lambda instance (512 Mb memory)exposed by means of the AWS API Gateway. EC2 instanceshost: (i) Apache JMeter2 as a load driver, (ii) Nginx as a proxy(either a reverse proxy or a failover proxy configuration),and (iii) example Java web application deployed to ApacheTomcat. Figure 5 depicts the experimental setup and communi-cation paths for these five scenarios using a set of official AWS

2Apache JMeter: http://jmeter.apache.org/

28,83 29,33 29,17 29,17 29,00

29,83 29,50 29,67 29,50 30,00

0

4

8

12

16

20

24

28

32

1 2 3 4 5

Avg

. Re

spo

nse

Tim

e (

in m

s)

# Load Bursts

application-plain

application-proxy

application-failover-proxy

parachute-plain

parachute-failover-proxy

Fig. 6. Average response time in milliseconds (ms) for the load bursts of allscenarios.

Architecture Icons3. For each of the six scenarios, a workloadconsisting of random 2KB JSON HTTP requests is generated.The workload is distributed among a warm-up phase (w) with2000 requests followed by an experimental phase comprisinga set of 31000 requests sent in five load bursts (i) for eachuser according to the following function:

m(i) = w +

5∑i=1

2i−1 · 1000 | w = 2000

Where m(i) reflects the total number of requests send untilthe i-th load burst with an increase of requests to the powerof two across the load burst.

For the failover scenario requests are sent constantly by fiveconcurrent users without any load bursts after the warmup-phase to measure the failover time when the function at theTomcat becomes unavailable and Nginx redirects all incomingrequests to the parachute deployed at AWS Lambda.

To conduct the workload for each of the defined evaluationscenarios, we use Apache JMeter version 5.1.1. We createda JMeter test plan for each of the introduced six scenarioswhich concurrently sends the above defined workload for fiveconcurrent users to the endpoint of the function. To alleviatethe effect of outliers in the experimental results, we executesix rounds of each scenario and calculate the average responsetime for each load burst. All JMeter test plans and evaluationresults are available online4.

B. Experimental Results

Figure 6 demonstrates the evaluation results for the first fivescenarios. The total amount of requests sent when evaluatingsix described scenarios is around 5.9 million requests. For theapplication-plain scenario the response time is approximately7ms, while the average response time for a direct AWSLambda communication in the parachute-plain scenario isapproximately 19ms. The increase in response time of approx-imately 12ms for the parachute-plain scenario might be due

3https://aws.amazon.com/architecture/icons4https://github.com/v-yussupov/parachutesmethod-evaluation

to the fact that the AWS Lambda is invoked via the AWS APIGateway, which needs to, e. g., map requests and responses orconvert the response into a binary format. When introducingthe failover proxy in the parachute-failover-proxy scenario, theresponse time slightly increases to approximately 21ms. Thisshows that introducing a failover proxy before a parachutedoes only result in an overhead of approximately 3ms. Almostidentical average response times with approximately 30ms arecaptured for the application-proxy and application-failover-proxy scenarios. The difference between communication withthe application directly or via the proxy is consistent acrossall bursts and is approximately 23ms.

For the sixth scenario, we evaluated the exceptional path’sactivation and deactivation time. The average time required foractivating the exceptional path is approximately 3.3 seconds,which is strongly influenced by the cold start problem [3], i. e.,the initialization time required for spinning up the first instanceof a function. Within our experiments, it took only 4-5 requestsuntil the response time from the activated parachute reducedsignificantly towards the average response times measured inthe other five scenarios. On the opposite, the deactivationtime, i. e., switching back from the parachute to the originalapplication, was in average 380ms. Furthermore, the failoverperformance remained constant over all executed six evalua-tion rounds, making our parachute method applicable to eventsof high and unexpected loads.

In general, the evaluation results indicate that adding thefailover proxy component, which reroutes traffic between theapplication and AWS Lambda function, introduces an over-head that has to be considered when applying the serverlessparachutes method. Therefore, in future work we plan tooptimize our method to decrease the performance overheadas well as conduct an extended evaluation where we measurethe influence of different types of extracted functions, varyingrequest sizes, proxy configurations, and other cloud providers.

VI. CONCLUSION AND FUTURE WORK

In this work we presented a method for preparing cho-sen functionalities of existing or developed applications towithstand unexpected loads caused by exceptional cases. Ourmethod leverages the advantages of the FaaS cloud servicemodel by generating and automatically deploying FaaS ver-sions of the chosen functionalities, while keeping the archi-tecture of the original application untouched and adaptingthe overall system architecture with generated and configuredproxy components. Chosen functionalities are annotated onthe level of source code and then automatically extracted intoparachute descriptors, which are used to generate deployableparachutes for chosen cloud service providers. As a proof ofconcept, we implemented a prototype supporting automatic ex-traction, generation, and deployment of serverless parachutesfor Java projects and AWS cloud provider. Furthermore, weevaluated our method by conducting a set of experiments andestimating the overhead introduced by the generated proxycomponents and measuring the exceptional path activation/de-activation times. The overhead for a generated proxy compo-

nent shown in our preliminary evaluation results need to betaken into consideration. The extracted parachutes demonstratea stable response time and nearly 100% success rate whenthe original application becomes unavailable. The evaluationresults demonstrate that our method is applicable as a backupstrategy for cases when unexpected, high loads target crucialapplication functionalities.

Apart from using it as a backup strategy, the serverlessparachutes method can be used in alternative applicationscenarios. One obvious example is an intermediate step beforestrangulating the functionality, e. g., blue-green or canarydeployments. In case a FaaS deployment of the functional-ity is eventually favored over the original functionality, themethod can be extended with additional steps, e. g., analyzethe dependencies and strip off the annotated functionality.Interestingly, the method can be applied to both, existing andnewly-developed applications. Another application scenario isa simplification of a loosely-coupled architecture developmentfollowing a monolith-first approach [44]. Here, the to-be-moved functionalities can be annotated and tested in parachutedeployments without affecting the monolith’s development.

In future work, we plan to perform an extended evalua-tion, which will include different payload sizes, programminglanguages, cloud providers, and proxy settings. We intend tofurther optimize the proxy generation and configuration aswell as to introduce support for different proxy types, e. g.,using the extensibility features of Envoy. Furthermore, we planto enrich our prototype with additional plugins for extractionand generation steps to support other programming languagesand cloud providers, including open source FaaS platformsas well as to extend the supported annotation types and toinvestigate other ways of applying our method, e. g., using theideas of Aspect-Oriented Programming [45]. One optimiza-tion strategy that we intend to explore is reconfiguration ofexisting components in the application’s deployment insteadof introducing new proxies, e. g., application load balancerscan be reconfigured to avoid additional overhead.

In addition, there are several interesting research ques-tions, which can help extending and enhancing the parachutesmethod. Firstly, we plan to investigate how the parachutesmethod can be extended to support strong code mobility [33],and, in particular, remote cloning mechanism. With remotecloning, the chosen functionality can be dynamically extractedfrom the source application at runtime, i. e., the applicationis dynamically adapted to scale only its certain parts. An-other question is to provide developers with the guidelinesand recommendations on which functionalities are suitablefor parachuting them, e. g., by means of profiling functionsusing metrics like the number of dependencies or presence ofdatabase operations in the code.

ACKNOWLEDGMENT

This work is partially funded by the European Union’s Hori-zon 2020 research and innovation project RADON (825040).We would also like to thank the three anonymous reviewers,whose insightful feedback helped to improve this paper.

REFERENCES

[1] P. M. Mell and T. Grance, “Sp 800-145. the NIST definition of cloudcomputing,” Gaithersburg, MD, United States, Tech. Rep., 2011.

[2] Y. Izrailevsky and C. Bell, “Cloud reliability,” IEEE Cloud Computing,vol. 5, no. 3, pp. 39–44, 2018.

[3] I. Baldini, P. Castro, K. Chang, P. Cheng, S. Fink, V. Ishakian,N. Mitchell, V. Muthusamy, R. Rabbah, A. Slominski et al., “Serverlesscomputing: Current trends and open problems,” in Research Advancesin Cloud Computing. Springer, 2017, pp. 1–20.

[4] Cloud Native Computing Foundation (CNCF). (2018, September)CNCF Serverless Whitepaper v1.0. [Online]. Available: https://github.com/cncf/wg-serverless/tree/master/whitepapers/serverless-overview

[5] A. Eivy, “Be wary of the economics of” serverless” cloud computing,”IEEE Cloud Computing, vol. 4, no. 2, pp. 6–12, 2017.

[6] Amazon Web Services, Inc. (2019, February) AWS Lambda. [Online].Available: https://aws.amazon.com/lambda

[7] Microsoft. (2019, February) Microsoft Azure Functions. [Online].Available: https://azure.microsoft.com/en-us/services/functions

[8] N. Kulkarni and V. Dwivedi, “The role of service granularity in asuccessful soa realization a case study,” in Services-Part I, 2008. IEEECongress on. IEEE, 2008, pp. 423–430.

[9] O. Mustafa and J. M. Gomez, “Optimizing economics of microservicesby planning for granularity level,” Experience Report, 2017.

[10] Y.-W. Kwon and E. Tilevich, “Cloud refactoring: automated transitioningto cloud-based services,” Automated Software Engineering, vol. 21,no. 3, pp. 345–372, 2014.

[11] W. Ye, A. I. Khan, and E. A. Kendall, “Distributed network filestorage for a serverless (p2p) network,” in The 11th IEEE InternationalConference on Networks, 2003. ICON2003. IEEE, 2003, pp. 343–347.

[12] C. C. Tan, B. Sheng, and Q. Li, “Secure and serverless rfid authenticationand search protocols,” IEEE Transactions on Wireless Communications,vol. 7, no. 4, pp. 1400–1407, 2008.

[13] G. C. Fox, V. Ishakian, V. Muthusamy, and A. Slominski, “Status ofserverless computing and function-as-a-service (faas) in industry andresearch,” arXiv preprint arXiv:1708.08028, 2017.

[14] J. M. Hellerstein, J. Faleiro, J. E. Gonzalez, J. Schleier-Smith,V. Sreekanti, A. Tumanov, and C. Wu, “Serverless computing: One stepforward, two steps back,” arXiv preprint arXiv:1812.03651, 2018.

[15] W. Lloyd, S. Ramesh, S. Chinthalapati, L. Ly, and S. Pallickara,“Serverless computing: An investigation of factors influencing microser-vice performance,” in 2018 IEEE International Conference on CloudEngineering (IC2E). IEEE, 2018, pp. 159–169.

[16] R. N. Charette, “Why software fails [software failure],” Ieee Spectrum,vol. 42, no. 9, pp. 42–49, 2005.

[17] P. Garraghan, R. Yang, Z. Wen, A. Romanovsky, J. Xu, R. Buyya, andR. Ranjan, “Emergent failures: Rethinking cloud reliability at scale,”IEEE Cloud Computing, vol. 5, no. 5, pp. 12–21, 2018.

[18] B. Maurer, “Fail at scale,” Queue, vol. 13, no. 8, p. 30, 2015.[19] T. Asghar, S. Rasool, M. Iqbal, Z. ul Qayyum, A. N. Mian, and

G. Ubakanma, “Feasibility of serverless cloud services for disastermanagement information systems,” in 2018 IEEE 20th InternationalConference on High Performance Computing and Communications;IEEE 16th International Conference on Smart City; IEEE 4th Interna-tional Conference on Data Science and Systems (HPCC/SmartCity/DSS).IEEE, 2018, pp. 1054–1057.

[20] T. Guo, U. Sharma, P. Shenoy, T. Wood, and S. Sahu, “Cost-aware cloudbursting for enterprise applications,” ACM Transactions on InternetTechnology (TOIT), vol. 13, no. 3, p. 10, 2014.

[21] K. Coleman, F. Esposito, and R. Charney, “Speeding up children reuni-fication in disaster scenarios via serverless computing,” in Proceedingsof the 2nd International Workshop on Serverless Computing. ACM,2017, pp. 5–5.

[22] O. Mustafa, J. M. Gomez, M. Hamed, and H. Pargmann, “Granmicro:A black-box based approach for optimizing microservices based appli-cations,” in From Science to Society. Springer, 2018, pp. 283–294.

[23] S. Newman, Building microservices: designing fine-grained systems. ”O’Reilly Media, Inc.”, 2015.

[24] D. Taibi, V. Lenarduzzi, and C. Pahl, “Processes, motivations, and issuesfor migrating to microservices architectures: an empirical investigation,”IEEE Cloud Computing, no. 5, pp. 22–32, 2017.

[25] P. Di Francesco, P. Lago, and I. Malavolta, “Migrating towards microser-vice architectures: an industrial survey,” in 2018 IEEE InternationalConference on Software Architecture (ICSA). IEEE, 2018.

[26] M. Villamizar, O. Garces, H. Castro, M. Verano, L. Salamanca, R. Casal-las, and S. Gil, “Evaluating the monolithic and the microservice archi-tecture pattern to deploy web applications in the cloud,” in ComputingColombian Conference (10CCC), 2015 10th. IEEE, 2015, pp. 583–590.

[27] R. Khadka, G. Reijnders, A. Saeidi, S. Jansen, and J. Hage, “A methodengineering based legacy to soa migration method,” in 2011 27th IEEEInternational Conference on Software Maintenance (ICSM). IEEE,2011, pp. 163–172.

[28] S. Frey and W. Hasselbring, “The cloudmig approach: Model-basedmigration of software systems to cloud-optimized applications,” Interna-tional Journal on Advances in Software, vol. 4, no. 3 and 4, pp. 342–353,2011.

[29] J. Spillner, “Transformation of python applications into function-as-a-service deployments,” arXiv preprint arXiv:1705.08169, 2017.

[30] J. Spillner and S. Dorodko, “Java code analysis and transformation intoaws lambda functions,” arXiv preprint arXiv:1702.05510, 2017.

[31] K. J. P. G. Perera and I. Perera, “Thearchitect: A serverless-microservices based high-level architecture generation tool,” in 2018IEEE/ACIS 17th International Conference on Computer and InformationScience (ICIS), June 2018, pp. 204–210.

[32] M. Fowler. (2004, June) StranglerApplication. [Online]. Available:https://www.martinfowler.com/bliki/StranglerApplication.html

[33] A. Fuggetta, G. P. Picco, and G. Vigna, “Understanding code mobility,”IEEE Transactions on software engineering, vol. 24, no. 5, pp. 342–361,1998.

[34] S. Hendrickson, S. Sturdevant, T. Harter, V. Venkataramani, A. C.Arpaci-Dusseau, and R. H. Arpaci-Dusseau, “Serverless computationwith openlambda,” Elastic, vol. 60, p. 80, 2016.

[35] X. Geng, O. Ma, Y. Pei, Z. Xu, W. Zeng, and J. Zou, “Research onearly warning system of power network overloading under serverlessarchitecture,” in 2018 2nd IEEE Conference on Energy Internet andEnergy System Integration (EI2). IEEE, 2018, pp. 1–6.

[36] L. Baresi, D. F. Mendonca, and M. Garriga, “Empowering low-latencyapplications through a serverless edge computing architecture,” in Euro-pean Conference on Service-Oriented and Cloud Computing. Springer,2017, pp. 196–210.

[37] M. Malawski, A. Gajek, A. Zima, B. Balis, and K. Figiela, “Serverlessexecution of scientific workflows: Experiments with hyperflow, awslambda and google cloud functions,” Future Generation ComputerSystems, 2017.

[38] P. Dziurzanski, J. Swan, and L. Soares Indrusiak, “Value-based manufac-turing optimisation in serverless clouds for industry 4.0,” in Proceedingsof the Genetic and Evolutionary Computation Conference. York, 2018.

[39] U. Breitenbucher et al., “Combining declarative and imperative cloudapplication provisioning based on tosca,” in Proceedings of the IEEEInternational Conference on Cloud Engineering (IEEE IC2E 2014).IEEE Computer Society, March 2014, pp. 87–96.

[40] M. Wurster, U. Breitenbucher, K. Kepes, F. Leymann, and V. Yussupov,“Modeling and Automated Deployment of Serverless Applications usingTOSCA,” in Proceedings of the IEEE 11th International Conference onService-Oriented Computing and Applications (SOCA). IEEE ComputerSociety, 2018, pp. 73—80.

[41] V. Yussupov, M. Falkenthal, O. Kopp, F. Leymann, and M. Zim-mermann, “Secure Collaborative Development of Cloud ApplicationDeployment Models,” in Proceedings of The 12th International Con-ference on Emerging Security Information, Systems and Technologies(SECURWARE 2018). Xpert Publishing Services, 2018, pp. 48–57.

[42] M. Wurster, U. Breitenbucher, O. Kopp, and F. Leymann, “Modeling andAutomated Execution of Application Deployment Tests,” in Proceedingsof the IEEE 22nd International Enterprise Distributed Object ComputingConference (EDOC). IEEE Computer Society, 2018, pp. 171–180.

[43] (2019, May) Prototypical implementation of the ServerlessParachutes Framework. [Online]. Available: https://github.com/v-yussupov/parachutesmethod-framework/releases/tag/v0.1.0

[44] M. Fowler. (2015, June) StranglerApplication. [Online]. Available:https://www.martinfowler.com/bliki/MonolithFirst.html

[45] G. Kiczales and M. Mezini, “Aspect-oriented programming and modularreasoning,” in Proceedings. 27th International Conference on SoftwareEngineering, 2005. ICSE 2005. IEEE, 2005, pp. 49–58.