Migrating Enterprise Applications To The Cloud . - Uni-stuttgart.de

Migrating enterprise applications to the cloud: methodology and evaluationFigure 1129Overview of NovaERM system architectureThe user interacts with the application using the NovaERMWeb GUI which provides a graphical user interface to login,complete manual human tasks, enter data, and administerthe system. The business logic layer contains the followingthree components: the business process management (BPM)Platform Activiti, the NovaTec Reference Platform, andthe NovaERM Web Application. All company-internalbusiness processes such as the hiring process are deployedand executed within the Activiti BPM Platform version5.12.1.2 The NovaTec Reference Platform builds thebasis for the NovaERM Web Application by providingnon-application-specific functionality. The NovaERM WebApplication consists of several sub-components representinga partner, e.g., an employee or job candidate, and a contract.All sub-components are realised using services. TheNovaERM Web GUI and NovaERM Web Application arerunning within a GlassFish application server3 version 3.2.1.Finally, the database layer consists of the Activiti Databaseand the NovaERM Database using PostgreSQL4 version9.1.9. The Activiti Database stores the data generated by theActiviti BPM Platform while the processes are beingdeployed and executed. The NovaERM Database containsall the data relevant for the hiring process such as contractdetails and administration information for the whole system.Considering the expansion of NovaTec, the companydecided to migrate some of their operations to the cloud. Inparticular, it was needed to decide what is the solution withthe least impact on their current architecture. Thus, incollaboration with NovaTec, we created a field study toevaluate their options.The challenges we faced during this process were: which part of the system to migrate what is the target system to migrate on if and how to adapt the existing system to operatecorrectly after the migration and most importantly, the lack of automated supportwith respect to the above decisions.In order to address these challenges, in this work we presenta methodology which incorporates decision and refactoringsupport for migration of the database layer of applications tothe cloud. For this purpose, in the following section, wefocus on investigating available methodologies and decisionsupport systems (DSSs) for such scenarios.3Related workFirst, we investigate available vendor-specific andvendor-independent methodologies and guidelines formigrating either the database layer, or the wholeapplication to the cloud. Afterwards, we consider availablerecommendation and DSSs with respect to migration tothe cloud.In Varia (2010), Amazon proposes a phase-drivenapproach for migration of an application to their cloudinfrastructure consisting of the following six phases: cloudassessment, proof of concept, data migration, applicationmigration, leverage the cloud, and optimisation. The datamigration phase is subdivided into a selection of theconcrete Amazon AWS service and the actual migration ofthe data. We use this methodology by applying the first fourphases and refined and implemented the data migrationphase by using our proposed methodology for the migrationof the database layer in order to evaluate the possibility tointegrate our proposal into a methodology to migrate thewhole application to the cloud. Additionally, Amazonprovided recommendations regarding which of their dataand storage services best fit for storing a specific type ofdata, e.g., Amazon Simple Storage Service5 is ideal forstoring large write-once, read-many types of objects.As the methodology proposed by Amazon focuses onAmazonAWSdata and storage services only, we abstractfrom this methodology and integrate the guidelines in ourproposal. In addition to several product specific guidelinesand recommendations Microsoft (2013a, 2013b), Microsoftprovides a Windows Azure SQL Database MigrationWizard6 and the synchronisation service Windows AzureSQL Data Sync.7 We reuse some of these tools, tutorials,

