Cloud computing is growing in popularity in recent years, mainly due to its attractive business model based on the provision of virtualized computing resources ...
Cloudstep: A Step-by-Step Decision Process to Support Legacy Application Migration to the Cloud Patricia V. Beserra1, Alessandro Camara, Rafael Ximenes, Adriano B. Albuquerque, Nabor C. Mendonça Programa de Pós-Graduação em Informática Aplicada (PPGIA) Universidade de Fortaleza (UNIFOR) Fortaleza, Ceará, Brazil {patybeserra, alessandrocamara, rafaximenes1}@gmail.com, {adrianoba, nabor}@unifor.br Abstract—Cloud computing is an emerging computing paradigm whose benefits (such as high scalability, reduced IT costs, self-service on demand, and pay-as-you-go price models) have increasingly attracted the interest of the corporate world. Nevertheless, many organizations have found it difficult to adopt cloud-based solutions, particularly regarding the migration of their existing legacy applications to this new environment. One of the main obstacles faced by those organizations is the lack of a general process to help application developers not only in selecting the cloud models and services best suited for their application, but also in carefully assessing the various risks and benefits involved. To fill this gap, this paper presents Cloudstep, a step-by-step decision process aimed at supporting legacy application migration to the cloud. The process relies on the creation of template-based profiles characterizing the organization, the target legacy application and candidate cloud providers, which are then cross-analyzed to help identify and possibly resolve critical constraints (either technical or non technical) that may hinder migration to the cloud. The use of the process is illustrated through an analysis of key factors influencing the migration of a commercial medical application to different infrastructure-as-a-service cloud providers. Keywords-cloud computing; legacy migration; decision support process.
I.
application;
cloud
INTRODUCTION
Cloud computing is growing in popularity in recent years, mainly due to its attractive business model based on the provision of virtualized computing resources (such as servers, storage, network, development environments and even entire applications) in the form of pay-as-you-go remote services that can be consumed and managed over the Internet [10][17]. Cloud users thus can easily acquire and release computing resources on demand, which allows them to concentrate on their applications and business needs without the burden of having to manage and continuously upgrade a local hardware infrastructure [3]. Some of the most important benefits commonly associated with the adoption of cloud computing are greater control over operational costs; the illusion of infinite resources; high scalability; and self-service on demand [10]. Those benefits have increasingly attracted the interest of all 1
Sponsored by Programa de Pós-Graduação de Instituições de Ensino Particulares (PROSUP), Coordenação de Aperfeiçoamento de Pessoal de Nível de Nível Superior (CAPES). 978-1-4673-3001-5/12/$31.00 ©2012 IEEE
kinds of organizations, from industry to governmental and non-governmental institutions, which see the cloud as a great opportunity to reduce IT costs, streamline their business processes, and improve the overall quality of their products and services [13]. However, despite these attractions, in practice many organizations have found it difficult to adopt cloud-based solutions, particularly when faced with the need to migrate existing legacy applications to public cloud providers [15]. Cloud migration decisions are inherently complex since they are influenced by multiple, possibly conflicting factors, such as cost, performance, security and legal concerns [16]. In addition, developers must carefully consider possible technical restrictions that may hinder cloud adoption by the organization, such as when its legacy applications may violate environmental constraints imposed by the cloud provider [19]. Another impeding factor is the wide variety of cloud computing services and models currently available. This complicates the selection of the cloud solutions that are best suited for the computing requirements and needs of a given organization [5]. The difficulties faced by organizations in moving their applications to the cloud have started to gain interest from the research community, with several works having recently been published on this particular topic (e.g., [1][2][16] [18][19][20]). Some of these works are reports of case studies involving the migration of existing legacy systems to the cloud [1][18], while others focus on proposing techniques and tools specifically aimed at supporting cloud adoption decisions [2][16][19][20]. However, none of these works has presented a systematic process detailed enough to be useful as guide for application developers and project managers throughout the various steps and decisions involved in a typical cloud migration scenario. In an attempt to fill this gap, this paper presents Cloudstep, a step-by-step process aimed at supporting organizations and application developers in making informed cloud selection and migration decisions. The process relies on the creation of template-based profiles describing key characteristics of the organization, its target legacy application and one or more candidate cloud
providers. These profiles are then cross-analyzed, as a way to identify and possibly resolve critical constraints (either technical or non-technical) that may hinder application migration to the cloud. In this way, the process can help to the reduce the subjectivity of the cloud migration decisions made by the developer, thus increasing the likelihood that the organization will adopt a cloud solution that best meets its needs and demands – if such solution can be found. The rest of the paper is organized as follows. Section II presents the Cloudstep process in more details, describing its main activities and execution flow. Section III illustrates the use of the process through an analysis of the key factors influencing the migration of a commercial medical application to different cloud providers. Section IV covers relevant related work. Finally, Section V offers some concluding remarks and outlines our future work. II.
CLOUDSTEP
A. Process Overview The Cloudstep process is centered on the guided identification and analysis of relevant factors that might influence the cloud selection and migration task. Those factors are usually related to the characteristics of the main entities directly involved in the migration decision: the organization, the target legacy application, and the candidate cloud provider. Therefore, identifying those characteristics is the first step towards determining whether (and how) it would be possible to migrate the legacy application to the cloud. To help developers in characterizing their organization, legacy application and candidate cloud providers, the process relies on the creation of entity profiles based on a set of provided profile templates. The idea is that, as the number of defined profiles increases, which can be stored and made easily accessible with help of automated tools, the easier becomes for the developer to find profile templates whose characteristics are closer to those of the entities involved in the migration scenario at hand. Once the required entity profiles have been created, the next step is to cross-analyze them in order to identify potential migration risks and constraints, as well as to define ways to avoid or mitigate them (e.g., by reducing the application migration scope or by changing the cloud provider). In Cloudstep, this analysis is done iteratively, at different stages, starting from a more organizational context to a more technical one. Below we provide a more detailed description of the Cloudstep workflow, including its main activities and decision points. We also mention some existing work and tools that can be used to partially support the process execution. B. Process Workflow The process is organized into nine activities, ranging from the characterization of the organization profile to the
Figure 1. The Cloudstep workflow.
actual migration of the target application to the selected cloud provider. These nine activities should be carried out according to the workflow shown in Fig. 1. The goals, analysis and decisions involved in each of the process activities are described in the following subsections. 1) Define Organization Profile The goal of this activity is to create a profile for the organization. The organization profile should capture information regarding legal or administrative characteristics that can be considered relevant to the migration task. Examples of such characteristics are policies, guidelines, laws or any other rule or procedure that the organization must abide to, and which somehow might influence its adoption of cloud-based solutions. The idea is to anticipate the detection of potential organizational constraints that might affect the cloud migration decision, before carrying out any further analysis of the application itself or of the candidate cloud providers. The following questions can be used as a guide to define the organization profile:
• • • • • •
What is the motivation that led the organization to contemplate cloud migration? Will the organization business benefit from the migration? How does the organization acquire and allocate its computing resources? Where does the organization develop, test and deploy its software products and services? Is the organization subject to any law or legal restriction on the physical location of its data and/or applications? What is the experience level of the organization's IT professionals, including their ability to negotiate and engage in technical discussions in a foreign language (particularly for non English speakers)?
2) Evaluate Organizational Constraints In this activity, the developer should conduct a preliminary assessment of potential organizational constraints regarding the adoption of a particular cloud model, based on information available in the organization profile. The goal is to allow early detection of critical factors within the organization that may prevent migration to the cloud. In this way, the organizational context also serves as input for cloud adoption decision-making, and not just technical and financial factors. The examples below can be used as a guide to identifying potential organizational constraints [2]: •
• • • • •
Resistance by members of the organization to changes resulting from the migration (e.g., current IT personnel fearing being dismissed after migration); Divergences between emergency handling policies established within the organization and those implemented by the cloud provider; Loss of governance and/or control over existing IT resources; Dependence on legacy applications and/or data that cannot be accessed from outside the organization; Risk of an unauthorized third party accessing critical business data that is kept in the cloud; Legal restrictions on the physical location of critical IT resources (e.g., governmental data that must be stored within regional or national boundaries);
If any critical constraint is found at the organizational level that impedes cloud adoption, the process is terminated prematurely. This prevents the developer from performing any subsequent analysis of technical and/or financial factors, which tend to be more complex in nature. Otherwise, the developer proceeds to the next steps of the process, which focus on the analysis of specific
characteristics of the application and the candidate cloud providers. 3) Define Application Profile In this activity, the developer should create a profile for the application targeted for migration. The application profile should capture any characteristic of the application that may influence its migration to the cloud, thus allowing an objective assessment of the application in view of the candidate cloud models. This activity is divided into two sub-activities, focusing on the identification of relevant application information pertaining its usage and technical characteristics, respectively. a) Identify usage characteristics Here the developer should identify characteristics of the application related to its use and operation. The goal is to elicit key functional and non-functional aspects of the application that may affect its migration to the cloud. The following questions can be used as a guide to define the application's usage profile: • • • •
What are the main features of the application? How many users access the application and from which locations? What are the usage patterns of the application (e.g., periods of low, normal and high user demand)? What is the cost required to operate and maintain the application by the organization?
b) Identify technical characteristics Here the developer should identify characteristics related to the technologies used by the application as well as any other relevant technical information involved in its use of implementation. The following questions can help to elicit the application's technical profile: • •
• • • •
What is the architecture of the application? What are the technologies used to implement the application (e.g., operating system, programming language, development platform, third party components and frameworks)? What are the technologies necessary to run the application (e.g., operating system, execution environment)? What are the technologies used by the application to handle its data (e.g., file system, database, persistence mechanism)? What is the data traffic received/sent by the application? Is there any stringent quality-of-service (QoS) requirement for the application (e.g.,
• •
performance, availability, reliability and security requirements)? What is the minimum hardware configuration necessary to run the application? Is there any other system or application whose services or data the target application depends upon? Where are those systems located? Can those systems be accessed from outside the organization?
4) Define Cloud Provider Profile In this activity, the developer should create a profile for one or more cloud providers. The goal is to characterize each candidate cloud provider in order to verify whether they satisfy the constraints identified for the application and for the organization as a whole. The following questions can be used as a guide to elicit the cloud provider’s profile: • •
• • • • • •
• •
What are the service models offered by the provider (e.g., infrastructure-as-a-service, dataas-a-service, platform-as-a-service [10])? What types of resources (e.g., virtual machines, storage space, development environments) does the provider offer as part of each of its service models? What are the costs and price models (e.g., per hour on demand, per hour reserved, market bidding [7]) for each type of resource? Does the provider offer any form of service level agreement (SLA) guarantees? How many and where are located the provider's data centers? Does the provider offer any other useful additional service (e.g., backup, monitoring, auto-scaling)? What are the security mechanisms put in place by the provider? What implementation technologies/resources (e.g., programming languages, development platforms, software licenses) does the provider support? Does the provider allow access to its internal operational logs (e.g., for auditing or forensic purposes)? What kinds of support services (e.g., via e-mail, phone calls, online chat) does the provider offer to its customers and in which languages?
5) Evaluate Technical and/or Financial Constraints The goal of this activity is to assess the conformance between the organization profile, the application profile and the profile of the candidate cloud provider. To this end, the process suggests a set of constraints that the developer should evaluate taking into account the specificities of the migration task at hand. These constraints were chosen based on an early review of the cloud migration literature (e.g., [1]
[2][3][4][11][15][16][23]), and on our on experience in deploying real-word applications in the cloud [12]. Overall, we identified seven main types of constraints: financial constraints, organizational constraints, security constraints, communication constraints, performance constraints, availability constraints, and suitability constraints. Each of these constraint types should be evaluated within the same context, as prescribed by the following sub-activities: a) Evaluate financial constraints Whenever possible, financial constraints should be evaluated ahead of any other technical constraint. This is because cost restrictions tend to be critical in many small to medium-size organizations. A typical example of a financial constraint is the cost to operate the application after migration to the cloud. Calculating this cost may be a nontrivial task, as it involves a number of technical (e.g., the number and types of cloud resources required by the application) and non-technical (e.g., expected user demand) factors. Other type of financial constraint is the cost of performing the migration itself, which might involve the need to transfer a large volume of business data to the provider's data center as well as the need to change the application to comply with any technological constraint imposed by the provider. b) Evaluate organizational constraints Here the developer should consider any organizational constraint whose proper evaluation might depend on specific knowledge regarding the application or the candidate cloud provider. An example of this type of constraint is when the organization is obliged to keep its application data within regional boundaries. Naturally, evaluating such constraint would require knowing the physical location of the provider's data center. Another example is when the organization's IT personnel are not fluent on the provider's support service languages. c) Evaluate security constraints These constraints are meant to evaluate whether the application and/or the organization’s security requirements are in accordance with the security mechanisms offered by the provider. A typical example is level of encryption implemented by the provider for communication both within and outside the cloud infrastructure. Another example is the level of protection imposed on the provider's virtualized resources. d) Evaluate communication constraints This type of constraint is related to the application's communication requirements, which are usually expressed in terms of bandwidth, latency, data transfer rate, etc. Such constraints are largely influenced by the quality of the network services available at the organization side, as well as by its physical distance to the provider's data center. An example of a communication constraint is when an
most appropriate order in which to evaluate the suggested constraints. This order is important since the presence or absence of constraints of a given type may lead the developer to further confirm or rule out the existence of constraints of other types. For example, the presence of communication constraints between application users and the cloud provider may trigger the investigation of potential constraints regarding the application's availability requirements. Figure 2. Constraints influence diagram.
applications requires low latency for data transmission between its client and server components, which means that moving only the server component to the cloud might not be a good migration decision. e) Evaluate performance constraints Performance constraints refer to the capacity of the application in servicing its users in an acceptable time. This type of constraint is directly related to the capacity (e.g., processing, memory, storage) of the cloud resources offered by the provider as well as to the quality of the communication with the provider's data center. An example of a performance constraint is when the cloud resources offered by a provider are insufficient to fulfill the application's memory or processing needs. f) Evaluate availability constraints These constraints concern the availability of the application once it has been deployed in the cloud. Availability constraints are related to the SLA guarantees offered by the cloud provider. They can also be affected by communication constraints on the side of the application users. An example of an availability constraint is when the SLA offered by a provider is insufficient to meet the availability requirements of the application. Another example is when application users are located in a region with unreliable Internet connections, as this may affect their capacity to communicate reliably with application components deployed on remote cloud servers. g) Evaluate suitability constraints These constraints are characterized by the need to change any aspect of the application in order to make it suitable for migration. An example of a suitability constraint is when the application depends on a software license that is not available on the cloud. Another example is when the application uses a data format that is not compatible with the data format supported by the provider's persistence service. As one can see from the description of each sub-activity, the different types of constraints evaluated are not mutually independent, and can exert an influence on each other. Fig. 2 shows an influence diagram created after performing an influence analysis over each of the constraint types discussed above. This kind of diagram can be useful to help developers and other users of the process to determine the
After all types of constraints have been evaluated, there are multiple paths to consider. If there are no violating constraints, the migration task is recommended and the process moves on to the next stage, which involves the definition of an adequate migration strategy for the legacy application. Otherwise, there are three courses of action to choose from: (i) address the violating constraints in the context of the application itself; (ii) select another cloud provider; or (iii) abort the process if the constraints are found to be irresolvable by the organization. 6) Address Application Constraints In this activity, the developer should attempt to resolve any application constraint identified in the previous activity. This can be done either by changing the application itself (e.g., by making changes to its source code or data format) or by reducing or increasing the migration scope (e.g., by moving only a subset of the application components to the cloud, or moving additional components and systems along with the current target application). In either case, the application profile should be updated, so that the constraint evaluation cycle can be restarted. This cycle goes on until no more constraints are found, or the developer reaches a decision to abort the migration due to unresolved constraints. 7) Change Cloud Provider The goal of this activity is to select alternative cloud providers, in an attempt to address violating constraints identified in the previous evaluation step. Depending on the nature of those constraints, different selection criteria can be used. For example, constraints pertaining the physical location of the application data can be resolved by selecting a provider whose data center is located within the boundaries required by the organization. Similarly, constraints related to operational cost can be resolved by finding a provider with more competitive resource prices or a cheaper pricing model. After a new candidate cloud provider is selected, a new provider profile should be created for it, so that the constraint evaluation cycle can be restarted. As with the Address Application Constraints activity, the evaluation cycle goes on until no more constraints are found, or the developer decides to abort the migration due to unresolved constraints. 8) Define Migration Strategy
This activity should be executed once the developer has decided that there are no critical constraints precluding application migration to the cloud. In this case, a migration strategy should be defined that takes into account all the issues raised during the process execution, including any decision made towards eliminating or circumventing previously identified constraints (for example, by considering a partial migration strategy in which only a subset of the application components are moved to the cloud). Such strategy should minimize not only the initial migration cost, but also the cost of managing and operating the application after it has been deployed in the cloud. Guidelines provided by previous work on SOA migration strategies can also be used to plan the cloud migration. In [9], the authors offer recommendations regarding the ordering of migration efforts, identification of increments that lead to increasing capability and suggestions regarding organization(s) best equipped to lead the migration effort. They also provide the following questions that can be used to plan the migration task: • •
What sorts of activities must be performed to accomplish the migration? What strategies are most appropriate for the migration effort?
Given the emerging nature and relative immaturity of current cloud technologies, it is recommended that the organization starts with a pilot migration project, in order to investigate if the behavior of the application in the cloud will be as expected. In this regard, it is highly advisable to consider multiple migration scenarios, possibly involving different migration strategies and costs. This approach will build confidence that the organization will find a cloud deployment scenario that effectively fits its needs and constraints [12].
We are also working on new tools specifically aimed at supporting the overall process execution. We briefly report on those tools in Section V. III.
In this section, we illustrate the use of Cloudstep to evaluate the main factors, constraints and decisions involved in the migration of a commercial medical application, called Naja RIS [14], to the cloud. To help the reader in better understanding the outcome of the each step of the process, we present our results according to the nine activities that are part of the process workflow. A. Define Organization Profile The organization behind Naja RIS is a small (
