A Migration-Based Approach to Execute Long-Duration Multi- Cloud Serverless Functions Boubaker Soltani Afifa Ghenai Nadia Zeghib LIRE Laboratory Constantine2 – Abdelhamid Mehri University, Constantine, Algeria {boubaker.soltani, afifa.ghenai, nadia.zeghib} @univ-constantine2.dz approach use is illustrated by a case study: a generic machine learning application built Abstract over the scientific platform ANTDROID. Serverless Computing is emerging as an undeniable paradigm for the deployment of 1. Introduction (multi)cloud applications. It is mainly Cloud computing is now commonly used to describe characterized by the use of stateless loosely- the delivery of software, infrastructure and storage coupled functions that are composed together services over the internet. In this field, there are to perform useful actions. This approach, generally two parts that may be made available under contrarily to monolithic one, makes easier the the client control: the application code and the maintenance and the evolution of the underlying infrastructure hosting that application. In applications, since the functions can be this context, Serverless computing provides a great independently revised and reprogrammed. opportunity for developers seeking relief from the However, one principle in Serverless burden of infrastructure. This computing model computing is that function execution should allows building and running applications and services be within a short duration (five minutes max without having to manage infrastructure. In fact, in most Cloud provider platforms), after Serverless Computing is an event-driven approach which the function is abruptly terminated that abstracts the infrastructure management away even if it has not completed its task. from the client. Aspects like scalability, provisioning Moreover, the max duration cannot be and fault tolerance are automatically handled by a extended without a negative effect on the Serverless platform, while the Cloud user focuses platform performance. This leads to prevent only on his functional code [Bald17]. This code functions requiring longer time from being comes in the form of a set of stateless functions that adopted as Serverless functions. This paper are agnostic of where are they going to be executed deals with this drawback. It proposes a [Bald17]. Serverless platforms adopt a pay-per- distributed migration-based approach which execution billing strategy, i.e., contrarily to traditional promotes the execution of long-duration Cloud platforms that host the client program in a Serverless functions: each running function listening running server (hence, the client pays as that reaches the maximum duration limit is long as the server is running even if there are no repeatedly transferred to another cloud requests), a Serverless platform does not start a server platform where it is carried on. In this aim, until a request is made. In this way, the client is billed the migration-based system architecture, the for each invocation, meaning that no payment if no migration technique and the migration requests [Kuh17]. The Serverless architecture is algorithm are described. The proposed relatively a new paradigm and only few pioneers have Copyright © by the paper’s authors. Copying permitted only for private and academic purposes. In: Proceedings of the 3rd Edition of the International Conference on Advanced Aspects of Software Engineering (ICAASE18), Constantine, Algeria, 1,2-December-2018, published at http://ceur-ws.org Page 42 A Migration-Based Approach to Execute Long-Duration Multi- Cloud Serverless Functions ICAASE'2018 investigated this domain. Amazon AWS Lambda is a [Groz14]. This distribution and independence allows compute service that supports many languages like us to apply our repeated migration-based approach to node.js, C#, Python and Java on AWS infrastructure. cope with the aforementioned problem. Source code is provided as ZIP file and deployed in a The remainder of this paper is organized as follows: container that is allocated the necessary hardware Section 2 discuses some works based on monolithic resources. The combination of code, configuration application decomposition that are relevant to our and dependencies is what is called a Lambda function work. Section 3 is dedicated to the presentation of our [Sbar17]. The author admits that a Lambda function migration-based system architecture. Section 4 can only run for a maximum of five minutes. Azure illustrates our proposal via a case study. Finally, Functions [Kum17] is Microsoft’s version of a Section 5 concludes the paper with ongoing work. Serverless platform. They provide a technique named the consumption plan to enhance function scalability 2. Related Work during execution [Azr18]. A function in such plan is limited (by default) to five minutes, but this value can The investigated literature is classified switch to two be increased up to ten minutes [Azr18]. Google Cloud categories: works that focused on well-designing Functions [Stig18] is another promising Serverless functions at design time, i.e., from the beginning, be platform which limits the function to nine minutes careful to program functions that do not surpass the max [Goo18]. Moreover, according to [Fox17], maximum limit; and works that focused on Serverless platforms are still hosting short- running decomposing pre-existing monolithic applications to functions due to the faced difficulty of scheduling smaller independent functions. long-running tasks and their SLA (service level agreements) management, but the authors advocate 2.1. Design-Time Function Creation that it is possible in the future that Serverless In [Ader17], set of requirements assisting the platforms will host such tasks. Current procedure to development of microservices benchmark application execute long-duration workloads is not to provision for repeated empirical research in software them as Serverless functions (e.g. as a listening server architectures was provided [Ader17]. The e- instead) [Fox17] [Sbar17]. commerce European software Otto is planned to be Consequently, in current Serverless platforms, the rebuilt from scratch switch to a microservice concept function execution should be within a short duration of Verticals (isolated parts from each other, no shared (five minutes max in most Cloud provider platforms), states or infrastructures) [Hass17]. Sascha et al. after which the function is abruptly terminated even if [Alpr15] propose a microservice-based architecture it has not completed its task. This leads to prevent for business process modeling. An application in their functions requiring longer time from being adopted as model is decomposed to resources and entities, where Serverless functions. a service is dedicated for each resource. Authors of In the aim to overcome this drawback, we take [Tarm17] are tackling the limit of the traditional advantage from Multi-cloud paradigm features and method for analyzing and designing microservice propose a distributed migration-based approach architectures by proposing a new one based on which promotes the execution of long-duration holistic analysis and design (from identifying the Serverless functions. organizational identity and objectives to modeling the The Multi-Cloud paradigm allows considering the microservice dependency graph) [Tarm17]. distribution and provider-independence aspects. In Containerized microservice [Venu17] is a typical fact, Multi Cloud [Groz14] is the usage of multiple, combination nowadays, due to the promising independent clouds by a client or a service. This container technology solutions like Docker. paradigm is dedicated to accomplish the task of Nevertheless, authors notice lack of performance scheduling workloads to resources deployed across consideration in microservice building and identify multiple clouds. A Multi-cloud is, however, not the open issues and research guidelines. The Table 1 same as Cloud federation which refers to a set of summaries the main advantages and limits of the cloud providers that intentionally interconnect their design–time function creation approaches. infrastructures to make a unified resource pool International Conference on Advanced Aspects of Software Engineering Page 43 ICAASE, December, 01-02, 2018 A Migration-Based Approach to Execute Long-Duration Multi- Cloud Serverless Functions ICAASE'2018 Table 1: Design-Time Function Creation Approaches Summary Papers Application domain Advantages Limits [Ader17] Software empirical research Evaluative Requirements Function execution time is [Hass17] E-commerce apps Scalability and agility once fixed in design-time. So, (in/de)creasing the max limit [Alpr15] Business process modeling Flexibility and agility requires redesigning the [Tarm17] Holistic analysis/design More details are dragged function to meet the new time [Venu17] Containerized microservices Lightweight virtualization limit. 2.2. Monolithic Application Decomposition determining the different contexts that the monolith encompasses, moving the source code selectively to In [Kecs16], authors offer an approach based on each context package, then choosing one of them to ENTICE project’s Image synthesis technique. The begin the separation process on it (priority criteria principle is to generate dynamic VM images and their like: pace of change, security). In [Maz17], authors required software dependencies (without irrelevant present a formal microservice extraction model to parts) [Kecs16]. Service Cutter [Gys16] uses 16 allow algorithmic recommendation of microservice software’s coupling criteria extracted from academia candidates in a refactoring scenario. This model is and industry practices. It uses domain models and similar to [Gys16] approach. It has two other artifacts as coupling information sources; transformations: construction, which converts the represents them as a graph; before estimating the monolith to graph and clustering, which extracts parts that may be split to independent loosely-coupled microservices from graph. The major advantages and services. Authors in [New15] give the outlines of limits of these approaches is summarized in Table 2. decomposing a monolithic application by Table 2: Monolithic Application Decomposition Approaches Summary Paper Decomposition based on Advantages Limits [Kecs16] VM images Facilitated by Cloud platforms  Requires manual intervention. [Gys16] Design artifacts Closer to user goals isolation  Decomposition may be [New15] Context packages Explicit domain isolation impracticable.  Application altering may [Maz17] Source code Directly executable result be undesirable. 2.3. Discussion which does not imply any structure reforming (no According to the above works summarized in Table redesign consideration concerns). It is mainly based 1 and Table 2, the decomposition may be on the migration principle in Multi-cloud computing. impracticable or leads to fixed-duration functions (do The key idea is that each running serverless function not fit a frequently-changing limit environment). that reaches the maximum duration limit is repeatedly Moreover, it may require manual intervention, or may transferred to another cloud platform where it is have a specific application domain. Hence, it seems carried on. that the decomposition has significant limits and it is not suitable to deal with long-duration Serveless functions. In the following, we propose an approach International Conference on Advanced Aspects of Software Engineering Page 44 ICAASE, December, 01-02, 2018 A Migration-Based Approach to Execute Long-Duration Multi- Cloud Serverless Functions ICAASE'2018 3. The Proposed Migration Approach In this section, we propose a distributed migration approach based on Multi-Cloud Serverless architecture. First, we describe briefly this architecture that uses Docker containers at runtime for executing user functions. This platform is the distributed link that makes the different clouds find each other. Second, we describe the used migration- based technique which is accomplished in two phases: monitoring and migration. 3.1. Distributed Serverless Architecture Figure1: Distributed Serverless Architecture[Solt18] Docker [Vohr16] is a container technique that 3.2. Migration-Based Thechnique bundles the dependencies of a specific application in a single deployable unit called Docker image that can First, we define a variable in our system: MaxLimit. be executed at any node running Docker engine. It represents the maximum allowed time (in seconds) Docker Containers can be connected to combine their for a function to be executed before it is scheduled for resources for the software running within. Dockerfile migration (abruptly terminated in traditional is a collection that embraces all commands of Serverless) and it is configurable by system configuration and downloads required API for the administrators switch to their needs (five minutes by application to be ready for execution. Then it builds default). the container either from scratch or upon other base The novel contribution is adding new specific image (usually, a base container consists of an images and functions to the Container Image operating system and some very basic tools) Repository (CIR) and the Function Registry (FM) [Vohr16]. Each function in the system needs a finite respectively. The new added elements details are as set of container images in order to be able to properly follows: work (its software dependencies). 3.2.1. Function Monitor Image (FMI): It is the We adopt our distributed Serverless architecture runtime image for the monitoring task. We are shown in Figure 1 [Solt18]. This architecture is a Peer choosing Prometheus as implementation for it. to Peer (P2P) system that spans several Cloud Prometheus [Prm1t18] is an open-source system provider platforms (a Middleware for Multi Cloud). monitoring and alerting toolkit and it can be In this paper, we show the role of two needed configured with Docker [Prm2t18]. This image components. has the interfacing API for monitor (see next (a) Container Image Registry (CIR): a registry of point 3.2.2) to use Prometheus. The Monitor API container images for different programming language Docker image is represented in Figure 2. runtimes. This registry is extensible, so runtimes can be added/ removed from it and each node in the Multi Cloud system has its own CIR (for its functions) 3.2.2. Monitor: It is a specific function that has as [Solt18]. role to count the consumed time during (b) The Function Manager (FM): among its roles, it execution, for each function in the local node ensures the communication between different nodes using FMI API and all functions that have ran in the Multi Cloud Serverless system. In this paper, more than or equals MaxLimit are passed to FUS we use it to migrate functions from node to another for migration (see next point). The monitor is along with its all dependencies, so, no worry about periodically invoked to ensure continuous their existence in destination [Solt18]. function refresh (thirty second by default, but it is configurable). International Conference on Advanced Aspects of Software Engineering Page 45 ICAASE, December, 01-02, 2018 A Migration-Based Approach to Execute Long-Duration Multi- Cloud Serverless Functions ICAASE'2018 application with at least one long-running function. Our illustrating case study is a generic machine learning application of three Java-based Serverless functions built over the scientific platform called ANTDROID [Hadr12]. 4.1. System Description ANTDROID [Hadr12] is a federated SaaS available to scientists for sensing the activities of mobile users for their own experiments. The scientist component of the platform provides an interface allowing them to Figure 2: Monitor API Docker Image connect external services to the platform to extract and reuse dataset collected from their experiments’ 3.2.3. Function Urgent Scheduler participants (e.g., visualization, analysis) as shown in (FUS): this function is the scheduler that receives Figure 4. the list of functions that have reached MaxLimit (from monitor). It selects, for each one, a random node and informs the selected node for the function’s dependencies (names only). The node responds back by asking for its missing images; the set passed by FUS to its local FM. Finally, the local FM migrates the function towards the remote FM all along with its missing images (delta images) and its current memory state. Algorithm 1 describes how FUS works. Algorithm 1 Input: List long Output: List migr Figure 4: AntDroid Architecture [Hadr12] For each f in long: This interface will be exploited by a special docker (1) fmid = Selects random node image of our Serverless system (stored (2) sends(fname, dependenciesNames) to fmid in CIR) to build the AntDroid Connect Service or (3) receives (deltaImages) from fmid ACS as shown in Figure 5. (4) adds (f, fmid, deltaImages) to migr End for; (5) returns migr to local FM (6) FM adds the complete deltaImages to migr (7) FM sends each f to its target Figure 3: Urgent Scheduler Algorithm 4. Case Study Figure 5: ACS Docker Image In the aim of showing the actual contribution of our ACS image is now the dependency runtime for all approach and its usefulness, we consider an the application’s three functions (as they do not need International Conference on Advanced Aspects of Software Engineering Page 46 ICAASE, December, 01-02, 2018 A Migration-Based Approach to Execute Long-Duration Multi- Cloud Serverless Functions ICAASE'2018 more than usual Java runtime environment given in Table3. The three functions are executed functionality). The details of the functions as well as sequentially one after another switch to their order in their minimum estimated time before termination are Table 3. Table 3: Example of Functions Set Function name Role Duration Filter Accesses the scientist collected dataset to extract the subset of valuable data. 20 min Learner Iterates the filtered data to acquire new knowledge (statistical indicators). 8 min Viewer Shows the calculated results in graphical plots (like Pie plots). few seconds 4.2. Application of The Proposed Approach to AntDroid Since the dataset collection may be very large and continuously fed by interactions (tens of gigabytes), the two functions filter and learner are estimated to be long, and hence, subjects for this paper procedure to be applied upon. The filter function, hence, will be migrated 3 times in the respective moments 5min, 10min and 15min after it starts. We show in the following figures how does that scenario happen (only once for filter for the sake of illustration). Table 4 discusses the three figures steps and meanings. Figure 7: Migration Scenario (b) Figure 6: Migration Scenario (a) Figure 8: Migration Scenario (c) International Conference on Advanced Aspects of Software Engineering Page 47 ICAASE, December, 01-02, 2018 A Migration-Based Approach to Execute Long-Duration Multi- Cloud Serverless Functions ICAASE'2018 Table 4: Migration Scenario Details Figure part Details (a) Application starting point. (1) The client calls the http link: fmid-url/filter. (2) The FM selects the filter function and its dependency ACS image. As shown in Figure 6. (3) The ACS is started and filter function now executes. (1) The local timer notifies the FM (each 30 sec). (b) After 5 min. (2) The FM prepares to start the new monitoring cycle. As shown in Figure 7. (3) The FMI image and monitor function are loaded to memory. (4) monitor detects that filter reached its max limit. It notifies FM. (1) FM prepares the FUS scheduler function. (c) Migration phase. (2) FUS is started within its container. As shown in Figure 8. (3) FUS executes its algorithm, determines the migration destination and informs FM. (4) FM migrates filter from Node1 to Node2. From this presented illustration of our technique the adoption of virtualization techniques to simulate a where the filter function was (same for learner) big number of physical machines, while in reality migrated as much as needed (3 times here) until its there are only a few of them. termination, the developer concerns himself less about time constraints and any factors affecting them 5. Conclusion during design-time (like unpredictable overloading of Serverless infrastructures, data volumes), focusing In this paper, we have tackled the limit of the more on functional requirements of his application. Serverless principle: all functions should terminate The above case study shows clearly that our their execution in a short period (typically five proposed approach allows the execution of long minutes). We have proposed a distributed migration duration Serverless functions. We intend to consider approach based on Multi-Cloud Serverless some key aspects to improve its efficiency. First, architecture. This migration-based technique deals during the function migration, the destination cloud with Serverless functions that run for a long duration. may not provide the same level of QoS (Quality of Our technique consists of transferring a target Service) desired by the migrated function (although function that reaches its limit in term of execution all the dependencies are ensured) for many reasons, time, to another Cloud platform to be resumed there. e.g. the new host may be in a period of high charge By repeatedly applying this step, a function – no workloads. Another issue is the time necessary to matter how long – finishes its task normally. This execute the algorithm of this paper added to the algorithm is designed to be fast and simple in term of required time to transfer the function state and its scheduling decision, because its main goal is not dependencies. This time can differ from Cloud-pair optimizing resource utilization, but to save long network links affected by parameters like geo- functions from being cut off. We have illustrated the locations, links’ bandwidth and size of transferred use of the proposed approach through the case study functions and libraries. The random aspect of the of a generic machine learning application built over Algorithm1 will be studied as a more fair function the scientific platform ANTDROID. In future, we distribution between nodes. An evaluation of the plan to investigate in the optimization of the incurred latency of Algorithm1 will be conducted by scheduler algorithm. Another interesting work may measuring the diverse parameters mentioned in this concern considering more fair function distribution paragraph, which gives more realistic dimension to between nodes instead of mere randomness-based this architecture. The main tool for this evaluation selection, all without losing the urgent aspect of the will be Semi-physical simulation which is essentially algorithm. International Conference on Advanced Aspects of Software Engineering Page 48 ICAASE, December, 01-02, 2018 A Migration-Based Approach to Execute Long-Duration Multi- Cloud Serverless Functions ICAASE'2018 6. References [Groz14] N. Grozev and R. Buyya, “Inter-Cloud architectures and application brokering: [Bald17] Ioana Baldini, Paul Castro, Kerry Chang, taxonomy and survey,” in Journal of Perry Cheng, Stephen Fink, Vatche Ishakian, Software: Practice and Experience, vol. 44, Nick Mitchell,Vinod Muthusamy, Rodric no. 3, pp. 369–390, Mars. 2014. Rabbah, Aleksander Slominski, Philippe Suter. Serverless Computing: Current [Ader17] Aderaldo C., Mendonça N., Pahl C., Trends and Open Problems. Springer, Jamshidi P., Benchmark requirements for December,2017. microservices architecture research. In https://arxiv.org/pdf/1706.03178.pdf Proceedings of the 1st International Workshop on Establishing the Community- [Kuh17] Jorn Kuhlenkamp and Markus Klems. Wide Infrastructure for Architecture-Based Costradamus: A Cost-Tracing System for Software Engineering, ECASE, May 2017, Cloud-based Software Services. Service- Buenos Aires, Argentina, pp. 8-13. Oriented Computing: 15th International Conference, ICSOC 2017, Malaga, Spain, [Hass17] Wilhelm Hasselbring and Guido Steinacker. November 13–16, 2017, pp.657-672. Microservice Architectures for Scalability, Agility and Reliability in E-Commerce. 2017 [Sbar17] Peter Sbarski with Forewords by Patrick IEEE International Conference on Software Debois, Donald F. Ferguson. Serverless Architecture Workshops (ICSAW), 5-7 April Architectures on AWS. Manning Shelter 2017, Gothenburg, Sweden. Island; 2017. [Alpr15] Sascha Alpers and Christoph Becker. [Kum17] Praveen Kumar Sreeram. Azure Serverless Microservice Based Tool Support for Business Computing Cookbook. Packt Publishing Process Modelling. Enterprise Distributed Object Ltd;August,2017. Computing Workshop (EDOCW), IEEE 19th https://azure.microsoft.com/mediahandler/files/res International, Sept. 2015. ourcefiles/ff388333-6cd0-4b47- a33e3c3296a5141b/Azure_Serverless_Comp [Tarm17]Ahmad Tarmizi Abdul Ghani, Mohd. uting_Cookbook. pdf Shanudin Zakaria. A Method for Analyzing and Designing Microservice Holistically. [Azr18]https://docs.microsoft.com/en-us/azure/azure- (IJACSA) International Journal of Advanced functions/functions-scale, accessed in Computer Science and Applications, Vol. 8, 5/23/2018. No. 12, 2017. [Stig18] Maddie Stigler. Beginning Serverless [Venu17]M.V.L.N.Venugopal. Containerized Computing, Developing with Amazon Web Microservices architecture. International Services, Microsoft Azure and Google Journal Of Engineering And Computer Cloud, Apress; 2018. Science ISSN:2319-7242 Vol.6(11), pp. https://www.apress.com/us/book/9781484230831 23199-23208, November 2017. [Goo18] Google Cloud Functions documentation: [Kecs16] Kecskemeti G., Marosi A., Kertesz A., The https://cloud.google.com/functions/quotas, ENTICE approach to decompose monolithic accessed in 5/23/2018. services into microservices. In International [Fox17] Geoffrey C. Fox, Vatche Ishakian, Vinod Conference on High Performance Muthusamy and Aleksander Slominski Computing & Simulation (HPCS 2016), July (IBM). Report from workshop and panel on 18-22, 2016, Innsbruck, Austria, pp. 591- the Status of Serverless Computing and 596. Function-as-a-Service (FaaS) in Industry and [Gys16]Michael Gysel,Lukas Kölbener, Research. First International Workshop on Wolfgang Giersche and Olaf Zimmermann. Serverless Computing (WoSC), June 5-8, Service Cutter: A Systematic Approach to 2017, Atlanta,GA,USA. Service Decomposition. 5th European Conference on Service-Oriented and Cloud International Conference on Advanced Aspects of Software Engineering Page 49 ICAASE, December, 01-02, 2018 A Migration-Based Approach to Execute Long-Duration Multi- Cloud Serverless Functions Computing (ESOCC), Sep 2016, Vienna, Austria. Springer International Publishing, LNCS-9846, pp.185-200, 2016. [New15] Sam Newman. Building Microservices: Designing Fine-Grained Systems. O'Reilly Media, Feb. 2015 (chapter 5). [Maz17] Genc Mazlami, Jurgen Cito, Philipp Leitner. Extraction of Microservices from Monolithic Software Architectures. The 24th IEEE International Conference on Web Services (ICWS 2017) June 25-30, 2017, Honolulu, HI, USA [Vohr16] Deepak Vohra. Pro Docker. Apress, ISBN- 13 (pbk): 978-1-4842-1829-7, ISBN-13 (electronic): 978-1-4842-1830-3; 2016. [Solt18] Boubaker Soltani, Afifa Ghenaï and Nadia Zeghib. Towards Distributed Containerized Serverless Architecture in Multi Cloud Environments. The 15th International Conference on Mobile Systems and Pervasive Computing (MobiSPC) Gran Canaria, Spain, August 13-15, 2018. [Prm1t18] Prometheus - Monitoring system & time series database. https://prometheus.io/, accessed 27/05/2018. [Prm2t18]https://docs.docker.com/config/thirdparty/prome theus/, accessed 27/05/2018. [Hadr12] N. Haderer, R. Rouvoy and L. Seinturier, “AntDroid: A Distributed Platform for Mobile Sensing,” Research Report RR-7885, Inria, Feb. 2012. International Conference on Advanced Aspects of Software Engineering Page 50 ICAASE, December, 01-02, 2018