130S. Strauch et al.and wizards and refer to them during the data migrationphase.Google is offering for the App Engine the toolBulk Loader, which supports both the import of CSVand XML files into the App Engine Data Store andthe export as CSV, XML, or text files.8 The potentiallyrequired transformations of the data during the import arecustomisable in configuration files. In addition, Google, Inc.(2013b) supports the user when choosing the appropriatedata store or service and during its configuration. Moreover,Google, Inc. (2013a) provides guidelines to migrate thewhole application to Google App Engine. We refer to thetools during the migration phase and abstract from thevendor-specific guidelines and recommendations in order tointegrate them in our tool.Salesforce provides data import support to theirinfrastructure via a web UI or the desktop applicationApex Data Loader.9 Another option to migrate andintegrate with cloud providers such as Salesforce isto hire external companies that are specialised onmigration and integration such as Informatica Cloud.10 Inaddition to the tools or external support, salesforce.com,Inc. (2013) provides data migration guidelines. Weconsider the non-Salesforce-specific steps for our proposedmethodology. As it will be discussed extensively inSection 4, Laszewski and Nauduri (2011) also propose avendor-specific methodology for the migration to Oracleproducts and services by providing a detailed methodology,guidelines, and recommendations focusing on relationaldatabases. We base our proposal on their methodology, byabstracting from it, adapting and extending it.Apart from the vendor-specific migration methodologiesand guidelines there are also proposals independent from aspecific cloud provider. Jamshidi et al. (2013) identified,taxonomically classified, and systematically comparedexisting research on cloud migration. We considered thelessons learned for the methodology, we propose andaddressed the identified lack of tool support for enhancingcloud migration by implementing a tool realising ourproposed methodology.Reddy and Kumar (2011) propose a methodology fordata migration that consists of the following phases: design,extraction, cleansing, import, and verification. Moreover,they categorise data migration into storage migration,database migration, application migration, business processmigration, and digital data retention. In our proposal, wefocus on the storage and database migration as we addressthe database layer. Morris (2012) specifies four golden rulesof data migration with the conclusion that the IT staff doesnot often know about the semantics of the data to bemigrated, which causes a lot of overhead effort. With ourproposal of a step-by-step methodology, we providedetailed guidance and recommendation on both datamigration and required application refactoring in order tominimise this overhead. Tran et al. (2011) adapted thefunction point method in order to estimate the costs of cloudmigration projects and classified the applications potentiallymigrated to the cloud. As our assumption is that the decisionto migrate to the cloud has already been taken we do notconsider aspects like costs. We abstract from theclassification of applications in order to define the clouddata migration scenarios and reuse distinctions such ascomplete or partial migration in order to refine a chosenmigration scenario.As we provide the prototypical realisation of a toolproviding support and guidelines while deciding for aconcrete cloud data store or service, the migration, and therefactoring of the application architecture accordingly, inthe following, we also investigate the state-of-the-art onDSSs as defined in Power (2002) in the area of cloudcomputing. Khajeh-Hosseini et al. (2011) introduce twotools that support the user when migrating an application toIaaS cloud services. The first one enables the costestimation based on a UML deployment model of theapplication in the cloud. The second tool helps to identifyadvantages and potential risks with respect to the cloudmigration. None of these tools is publicly available. We donot consider the estimation of costs, or the identification ofrisks as our assumption is that the decision for migration tothe cloud has already been taken. We consider aspects likecosts, business resiliency, effort, etc. to be consideredbefore following our methodology and using the tool asdiscussed in Andrikopoulos et al. (2013). Menzel andRanjan (2012) developed CloudGenius, a DSS for theselection of an IaaS cloud provider focusing on themigration of web servers to the cloud based on virtualisationtechnology. As we provide support for the migration of thedatabase layer, we focus on another type of middlewaretechnology. Our approach is also not limited to a specificcloud service delivery model and migration by usingvirtualisation technology.Menychtas et al. (2013) investigate a model-drivenapproach for the migration of legacy applications to thecloud and present an integrated framework supporting thisapproach. Based on the fact that there is not always a modelfor the legacy system to be migrated and that periodicallychanging requirements for example with respect toscalability imply periodic updates of the model, we do notfollow a model-driven approach for migration andrefactoring of the application architecture.Leymann et al. (2011) propose a method based onapplication model enrichment and a corresponding toolchain that allows moving an application to the cloud. Incomparison to their approach, we introduce a DSS guidingthe user through a step-by-step methodology without theneed for an application model.4Migration methodology and tool supportAs discussed above, in this section we introduce astep-by-step methodology for the migration of the databaselayer to the cloud and the refactoring of the applicationarchitecture. Before we introduce the methodology, weinvestigate the requirements to be fulfilled by such amethodology.

