semi-automated transformation of legacy code and of generic new code to the coding and packaging convenCloud platforms offer diverse evolving programming tions expected by this model, including runtime restricand deployment models which require not only appli- tions. Ideally, programmers would not have to worry cation code adaptation, but also retraining and chang- about how to map Java classes into cloud functions; ing developer mindsets. Such change is costly and is rather, a smart transformation mechanism would perbetter served by automated tools. Subject of the study form this work, resembling a compiler which would are automated FaaSification processes which transform treat the function runtime as its low-level target platconventional annotated Java methods into executable form. Function-as-a-Service units. Given the novelty of the In our previous work, we have reported on a fullyproblem domain, a key concern is the demonstration automated approach called Podilizer [SD17] which of feasibility within arbitrary boundaries of FaaS offer- however fails to transform a number of functions or ings and the measurement of resulting technical and methods. Some failures occur at translation time due pricing metrics. We contribute a suitable tool design to complex code structure. Possible reasons for runcalled Termite with corresponding implementation in time failures beyond translation are use of local inJava. The design is aligned with a generic transfor- put from files or interactive terminals. Furthermore, mation pipeline in which each step from code analysis the runtime overhead of Podilizer becomes needlessly over compilation to deployment and testing can be ob- high whereas in practice, only few functions on the served and measured separately. Our results show that performance-critical path may need to be offloaded to annotations are suitable means for fine-grained con- a FaaS environment. figuration despite ceding control to the build system. Instead, in this work, we explore an assisted apSmaller Java projects can be FaaS-enabled with little proach which is controlled by programming language effort. We expect FaaSification tools to become part annotations and introduce Termite as tooling support. of build chains on a wide scale once their current en- As with the previous work on Podilizer, we limit the gineering shortcomings in terms of tackling more com- study and observations to Java code as input and AWS plex code are solved. Lambda functions as output in order to allow for comparison, but claim that most of the observations also 1 Motivation apply to other combinations without loss of generality. Hence, we aim at contributing novel insight into New computing paradigms such as cloud computing a selective automated transformation of legacy applibring along new programming models with high fre- cations into FaaS-hosted cloud applications which we quency. In domains centered around discrete events name FaaSification for the general case from a softsuch as connected devices, cloud automation or elec- ware technology perspective. We claim that our tools, tronic markets, trends indicate that the execution of Podilizer and Termite1, are the first ones which pershort-lived functions in Function-as-a-Service (FaaS) form such a transformation from monolithic Java code environments will become the dominant hosted code to AWS Lambda units, and do so with sufficient qualparadigm. As the FaaS programming, deployment and
ity to be considered in cloud application prototyping vices. No performance numbers or other details beyond projects. Due to the restriction to Lambda, we re- the changed lines of code were reported. fer to this process more specifically as Lambdafication. Already in 2012, JTransformer was proposed to We employ an experimental scientific method with syn- achieve higher precision and recall of design pattern dethetically generated and manually engineered applica- tection in code analysis and code reengineering tasks tions. The research is backed up by a curated dataset [BK12]. It is available as plugin for Eclipse JDT. It containing publicly verifiable tools, reference applica- works on factbases which are associated to Prolog protions and experiment instructions. As we have previ- cesses to produce analyses and transformations (A&T). ously reported extensively on Podilizer [SD17], we will While a useful expert tool, it requires knowledge of not repeat its design and only include the tool for the Prolog to write A&T which is not a skill most FaaS purpose of experimental comparison in this article. developers would possess, and it lacks a runtime in
The article is structured as follows. First, it dis- tegration for applications with selective offloading to cusses related work. Then, it outlines the research cloud functions. questions and the chosen approach and explain how to map object-oriented programming to a function-based 3 Approach service and execution model. The mapping description is complemented by an abstract pipeline archi- Our approach consists of three parts. First, we identecture and a concrete realisation thereof, the Termite tify three research questions. Then, we explain general tool, with unique benefits in the trade-off between au- decisions which must be taken by any transformation tomation and developer control. Afterwards, we share tool related to the programming model, the handling of the experimental evaluation results and discuss the ex- stateful objects and the design of a transformation protracted findings. The paper concludes with an open cess. The third part presents both the design and the discussion of how software should be written for the implementation of our transformation tool Termite. cloud based on fine-grained functions. 3.1
2
research questions (RQ1–RQ3). Our approach is foSoftware engineering for FaaS environments is an cused on generating empirical results and deriving the emerging topic. In 2019, the European research project answers accordingly. Both RQ1 and RQ2 mirror the RADON was initiated to produce an advanced DevOps research questions from our initial work on Podilizer framework for FaaS but will require time to produce but will result in different answers due to our advanced first results. As one of the first large-scale academic ef- approach. forts, it contrasts established industry approaches such RQ1: Is it economically viable to run a Java applicaas the Serverless Framework. In recent versions of tion entirely over FaaS with no or little cost overhead this framework, cloud function code is supplied with for typical usage patterns? The comparison baseline wrapper functions to achieve deployment across cloud would be conventional programmable platform (PaaS) providers. No further code analysis is performed, and models by deploying the application onto a suitable the framework assumes a function-native development application server as well as programmable infrastrucapproach. ture (IaaS) by wrapping the Java application into a
Code transformation has been proposed to reduce container or a virtual machine. Evidently, the quessoftware prototyping and engineering effort for several tion needs to be broken down to the granularity of ofnew execution environments. In 2015, Cai et al. in- floading Java methods and the way they interact with troduced a pattern-based technique for cloud-readiness each other. If each small helper function becomes a [CZW+15]. The technique uses patterns, rules and cloud function under the FaaS pricing model, deeper templates and was validated on 19 open source Java callgraphs will quickly result in prohibitively expensive projects migrated to AWS cloud services. The trans- hosting. formation did not change the execution nature but RQ2: Is it technically feasible to automate part of modified the storage/persistence layer to attach to Dy- this process? And if so, which percentage of code namoDB and other cloud database and security ser- coverage can be expected, which performance can be achieved, and which code is easier, hard or impossible ing various combinations of local functions into cloud to convert? Evidently, due to our approach of using function bundles and invoking the appropriate bundle. annotations, the automation depends on the choice of In our approach, we perform a simple 1:1 mapping inwhere to put which kind of annotation. stead.
RQ3: Is there a friction-free integration with es- Considering the automation (RQ2), we note that ustablished Java development notations and processes? ing annotations allows for configuring per-method paCan the FaaSification be integrated into existing build rameters on where and how the cloud function should tools? be executed, including an individual assignment of memory allocation and runtime constraints. Moreover, 3.2 PMraopgprainmgming 7→ Execution Model swoe tahragtuea nfoarlyatificnale-agnradinceodrrsetcatgiveed mcoedaesutrreasnscfaonrmbaetiionntroduced for each method in various stages. In our FaaS is inherently bound to the functional program- approach, we will use a pipeline model with multiple ming paradigm. Its characteristics under a pure in- transformation steps per function, and an injection of terpretation are determined by stateless computations additional code for transparently handling state. with strict use of invocation parameters and return values without global variables. In practice, just as func- 3.3 State Handling tional programming languages have introduced techniques to cause side effects and manage state, for in- Java methods are often stateful through instance atstance through monads, so do most FaaS interfaces, for tributes. The state handling of the resulting decominstance through access to storage services. posed functions can either extend the method signature
The function orientation is in contrast to Java’s to pass in and out all attributes that are accessed and model which is predominantly an object-oriented lan- modified, or use server-side state. AWS Lambda offers guage. Even though few functional programming con- both an S3 blob storage interface and local environcepts are available through the Functional Java library ment variables. However, the variables are restricted to and starting with Java 8 with native Lambda expres- read-only access from the runtime. Weighting the adsions [Plu14], the dominant share of code is written in vantages of S3 (performance) against extended method a pure object-oriented way. The same observation ap- signatures (price, functional purity), our approach uses plies to similar programming language. Therefore, the the latter technique. code translation needs to take the paradigm shift into In Java, methods with parameters are integral parts account. of classes and are used to change the state of the corre
The challenges are then related to the mapping of sponding instances: Class.method(params). The inJava classes to appropriately packaged Java FaaS func- stance is self-referenced implicitly with the keyword tions, called FaaS units or functional units. The map- this. According to the Lambda programming model, ping needs to account for empty methods, getters and every function unit assumes a specific stateless class setters, constructors and singletons. Beyond the code, with a method handler which is triggered when the typical Java project conventions such as the presence function is invoked. The statelessness is due to not of a src folder, but also the absence thereof and ex- guaranteeing the same object of this class to be used for ceptions from the conventions, need to be accounted subsequent requests. Early works to compile Java code for. Finally, the mapping needs to consider the group- into a typed Lambda calculus have suggested making ing of methods per functional unit to avoid excessive the self-references explicit by enhancing the method network calls and ensure that all dependency methods signatures with it [WJUH98] which is the approach referenced from each method can be resolved. chosen by us as well.
Considering execution cost (RQ1), in commercial The translation process thus rewrites the method FaaS environments the three contributing factors are header with the Lambda-required signature and execution time, memory allocation and a fixed per- the method body with generated code. This invocation fee, with some providers speeding up execu- code first initialises the invocation credentials, cretion upon allocation of more memory, while code size is ates an input object to save the instance state not a factor. Applying code transformation could lead as well as any method parameters, initialises the to combined cost/performance improvements by pack- Lambda invoker with the created input object serialised to JSON, calls the method (Class.ha- tempts to lambdafy an entire Java project unconditionndleRequest(input, output, context)), fetches the re- ally, including all classes and public methods. Any consult from the deserialised output object, and renews figuration is read from a per-project configuration file. the instance state using the result object. The creden- Podilizer has been described in detail in previous work tials are read from the environment and upon failure [SD17]. The second, Termite, only lambdafies methfrom a configuration file which permits the generated ods explicitly marked by the software developer. Any code to still run outside of the Lambda environment. configuration can be customised through the markers. The impact of the competing designs on software de3.4 FaaSification Pipeline velopment contributes to the answer for RQ3. We are interested to quantify the differences between the two FaaSification is the process of converting a code struc- tools via conformance and performance measurements ture into a format that is executable on FaaS. In our to achieve an answer for RQ2. The resulting functions approach, inspired by the predecessor work [SD17], this are compared against their original monolithic impleprocess is represented by a superscalar pipeline which mentations to finally answer RQ1. allows for parallel processing of each of its steps. The first step is the static code parsing and analysis (A). 4.1 Termite Design The second step is the decomposition into functional units and a remainder which includes the code identi- In contrast to Podilizer, Termite supports the selecfied as incompatible to the target FaaS platform (D). tive publishing of functions through Java method anThe third step is the source-to-source translation of the notations. Through parameters to these annotations, functional units into FaaS units, adhering to the calling the deployment as well as operational aspects can be conventions of the target platform (F ). The fourth step controlled by the software engineer which aligns with is the compilation and dependency assembling of these combined developer and operator roles (DevOps). Usunits (C), and the fifth step is their upload, deployment ing annotations offers the following advantages: They and configuration to turn them into ready to use mi- are part of the Java language syntax, their vocabulary croservices (U ). An optional sixth step is the system- can be learned easily as domain-specific language, and atic test of all deployed functions and the verification they can be extended to cover future FaaS features. of the successful transformation (U ). Fig. 1 gives an In Termite, @Lambda annotations are thus applied on example of a generic FaaSification pipeline whose par- the method level, although recent research on @Java allel execution depends on resource consumption su- for more fine-grained annotations suggests that more perpositioning and on dependencies between methods sophisticated FaaS deployments might become possibefore the ability to run unit tests. In our work, we re- ble [CV13]. All parameters have default values and are fer to the process adopted for targeting AWS Lambda therefore optional, contributing to a rapid service prowithin the boundaries of the pipeline more concretely totyping experience. The set of supported parameters as Lambdafication. is described in Table 1. and parallelisation of method processing. Termite’s transformation work is hooked into the compilation before the Java compiler performs its work. Its runtime part to invoke dependency functions is furthermore coded into the rewritten method invocations (I2).
4.2
Termite takes care of invocations of each function at runtime. The implementation uses AspectJ and the Reflection API. The purpose of the AspectJ library is to create aspects, basically interceptors. Custom aspects can be configured to react on a particular annotation, to interrupt the normal runtime workflow through join points and to perform custom actions Figure 3: Termite implementation architecture and instead. In Termite, the interception logic mandates workflow that each method annotated with the @Lambda annotation is being intercepted and then separated into a Projects compiled with Termite are modified to denew thread. Lambda’s concurrency paradigm is thus pend on Termite’s invocation module. Any data exexploited. Going deeper into the interception logic, change between local and functions is performed usaspects can interrupt the workflow before, after and ing JSON through this module. For each generated around every method or particular marked ones, for Lambda function, additional input and output classes instance with certain annotation. Termite uses the are also generated. These classes are usual POJOs, ”around” interception, meaning that aspects will be resulting in plain old java objects without extending called instead of the main method which is then in existing classes or using other annotations. The input turn invoked again from the aspect. The aspect ini- object is mapped into JSON and transports informatialisation is demonstrated in Listing 1. tion to the Lambda function instance. The object of
The aspect’s join point allows to use the Java Reflec- type output brings data back to the invoker. Input and tion API to get the method specification and perform output classes are built based on the method’s specifithe invocation. Furthermore, if a hosted function is un- cation, its parameters for the input type and its return reachable, a configuration option allows for the method value for the output type. Additionally, the output to be called locally, providing a fail-over mechanism for type contains fields for service time and environment functions that are outsourced for performance reasons description. Listing 2 gives an example of how a sumwithout consideration for local code size. mation method is transformed by Termite. Listing 2: Example of a Termite code transformation. as well in a Lambdafication Repeatability project2. @Lambda( ) The main results of the current implementation are p u b l i c s Styasttiecm i.notuts.upmr(i nint tln a(”1 a,1 i +nt a2a2 =){ ” + ( a1 + a2 ) ) ; reflected in this section.
return a1 + a2 ; } Each step of the pipeline is associated to a unique check for success. The first three steps are performed internally by Podilizer within one procedure, whereas the 4.3 Termite Limitations. three remaining ones are merely automated by running The implemented prototype only supports synchronous executables out of which one is provided by Podilizer, Lambda function calls which may change the program too. In Termite, only the third step is performed by the semantics due to Java offering an asynchronous Fu- tool and the last two steps are automated. The most tureTask class for concurrent compute tasks. Asyn- crucial check is the final one which is successful if all chronous methods using FutureTask would need to en- deployed functions are remotely invocable. According force the corresponding asynchronous function calls to to DZone, about 30.7% of all Java projects hosted on avoid blocking, even though they do not offer cancella- Github depend on JUnit which calls for an integration tion, making a strict translation impossible. The mis- to ensure systematic testing of the deployment [Har13]. match is caused by Lambda not treating function in- Table 2 summarises all steps and checks. stances as first-class citizens. Once deployed, changes in methods are not recognised and do not automatically lead to a re-upload. This means that even for smaller changes, a forced re-deployment has to be performed to avoid code inconsistencies. 5 Trials and Findings Both transformation tools instrumented with millisecond-precision logging to reveal the duration of We evaluate Termite experimentally with a standard each pipeline step. In addition to the performance, research testbed approach shown in Fig. 4, first on the quality of the transformation can be measured its own and then in comparison to Podilizer. All in- by the ratio of successful checks against all which are put to the experiments is recorded in public versioned performed in each step. repositories, and all raw output is captured in another The economic aspect requires a comparison between dedicated repository. The versioning allows for finding the execution of the lambdafied application compared improvements and regressions over time as the soft- to a monolithic execution in a configuration which ware evolves. All experiments are tracked in a pub- matches the performance. In the absence of a general lic Open Science Notebook and tools for reproducibil- 2Lambdafication Repeatability in the Open Science Frameity, repeatability and recomputation are made available work: https://osf.io/c886p/ performance estimation formula, a manual calibration specific to each software application under test is there- Table 3: Lambdafication pipeline characteristics (qualfore needed. ity) foSrtePp1–P6P1w:QithPT2:eQrmiPt3e:.Q P4:Q P5:Q P6:Q JwaavTraehesaoprfptewfleiacrareetnicoeenngsininwpehueitrcihpnrgro,ejprearcnetsgesinenttg ctfhoronemslias2trsg8eotfovas7rix7ie1tsyosifgot--f CTVUAO,DT,FAL 10f000a%%%i–l 1033f033a%%%i–l 10f088a%%%i–l 10f000a%%%i–l 10f066a%%%i–l 10f000a%%%i–l nificant lines of code (SLOC), diverse interaction forms (none, standard input and output, graphical, files, pile with Termite through Maven and the resulting HTTP methods) and build tools (javac, make, maven, sizes with generated code are compared in Table 4. ant) and artefact type (applications, libraries, plugins, Compared to Podilizer, the overhead is much lower tests). The software projects are a graphical window both on average and per each individual project. with buttons (P1), mathematical functions (P2), calculation of shipping containers and boxes (P3), public Table 4: Application source code size comparison betransport information (P4), image processing (P5) and fore/after using Termite. domain-specific language parsing and evaluation (P6). Flavour P1:S P2:S P3:S P4:S P5:S P6:S hAenlloarwtiofirclidalmpertohjoecdts cisonussiesdtinags oafdd1i0t0ionnualmcboemrepdarJisaovna LOOarvmiegrbihndeaaalfided 33392238kk%bb 419404218kk%bb 1532438473kk%bb 1228488427kk%bb 1936494892kk%bb 713066036kk%bb point (P7). 5.2.2
Comparative results
Fig. 5 shows the performance timeline of Termite on We have run the experiment on a notebook with Intel the synthetic application P7. On average, including the Core i7-4800MQ quad-core processor clocked at 2.70 Maven overhead, around 5-6 seconds are spent on proGHz. The notebook was connected to SWITCHlan, cessing each annotated function in addition to possible the Swiss university network, via 1000baseT Ether- network delays. The total processing time per method net, and installed with Ubuntu Linux and OpenJDK is 12.06 s which factors in further Maven and AspectJ 8. The results differ depending on the chosen software overheads. In contrast, Fig. 6 shows the correspondproject to translate. The values are also influenced ing performance timeline of Podilizer. The raw build by the hardware, the used software tools (Termite and and upload time is similar, albeit slightly higher comPodilizer, AspectJ, Maven, JUnit), the FaaS runtime pared to Termite with about 6-7 seconds. The discrepenvironment (AWS Lambda, Snafu) and the network ancy can be observed with the translation time that the connection in between. A full specification and self- tool implements by itself which slows it down considcontained virtual machine is made available as part of erably to a total processing time per method of 17.21 the Lambdafication Repeatability project. s. This implies that despite Termite’s more flexible approach, it is about one third faster than Podilizer. The 5.2.1 Termite results drawback is that the Termite implementation does not consider dependency functions whereas Podilizer conThe evaluation of Termite follows the same pattern siders all methods in a file as potential dependencies as the one already published for Podilizer. Table 3 for which proxy stubs are generated. summarises the achieved transformation quality on the Table 5 compares the overhead on code size of both projects P1–P6. Due to the combined analysis and approaches, starting with the synthetic code file of P7 transformation steps, the results for A → D → F are which accounts for 14.0 kb with annotations and 5.8 joined. The evaluation omits the verification step V kb without. Due to the included stubs, the overhead entirely due to the impossibility to invoke remote func- is much higher on the source side with Podilizer, but tions from other functions with the current implemen- less on the binary side as the dependency JARs per tation. Consequently, all projects fail overall although function, which are almost equal in both tools and inporting the related functionality from Podilizer would clude the AWS SDK, account for the majority of added be possible with moderate engineering effort beyond space. An apparent drawback is that Podilizer assumes our research work. all other methods per file to be dependencies instead of The original project sizes after adjustments to com- performing a static call tracing which would drastically 18 16 14 12 ()s 10 item 8 6 4 2 0 reduce the overhead and could then be implemented in Termite as well, reducing the differences between both approaches on the implementation level. for individual function access. According to a recent study, at least 20% of Java methods are too accessible (public instead of protected or private) [VBMP16], while for our work, they are sometimes too inaccessible, although the solution to both is the same: powerful refactoring tools for software engineers. Further difficulties originate from interfacing with the Java virtual machine, for instance through the classloader, and with the command-line interface, as well as with data access with differing file paths.
A comparison between our two approaches, Podilizer and Termite, is available through Table 6. The commonalities in scope and process are contrasting the differences in how much control a developer has over the process. The advantages of the Termite which included lessons learned from the earlier Podilizer implementation are clear. Its design foresees for instance the fallback invocation of the local method in cases where the cloud-deployed transformed copy is not available.
further compared in Table 7. While Termite is limited to rather simple code structures, Podilizer handles several advanced cases well including exceptions and dependencies between methods, but also weighs in with more than twice the significant Lines of Code (LoC). Both tools integrate with Maven and handle common programming styles such as classes with and without packages, but Termite currently lacks proper support for object attributes.
6 Discussion questions becomes possible. While the answers have been discussed in context before, the following list sumOur findings in automated Java code to Lambda units marises the claims. transformation look promising for future cloud appli- Answer to RQ1: The economic viability of FaaS decation engineering. The results are also beneficial to pends on the request frequency and load in addition programming education where rather simple object- to the rather volatile pricing model of cloud providers. oriented applications are in wide use and educators reg- In the case of the reference applications, the load genularly struggle to keep up with new application hosting erally justifies the FaaSification when less than 200000 formats and platform services. requests per month occur.
Difficulties originate from code that is not prepared Answer to RQ2: The automation is possible although keeping the engineer in the loop through con- Annual ACM Symposium on Applied Comtrolling annotations and a resulting semi-automation puting, pages 1688–1693, Coimbra, Portuis preferable. The averaged code coverage ranges from gal, March 2013. 8% (Termite) to 83% (Podilizer) due to implementation differences. The averaged overhead figure ranges [CZW+15] Zhengong Cai, Liping Zhao, Xinyu Wang, from 2131% (Termite) to around 10518% (Podilizer), Xiaohu Yang, Juntao Qin, and Keting and the performance figure from 62 s (Podilizer) to 254 Yin. A pattern-based code transformas (Termite). tion approach for cloud application migra
Answer to RQ3: Annotations are a suitable estab- tion. In 8th IEEE International Conferlished Java notation which given the current progress ence on Cloud Computing, CLOUD 2015, of the field represent the least friction in terms of de- New York City, NY, USA, June 27 - July velopment tooling integration. Triggering the FaaSifi- 2, 2015, pages 33–40, 2015. cation process through the build system is also consid- [Har13] Chen Harel. GitHub’s 10,000 Most ered suitable, even though alternatives such as explicit Popular Java Projects: Here are method calls at runtime have not been discussed. the Top Libraries They Use. on
Overall, we believe that the tool designs and imple- line: https://dzone.com/articles/ mentations are helpful in accelerating cloud deploy- githubs-10000-most-popular, 2013. ments despite needing more fundamental research on the OOP to FaaS mapping and tool engineering and [Plu14] Martin Pluemicke. Functional Interfaces testing. Inspired by the results of using Termite, we vs. Function Types in Java with Lambhave successfully implemented a basic form of selec- das. In Software Engineering (Workshops), tive FaaSification to the Lambada tool which performs number 1129 in CEUR-WS, pages 146–147, static and dynamic transformation for Python applica- Kiel, Germany, February 2014. tions [Spi17]. [SD17] Josef Spillner and Serhii Dorodko.
Future work identified by limitations of our ap- Java Code Analysis and Transformaproaches encompasses the handling of dynamic class- tion into AWS Lambda Functions. loading, server-side state handling, FaaSification be- arχiv:1702.05510, February 2017. yond Java and Python as input languages and AWS Lambda as target service, improved developer tooling [Spi17] Josef Spillner. Transformation of Python integration, as well as optimisations for attribute and Applications into Function-as-a-Service method dependencies including the creation of function Deployments. arχiv:1705.08169, May 2017. clusters or bundles. [ST15]
ucation Research Grant which helped us to run our [VBMP16] Santiago A. Vidal, Alexandre Bergel, Clauexperiments on AWS Lambda as representative public dia Marcos, and J. Andr´es D´ıaz Pace. Uncommercial FaaS. derstanding and addressing exhibitionism in Java empirical research about method References accessibility. Empirical Software Engineering, 21(2):483–516, April 2016.
Alexander Binun and Gu¨nter Kniesel. Joining Forces for Higher Precision and Recall [WJUH98] Andrew K. Wright, Suresh Jagannathan, of Design Pattern Detection. Technical Re- Cristian Ungureanu, and Aaron Hertzport IAI-TR-2012-01, University of Bonn, mann. Compiling Java to a Typed January 2012. Lambda-Calculus: A Preliminary Report. In Types in Compilation – 2nd InternaWalter Cazzola and Edoardo Vacchi. tional Workshop, volume 1473 of LNCS, @Java: annotations in freedom. In 28th pages 9–27, Kyoto, Japan, March 1998.