Migrating enterprise applications to the cloud: methodology and evaluation4.1 RequirementsThe functional and non-functional requirements we presentin this section aim to provide decision support andguidelines for both migrating an application database layerto the cloud, and for the refactoring of the applicationarchitecture. The presented requirements have beenidentified during our work in various research projects, andespecially during our collaboration with industry partnersand IT specialists from the enterprise domain.4.1.1 Functional requirementsThe following functional requirements must be fulfilled byany methodology for migration of the database layer to thecloud and refactoring of the application architecture:FR1Support of data stores and data services: Themethodology must support the data migration forboth fine- and coarse-grained types of interactions,e.g., through SQL and service APIs, respectively.FR2On-premise and off-premise support: Themethodology has to support data stores and dataservices that are either hosted on-premise oroff-premise, and using both cloud and non-cloudtechnologies.FR3Independence from database technology: Themethodology has to support both establishedrelational database management systems as discussedby Codd (1970) and NoSQL data stores as discussedby Sadalage and Fowler (2012) that have emerged inrecent years.FR4FR5FR6Management and configuration: Any tool supportingsuch a methodology must provide management andconfiguration capabilities for data stores, dataservices, and migration projects bundling togetherdifferent migration actions. This includes, forexample, the registration of a new data store,including its configuration data, e.g., databaseschemas, database system endpoint URLs, etc. Itmust also support the creation of new migrationprojects for documentation of the decisions andactions taken during migration.Support for incompatibility identification andresolution: Any potential incompatibilities, e.g.,between SQL versions supported by different dataservices, must be identified, and guidance must beprovided on how to overcome them. For this purpose,the methodology has to incorporate the specificationof functional and non-functional requirements forboth the (source) database layer used before themigration, and for the target data store or dataservice.Support for various migration scenarios: As the datamigration depends on the context and the concreteuse case, e.g., backup, archiving, or cloud bursting,131the methodology has to support various migrationscenarios.FR7Support for refactoring of the applicationarchitecture: The amount of refactoring of theapplication architecture during the migration of thedatabase layer to the cloud depends on many aspects,such as the supported functionalities of the target datastore or data service, use case, etc. It is thereforerequired that the methodology provides guidance andrecommendations on how to refactor the applicationarchitecture.4.1.2 Non-functional requirementsIn addition to the required functionalities, a methodologyfor migration of the database layer to the cloud andrefactoring of the application architecture should alsorespect the following properties:NFR1 Security: Both data export from a source data store,and data import to a target data store requireconfidential information such as data store locationand access credentials. Any tool supporting themethodology should therefore consider necessaryauthorisation, authentication, integrity, andconfidentiality mechanisms and enforce user-widesecurity policies when required.NFR2 Reusability: As the migration of data can be eitherseen as the migration of only the database layer oras part of the migration of the whole application, themethodology has to be reusable with respect to theintegration into a methodology for migration of thewhole application to the cloud, suchas the one proposed by Varia (2010) for Amazon.NFR3 Extensibility: The methodology should be extensibleto incorporate further aspects that impact the datamigration to the cloud, such as regulatorycompliance. For example, in the USA, the cloudservice provider is responsible to ensure complianceto regulations as discussed by Louridas (2010), butin the EU it is the cloud customer that is ultimatelyresponsible for investigating whether the providerrealises the Data Protection Directive as stated inCate (1994).4.2 Migration methodologyThe step-by-step methodology, we introduce in this sectionrefines and adapts the migration methodology proposed inLaszewski and Nauduri (2011) in order to address theidentified requirements. The methodology in Laszewski andNauduri (2011) consists of seven distinct phases. Duringthe assessment phase, information relevant for projectmanagement such as drivers for migration, migration tools,and migration options is collected in order to assess theimpact of the database migration on the IT ecosystem. Theanalysis and design phase investigates the implementationdetails on the target database, e.g., potentially different data

132S. Strauch et al.types and transaction management mechanisms being used.The goal of this phase is the creation of a plan to overcomepotential incompatibilities between the source and targetdata store, while avoiding changes in the business logicof the application. The migration phase deals with themigration of the data from the source data store to the targetdata store in a testing environment, including tasks such asdatabase schema migration, database stored proceduresmigration, and data migration. After the migration, both thedatabase and the application have to be tested in the testphase. This includes for example tasks such as dataverification and testing the interaction of the applicationwith the new target data store. As applications are ingeneral highly optimised for a particular database, after themigration to another target data store the performance mightbe poor. Thus, optimisations based on the new target storeused are applied in the optimisation phase in order toimprove the performance. The goal of the deployment phaseis to deploy the final system, including actually migratingthe database, to the production environment.At first glance, the methodology of Laszewski andNauduri (2011) addresses most of the requirementsdiscussed in the previous. However, it discusses its phaseson a high level that is not suitable for direct application,requiring further refinement in practice. Furthermore, it failsto satisfy some of the most important requirements that weidentified. More specifically, as the methodology focuses onOracle solutions it only considers the relational databasemanagement system of Oracle as target data store and thefollowing relational data stores as source databases for themigration: Microsoft SQL Server11, Sybase12, IBM DB213,and IBM Informix14. All of these databases are data storessupporting fine-grained interactions through SQL. It isunclear whether the methodology also supports dataservices, as no information can be found on this aspect inLaszewski and Nauduri (2011) (FR1). The methodology isnot independent from the database technology as it focusesFigure 2on a small set of relational databases and does not supportNoSQL approaches (FR3). Moreover, the methodology islimited to the pure outsourcing of the database layer to thecloud and does not consider the context and specifics ofmigration scenarios such as cloud bursting, backup, andarchiving (FR6). As concrete migration scenarios are notconsidered, their specifics and the context cannot beconsidered for the guidance and recommendation towardsrefactoring of the application architecture. In addition, theguidance and recommendations for the required adaptationsof the application architecture during the migration arevery limited, since the migration methodology in Laszewskiand Nauduri (2011) considers only one vendor-specificrelational target data store and a small subset ofvendor-specific relational data stores as source data store(FR7). The vendor-specificity has also the consequence thatthe methodology does not consider the reusability aspectwith respect to the integration or combination of thismethodology with other existing proposals for migration tothe cloud (NFR2).Addressing these deficiencies, in the following wepropose a vendor- and database technology-independentstep-by-step methodology which refines and adapts the oneproposed in Laszewski and Nauduri (2011). Figure 2provides an overview of our proposal consisting of sevensteps. All steps are semi-automatic, in the sense that ahuman (e.g., the application developer in charge of themigration) has to provide input and follow therecommendations and guidelines provided by themethodology. Figure 2 also shows the mapping between theproposed methodology and the one in Laszewski andNauduri (2011). As it can be seen, no direct support for thetest and optimisation phases is provided by our proposalsince there are no identified requirements explicitlyrequiring these phases. The impact of not supporting thesephases is evaluated in Section 5. The steps of themethodology are.Methodology for migration of the database layer to the cloud and refactoring of the application architecture

Migrating enterprise applications to the cloud: methodology and evaluationStep 1 Select migration scenarioThe first step in our proposed methodology is the selectionof the migration scenario. For this purpose, we use the tencloud data migration scenarios identified in Strauch et al.(2013a): database layer outsourcing, using highly-scalabledata stores, geographical replication, sharding, cloudbursting, working on data copy, data synchronisation,backup, archiving, and data import from the cloud (FR6).These migration scenarios cover both migration directionsbetween on-premise and off-premise (FR2).Based on the selection of the migration scenario, amigration strategy is formulated by considering propertiessuch as live or non-live migration, complete or partialmigration, and permanent or temporary migration to thecloud. During this step, potential conflicts between themigration scenario selected and the refined migrationstrategy should be explicitly addressed by proposingsolutions to the user, e.g., the choice of a different migrationscenario. An example of a conflict is the selec

Abstract: Migrating existing on-premise applications to the cloud is a complex and multi-dimensional task and may require adapting the applications themselves significantly. For example, when considering the migration of the database layer of an application, which provides