Sie sind auf Seite 1von 8

2013 IEEE Seventh International Symposium on Service-Oriented System Engineering

Effort Estimation in Cloud Migration Process

Kewei SUN
IBM Research - China Beijing, China e-mail: sunkewei@cn.ibm.com

Ying LI*
School of Software and Microelectronics Peking University, Beijing, China e-mail: li.ying@pku.edu.cn

AbstractOne major benefit claimed for cloud computing is cost saving, which stimulates enterprises to migrate their workload to cloud. Cost Models and assessment approaches appear as major tools aiming at better understanding and deciding cloud migration. However, their focuses are on the post-migration cost assessment. How costly a cloud migration process can be is still an open question. Cloud migration is a comprehensive process involving insightful assessment and technique supported tasks, which requires a systematic end-toend view. In this paper, we undertake one of the first attempts to conduct effort estimation in cloud migration. We elaborate the cloud migration process with assessment on the steps. A process-based effort estimation approach is presented to assess the investment of a cloud migration process before it is undertaken, and the case study is discussed to demonstrate the feasibility of the approach. Keywords- cloud computing; migration process; effort estimation

I. Introduction Research challenges in cloud computing have been discussed broadly from both technology and economics perspectives [2][3][6], wherein the challenges for enterprises to adopt cloud computing are highlighted and attract special attentions [5]. These researches and discussions make it clear that there are a large number of opportunities and big benefits for enterprises or organizations to move workloads into cloud computing model. Cost saving has been treated as the key motivation of cloud adoption [8][5]. The vast majority of current cloud research efforts focus on the direct cost and effort of computing provision, such as hardware costs, software costs and efforts of maintenance. Few discussions considers the economic issues around migration to cloud. Though papers[14][15]discussed and analyzed the case studies of migrating workload to public IaaS, they focuses on post-migration cost, which is the cost of infrastructure and maintenance after migration process is completed. How costly a cloud migration process could be is still an open question. In practice, the cloud migration is a comprehensive process involving insightful assessment and technique supported tasks, which is non-trivial and cant be done overnight. Understanding the efforts and cost of cloud migration is critical for cloud adopters, because under or over-estimated cloud migration process can have detrimental effects on the business, for example, the under-estimated cloud migration may cause unexpected disruption of business.
978-0-7695-4944-6/12 $26.00 2012 IEEE DOI 10.1109/SOSE.2013.29 84

Understanding the efforts and cost of cloud migration is far from straightforward because of discrepancies between the cloud platform and workload running environments, which is provided by the traditional platform. There are often differences in the versions of various infrastructures, the libraries available, not to mention those comprehensive interdependencies among configuration items. In our previous work, we built the IBM migration tool called UCM [25][26], which automatically migrates configurations of workload across different platforms, for example, from physical platform to virtualized cloud platform, with transformation logics inside. When using UCM in the real cases, we found that the whole cloud migration process involves multiple tasks like requirement collection, planning and analyzing which are labor-intensive. The amount of labor efforts required should be assessed before the real cloud migration. Various target cloud service models may have different requirements for migration. For example, migrating application to SaaS requires data extractions, and potentially code rewriting to support multi-tenancy model, while if the target cloud environment is a private cloud virtual infrastructure or a public IaaS (we call it infrastructure-level migration), it is essential to migrate the configurations of the workload and then deploy the workload on the new cloud environment. The configurations describe the dependencies and constraints among components of the workload, as well as the deployment requirement of workload on its underlying infrastructure. That is, the infrastructure-level migration is majorly moving configurations so that the workload can be deployed and run on the new cloud. In this paper, we focus on explore the effort of the infrastructure-level migration because of our practical experiences of using UCM migration tool, and more importantly, because for many enterprises, their first trials on cloud computing are going to consolidating workloads onto private virtualized cloud environment [5], or moving applications to public IaaS [8]. Though our focus is infrastructure-level migration with configurations, we try to take a general enough cloud migration process as the estimation base. Therefore, our effort estimation approach can be a reference for other kinds of cloud migration scenarios. Based on the cloud migration process, we leverage the empirical software effort estimation approach Putnam method in the cloud migration context. According to NIST cloud reference architecture [3], cloud providers should offer cloud service management functions to support cloud

migration (it is called portability). The proposed approach is to assist cloud provider to estimate the cloud service management functions in terms of their operational cost. The rest of this paper is organized as follows: Section II elaborates the cloud migration process based on our experiences and lecture studies. Section III presents the effort estimation approach in detail. Section IV discusses the case study. Section V introduces the related work and finally Section VI concludes the paper. II. Cloud Migration Process The process of migrating workload from source to target cloud environment could be divided into three major phases: plan, migration and validation. As mentioned before, we focus on infrastructure-level migration. To simplify, here we refer the workload with its source infrastructure as source system, and the workload with its new cloud infrastructure as target system. Firstly, the planning phases include negotiation with end user about the target system, planning the scale according to the source system, and also design the migration approach of the whole migration tasks. Secondly, after the planning phase, the system migration engineers (SMEs) would enter the migration phase of the migration task. In the migration phase, the SMEs would firstly discover the source system and then make reconciliation on the discovery result to make sure that it correct. After reconciliation, the discovered data would be complete and have no conflict of configuration parameters. With correct data, the SME would be able to map from source configuration information to target configuration information. This will create a corrected model on the target system and make ready for migration. The migration task is to move configuration settings from the source system to the target with the data model described from them, and the provisioned target cloud according to the defined scale from the planning phase. During migration, a remediation task would be applied on the target system, to make the performance of the target system as well as the source system. At last, a test phase will be applied to the target system for verifying the functional and nonfunctional requirements of the system working on the target environment. The detailed execution sequence of the migration process is illustrated in Figure 1.

the requirements of the target system according to the current configuration setting of the source system. When migrating to cloud, this usually means that the source system is not the same with the target system, and the end user is expecting their system to perform better on the target system comparing with the source. It is not necessary that the end user knows the target system well, but usually they know better about their source system. The SMEs need to collect the requirements from the end-user and make a first step mapping from the source system to the target system. The requirement collection is usually a manual task, and the quality of the negotiation result will impact a lot on the quality of the migration task. Migration Planning: The migration planning task defines what the target system looks like, according to the requirement collection results. The target system could be a public cloud, private cloud or a hybrid cloud. SMEs will choose different approach to migrate the workload considering different styles of cloud. If the target system is a private cloud, SME will also need to define the scale of the private cloud, including how many physical machines needed, how many machines need to be deployed and also the network planning of the target system. If the target system is a hybrid cloud, SMEs will need to decide which data should be stored in the private data center while putting the other data out of the public cloud. The migration planning phase makes decision based on the information collected from the requirement collection task. It can only generate a rough planning of the scale of the target system and the detailed design is left to the migration phase. B. Migration Phase Discovery: The discovery task focuses on collecting configuration information from the source system. This includes three levels of configuration information. The first level of configuration information targets on knowing how the system is deployed. For example, how many physical machines are deployed in the source system? What is the network topology of these physical machines? This information would be used to determine the deployment scale on the target cloud environment. The second level of configuration information is about application, which discovered the application deployments topology of applications regarding to the physical machines in the source system. The third level is the configuration parameters, which discovered the detailed configuration parameters of each software component, including operating systems, middleware, and also applications installed on middleware. The configuration discovery task will build a full configuration data model reflecting the configuration information on the source system. Assessment and Design: the assessment and design task targets at building a migration strategy and assess the feasibility of the strategy. According to the result of the configuration discovery task, SMEs now have a clear image of the source environment. According to this clear image, it is possible to describe the characteristics of the workload on the source system and furthermore assess the feasibility of moving the workload to the cloud. After the feasibility is

Figure 1. Cloud migration process A. Planning Phase Requirement collection: Requirements negotiation is a task for SMEs sitting down with the end users talking about

85

assessed, SMEs could move further to design the migration approach. This design is based on a comprehensive analysis of the discovered data. The analysis may include migration objective planning, Return on Investment (ROI) analysis, as well as technical feasibility assessment. Map: although now we have the detailed configuration data discovered from the discovery task, there is still a huge gap between the source and the target for cloud migration. The source system usually consists of physical machines, while the target system is either a virtual system or a hybrid system mixed with physical machines and virtual machines. The map task is aimed to translate from the source data model collected and organized in discovery task to the data model describing the configuration information on the target cloud environment. The configuration information is complicated, and may be too complicated for system migration engineers to handle manually. Usually this requires an automatic way to translate. After the map task is done, there will be a data model containing all of the information from virtual machine deployments level, operating system level, middleware level and application level. These information would be sufficient to guide the provisioning and migration tasks. Provision: according to the data model calculated from the map task, the provisioning task is in charge of building the runtime environment for accommodating the workload on the target cloud environment. The runtime environment of a workload includes physical machine, hypervisors, virtual machine, operating systems, middleware and application binaries. After provisioning, the hardware and software stack is ready to accept the workload on the target environment. Besides software and hardware installation, the network planning is also applied on the target environment. When migrating to cloud, there are two ways to provision the target system: one way is to build up the hardware and software stack layer by layer, that is, from VM provisioning to application installation; the other way to provision the system is to move each VM level system as a whole from source to target. The second provisioning way will need to include direct P2V technology from VM level. The pros and cons for each provisioning method, which is out of the scope of the discussion of this paper. Migrate: The goal of migrate task is to move the configuration parameter information from the source to the target system. According to the calculation results from the map task, the migrate takes in the configuration model, and set the configuration information to the target system. After the configuration information is set, the migrate task also need to make a remediation of the target system. The goal of the remediation task is to make sure that the newly accommodated workload is adaptive to the target system, and the system will work in an optimized way. C. Test Phase Test: though the system is migrated following the migration process in each step, it is still very necessary to perform a test on the whole environment. The test phase will goes through each of the function point of application under the designed workload. The test will cover both the

functional and nonfunctional properties of the target system to make sure it works as well as or better than the source system. III. Effort Estimation The cloud migration process is defined sequentially. It seems that a normal migration process will goes from the information collection in plan phase, going through migration phase and end up with a validation testing. However in real cases, the migration task is executed iteratively rather than sequentially. If one step fails, all the steps before this are expected to be executed again. When evaluating the cost of a migration task, it will be more precise if we take the repeated work into account, then the efforts would be much bigger than ideally ignore the mistakes. In real cases, the root cause analysis for a mistake in one step of the cloud migration process could be very difficult, because the system are different from one another. It is almost impossible to find out a common way to get the root cause. However, the problem-solving is following a recursive way. That is, if we encounter a problem in a certain migration step. The root cause might only be in the step itself or in the previous steps. Therefore, we can generate an approach to search the root cause one step each time and define an recursive method to calculate the cost. As illustrated in Figure 2, we defined Provision task as Tprovision and the efforts needed to finish the provisioning step as Eprovision and also the probability when the provision task could be successfully executed is Ps(Tprovision), and it's very easy to conduct that the probability when the provision task could be failed is 1-Ps(Tprovision). With the provision task failed, no matter we reach out to find the root cause or not, we would either need to redo the provision task or redo the task one step before provision. We define the efforts to recover from a fail over provision task as Ef(Tprovision) and in contrary, we define the effort when the task is smoothly executed as Es(Tprovision). Therefore, the effort need for provision to finish could be represented as: E Pr ovision = E s (T Pr ovision ) Ps (T Pr ovision ) (1) + ( E f (T Pr ovision ) + E Map ) (1 Ps (T Pr ovision ))

Figure 2. Recursive calculation of task effort For representing the algorithm in a general way, Suppose we create a NULL task T0 before Collection Task, and the effort

86

of T0 is defined as E(T0)=0, The task on the Kth position of the process is defined as TK. Therefore, the effort of each task could be uniformed defined recursively as
E Tk = E s (Tk ) Ps (Tk ) + ( E f (Tk ) + E Tk 1 ) (1 Ps (Tk )) E T0 = 0

(2)

and the overall migration effort could be defined as


Emigration = ETk = Es (Tk ) Ps (Tk ) + (E f (Tk ) + ETk 1 ) (1 Ps (Tk )) (3)
k =0 k =0 8 8

ability of a particular team to produce software of a given size at a particular defect rate, Effort is the total effort applied in person-years, Time is the total schedule of the project in years. [28]. When evaluating the migration effort, we keep the original definition of the Productivity and Time, but re-define the Size as following, Suppose the number of software component binary is Nb(Tk) and number of configuration items is Nc(Tk), for a specific step in the whole migration process, we define the Size of step k as

Size ( k ) = N b ( Tk ) + N c ( Tk ) (4) Therefore the Effort of step k would be represented as


E s (T k ) = N b (Tk ) + N c (Tk ) Pr oductivity

whereE T0 = 0

Under the recursive definition, the system migration administrator could estimate the migration efforts through effort estimation of the effort (success and failure) and the probability of success on each migration step separately. When migrating to cloud environment, the effort and probability estimation is mostly determined by the capability of the migration team, size and complicity of the workload. Migration Workload Size and Complexity: The complexity of a migration workload is determined by the number of software components binary, the number of configuration items and the inter-dependency between configuration items. Typically, the software component is organized in multitier structure, from operating system level to middleware level to application level. Without considering the configuration items applied, the software components binary is a group of files requires no customization during migration. If the source and the target system are the same, the migration requires only copy and paste contained binary files. Otherwise, if the source and the target system are not the same, the migration requires to recompile and reinstalling the software component to the target environment. In the second situation, if there is standard installation package, usually released by the producer, only installation effort is required. Configuration items are the changeable parameters which are different in either format or content or both on the source and the target system. When migrating to cloud, the source and target platforms are totally different. Under this situation, for enabling the same or better performance, the application would need to be re-configured on the target. Each configuration item change would need efforts throughout the migration lifecycle, including the configuration items collection, planning for the configuration change, discover the configuration information from the source system, assess the feasibility on the configuration change, mapping from the source to target and finally setting the configuration onto the target system through provisioning and migration. Therefore, the number of configuration items is important factors for evaluating the effort of the migration. We leverage the Putnam method [28] to evaluate the effort of each migration tasks. In Putnam Method, Where Size is the product size in terms of ESLOC (effective source lines of code), B is a scaling factor and is a function of the project size, Productivity is the process productivity, i.e., the

(5)

And suppose each sub step of Tk has the same probability to be failed therefore (6) E f (Tk ) = E s (Tk ) / 2 and the unit of E is person-days. y Capability of Migration Team: A migration team composes of SMEs who fulfills a cloud migration task through collaboration. The capability of SME could be diverse. Usually, SMEs have different migration task(s), at which him or her is doing efficiently. The capability of the SMEs on different migration tasks could affect significantly on the probability of accomplishing a success migration task. Formally, we describe the capability of each SME in a capability metrics. An example capability metrics is described in Table 1. Table 1.Migration Team Capability Table
Collection Plan Discover Design Map Provision Migrate Test Peter Expert Professional Amateur Amateur Amateur Amateur Amateur Amateur Mike Amateur Amateur Expert Expert Professional Professional Expert Amateur Mary Amateur Amateur Amateur Amateur Amateur Amateur Amateur Expert Kevin Professional Professional Professional Professional Professional Professional Professional Professional

Table 1 describes a migration team with four SMEs. And the capabilities of each SMEs are different. In this example, Peter is characterized as a requirement collection and planning engineer, and Mike is good at migrate workload according to the plan. Mary is a testing engineer. Kevin is good at everything who could be a backup for everyone in the team. We classified the capability of each SME on a specific task into three categories: amateur, professional and expert. And accordingly, we assign a probability of success value to each category. The probability assignment is described in Table 2. Table 2.Probability Assignment Amateur 0.6 Professional 0.8 Expert 0.9

87

From amateur to expert, the SME is more and more possible to perform a migration task on his or her own without encountering any problems. Since each migration task is error-prone, there's no guarantee that an expert could perform the task a hundred percent error-free. Therefore, we design the 0.9 probability for the expert level. Combining the migration capability description in table 1 and the probability assignment in table 2, we can now have the capability description metrics for the example team. As illustrated in Table 3. Table 3.Migration Team Capability Metrics Peter Mike Mary Kevin Collection 0.9 0.6 0.6 0.8 Plan 0.8 0.6 0.6 0.8 Discover 0.6 0.9 0.6 0.8 Design 0.6 0.9 0.6 0.8 Map 0.6 0.8 0.6 0.8 Provision 0.6 0.8 0.6 0.8 Migrate 0.6 0.9 0.6 0.8 Test 0.6 0.6 0.9 0.8 In table 3, we assigned a probability value for each SME on each migration task. Suppose we have n SMEs on the team, for each SME i, the capability of SME i on a specific task Tk could be represented as pi,k. The capability of the whole migration team on a specific task could be calculated according to the following formula:

with High Availability (HA) deployment. As the collection result, Figure 3 shows the source deployment.

Ps (Tk ) = 1 (1 pi ,k )
i =1

(7)

According to the formula, the capability of the team describe in Table 3 could be represented as following in Table 4. Table 4.Migration Team Capability Collection 0.9968 Plan 0.9936 Discover 0.9968 Design 0.9968 Map 0.9936 Provision 0.9936 Migrate 0.9968 Test 0.9968
IV. Scenario Evaluation Taking the real scenario of migrating a typical 3-tier application from the source system to the target private cloud platform, we calculated the effort of migration process as follows. In the planning phase we collected the raw configuration information from the end user about the source system deployment wherein a J2EE application with Websphere Application Server as application middleware. The application is deployed in cluster with 1 deploy manager and 3 peer nodes. All of the nodes are connect to a DB2 database

Figure 3. Source deployment When migrated to cloud, the workload will use the cloud resource management API for resource allocation and HA guarantee. Therefore, in planning phase, we didnt need to consider the configuration on the WAS Deployment manager and also the related DB2 HA setting. Instead of 3 WAS nodes and 2 DB2 nodes, one for each should be considered. Comparing the source and the target cloud environment, there are three types of configuration item changes (in configuration file level): Type I: configuration files exist only on the source but not on target (we can ignore) Type II: configuration files exist only on target but not on source Type III: configuration files exist on both source and target (needs configuration mapping) In this scenario, the number of configuration files for each type is 59, 27, and 113 correspondingly, listed in Table 5. The Type I can be ignored since it indicates the configuration parameters which are not applicable for the target environment. These parameters can be treated as deprecated configuration values. The number of configuration files which will be took into consideration is 140, and the number of binary of the software components is 3. Table 5.Configuration Files Change Table Type I Type II Type III # of files 59 27 113 Therefore the total size of the migration task is 143. Size = N b (T ) + N c (T ) = 3 + 27 + 113 = 143 Referencing the team capability described in Table 3, Peter is assigned to perform the planning, Mike and Kevin for the migration phase and Merry for the testing phase. According to this arrangement, the capability table would be tuning as Table 6. Table 6.Capability Metrics (Trade6 Migration) Peter Mike Mary Kevin Team Collection 0.9 0 0 0 0.9 Plan 0.8 0 0 0 0.8 Discover 0 0.9 0 0.8 0.98 Design 0 0.9 0 0.8 0.98 Map 0 0.8 0 0.8 0.96 Provision 0 0.8 0 0.8 0.96 Migrate 0 0.9 0 0.8 0.96 Test 0 0 0.9 0 0.9

88

In this scenario, because of the characteristics of different tasks, We should use different method to deal with the tasks, either manually or automatically, with the help of tools, such as configuration discovery tool, or UCM. And some tasks, e.g. collection, will only involve binary level information. Therefore, we characterize the task in Table 7.
Table 7.Trade6 Migration Task Description Size (CI) Auto Level Productivity (CI/Day) Collection 7 Manual 1 Plan 7 Manual 1 Discover 143 Auto 1000 Design 143 Manual 8 Map 143 Maunal 8 Provision 3 Auto 1000 Migrate 140 Auto 1000 Test 143 Manual 2

Notes: CI=Configuration Items Taking Collection as example


E Collection = E s (TCollection ) Ps (TCollection ) + ( E f (TCollection ) + E (T0 )) (1 Ps (TCollection )) = 7 7 1 0 .9 + ( + 0) (1 0 .9 ) 1 1 2 = 6 .65

And furthermore, the total effort would be evaluated as in Table 8. Table 8.Trade6 Migration Effort Estimation Size (CI) Collection 6.65 Plan 7.63 Discover 0.29 Design 17.7 Map 18.23 Provision 0.73 Migrate 0.17 Test 67.9 Total 119.3 That is, it is estimated that to migrate a typical 3-tier workload like Trade 6 with its middleware to the target private cloud platform requires 119.3 person-days, which is coincident with what we practice in the real case. In practice, it cost months for migrating the typical J2EE workload from physical platform to private cloud platform RC2 [33]. The migration execution through Migrate phase costs 47% of the effort, and the Test phase costs 57% of the effort.
V. Related Work

This paper aims to provide a way for cloud adopters to measure how costly the cloud migration process can be. The most relevant research is about understanding the benefit and risk of cloud migration, and estimating effort in software engineering.

A. Cloud Migration The challenges of cloud adoption or migration are beginning to attract attentions of academics. The related efforts mainly includes cloud migration automation, and cloud migration assessment. Cloud migration automation is to develop technology and tools for smoothly migrating workload from the previous environment to cloud in an automatic way, with minimal disruption and risk. For example, The UCM, an IBM migration tool, migrate configurations from source physical platform to target virtualized cloud platform automatically with transformation logics inside [25][26]. VMwares VCenter Converter aids physical to virtual migration at the image level. These migration automation tools are normally performed at one or two phases of provision, migration or configuration, supposing the migration plan has been set after assessment. The Darwin framework [16] provides an end-to-end view of migration process by integrating automation tool like UCM and discovery tool, and analysis. Cloud migration assessment is to evaluate the benefits, risks and costs of migrating IT systems to the cloud for enterprise so as to figure out the migration plan. Currently limited assessment framework and cost modeling tools are proposed. Khajeh-Hosseini et al [19] proposed a conceptual framework that tries to arrange all issues of making a cloud migration decision in a logical way. It proposed to start with a technology suitability analysis, then investigate cost of using cloud, and at the same time, analyze stakeholder impact, lastly perform responsibility modeling to identify and analyze risk. Though the modeling and analysis tools didnt developed yet at that time, their conceptual work was a good starting point to build a systematic view of cloud migration plan. Another work trying to cover all challenges of cloud migration for an enterprise is cloud computing adoption assessment model (CAAM)[20]. It aims to assist cloud adoption or migration by evaluating the organizations, its key capabilities and processes affected by migrating to clouds. It is a questionnaire-based approach, majorly the challenges and capabilities are collected in accordance of questions, and the assessment results are then conducted by interview questionnaires with the stack-holders. The work on cost modeling of cloud migration is now focusing on analyze the post-migration cost or cost saving. Klems et al. presented a framework [21] that could be used to compare the costs of using cloud with in-house IT infrastructure. Their framework was very briefly evaluated with two case studies, but no results were provided as it was at an early development stage. The cost modeling of decision support tools for cloud migration, proposed in [15], estimates and compares cost of using public IaaS clouds. It takes a cloud deployment model as a directed cyclic graph, and retrieves pre-unit price of the resource from public IaaS cloud providers like AWS, FlexiScale, GoGrid, and then calculate the cost according to the usage patterns. We presented cloud Total Cost of Ownership (TCO) modeling tool [32] by taking into account the cost factors of building and operating a cloud, such as hardware, software, power, cooling, staff and real-estate. This cloud TCO modeling tool

89

is useful for both large and small cloud providers to estimate and predict their cost spent. A few more work investigated the cost of using the cloud via individual case studies [23][24], or build the cost modeling of cloud computing from a consumer perspective [22]. However, none of them explores the cost or effort happened during cloud migration process. B. Effort Estimation Approaches Cost estimation is a serious problem for migration engineers. Actually, effort or cost estimation is an important and challenging issue in software engineering area. One of the most important objectives of the software engineering community has been the development of useful models that constructively explain the development life-cycle and accurately predict the cost of developing a software product. There is a diverse range of cost estimation approaches for software development in software engineering area. The approaches can be broadly divided into two categories: expert estimation, and algorithmic model estimation, though there have been attempts to combine these two. Expert estimation is the approach conducted by a person recognized as an expert on a task, and the estimation process is based on a non-explicit and non-recoverable reasoning process, i.e., intuition [17]. Mostly, Expert estimation doesnt have strict requirements on project data, and may has the advantage of being easy to use and flexible[29], but it requires seasoned experts each time the estimation needs to be performed. The reliability of the estimation results depends on the expertise and preferences of the experts involved. As cloud is still at its early adoption phase, there is a lack of skillful experts with special experiences of the cloud, the expert estimation approach is not applicable for the cloud migration context at this stage. Moreover, since the rationale underlying the final estimates is not modeled explicitly, expert estimation, by itself, provides hardly effective support for effective decision making. In contrast to expert estimation, algorithmic model approach estimates cost using algorithmic models to establish the underlying rationale, that is, the relationship between dependent and independent variables of the estimated effort and influential cost factors, respectively [18]. COCOMO (Constructive Cost Model)[27] is one of the bestknown formal software effort (and cost) estimation method, has a set of three modeling levels: Basic, Intermediate, and Detailed, all including a relationship between system size (in terms of thousands delivered source instructions, KDSI) and development effort. The Putnam method [28] is another algorithmic model estimation approach, which is based on an equation of staffing profiles for research and development projects. Its major assumption is that the staffing profiles follow the well-known Rayleigh distribution. One of the key advantages to this model is the simplicity with which it is calibrated. Most software teams, regardless of maturity level, can easily collect size, effort and duration (time) for projects. The major advantage of algorithmic model estimation approaches is that, theoretically, they do not require any historical data to be applied, which is more suitable for cloud

migration at this stage. Moreover, the rationale underlying the final estimates is modeled explicitly to reduce the heavy dependence on experts. However, the traditional algorithmic models such as COCOMO and Putnam were developed in the context of software development project, not for maintenance and operation project, not to mention cloud migration. Moreover, the survey of current practices regarding effort estimation [30] reveals that these traditional algorithmic models such as COCOMO are often perceived as complicated to use, requiring significant overhead. In practice, only simple algorithmic models such as linear regression based on the effort and size of projects are more applied. The effort estimation approach in this paper provides explicit and simple model, in particular considering the most relevant factors contributing to cloud migration effort, based on the insight we gained from system migration experiences.
VI. Conclusion

Enterprises are heading towards the cloud computing. To make sure the move to cloud is on schedule and within budget, the adopters need a way to estimate the effort required for the cloud migration. This paper proposed an effort estimation approach based on the elaborated cloud migration process. We suggested the task in the process is executed iteratively rather than sequentially that there is probability of each migration task. We define and describe a migration process in three phases Plan, Migration and Test. And we further argue that the workload complexity is a reflection of the number of the configuration items which needs to be moved. We leveraged the Putnam method in the cloud migration context that the effort of migration task is determined by the scale of configuration items and the capability of the migration team, which forms key parameters of the migration effort evaluation model. We explored a case study to demonstrate the approach and to show its feasibility. We take this paper as the first step of tackling the migration effort and cost evaluation problem. In future, we will extend the approach to cover the workload consolidation effort from physical to cloud; this approach will involve accommodating the different workload in the same platform. And furthermore, we will apply the method in more migration cases, perform more case studies, and optimize the effort evaluation approach.
References
[1] [2] M. Creeger, Cloud Computing: An Overview, ACM Queue, vol. 7, no. 5, pp. 15, 2009. M. Armbrust, A. Fox, R. Grith, A. Joseph, R. Katz,A. Konwinski, G. Lee, D. Patterson, A. Rabkin,I. Stoica, and M. Zaharia. A view of cloud computing.Communications of the ACM, 53(4):50{58, 2010. Liu F.; Tong J.; Mao, J.; Bohn, R. B;Messina, J.V.; Badger, M.L.; Leaf, D.M.; NIST Cloud Computing Reference Architecture, NIST SP-500292, 2011. Ed Reynolds, Charlie Bess, Clearing up the Cloud: Adoption Strategies for Cloud Computing, CUTTER IT Journal, June/July 2009,pp. 14-20.

[3]

[4]

90

James Staten ,Is Cloud Computing Ready For The Enterprise? Forrest Report, March 7, 2008. [6] Marston S., Li Z, Bandyopadhyay S., Zhang J., Ghalsasi A., Cloud computing The business perspective, Elsevier Decision Support Systems, Volume 51, Issue 1, April 2-11, pp. 176-189. [7] Sullivan, T., Nick Carr: The ways cloud computing will disrupt IT, http://www.cio.com.au/article/296892/nick_carr_ways_cloud_computi ng_will_disrupt_it/, March 2009. [8] KPMG, Exploring the Cloud: A Global Study of Governments Adoption of Cloud, March 2012, http://www.kpmg.com/Global/en/ IssuesAndInsights/ArticlesPublications/Documents/exploringcloud.pdf. [9] Subrarmanian K., Survey says scalability and costs are driving cloud adoption, June 14, 2011. http://www.cloudave.com/13515/surveysays-scalability-and-costs-are-driving-cloud-adoption/ [10] Money, not technology, drives cloud growth, IT shrinkage, May, 2012. http://midsizeinsider.com/en-us/article/cfos-driving-cloud-adoptionnot-it [11] Mckinsey Report, clearing the air on cloud computing, http://www.isaca.org/Groups/Professional-English/cloud-computing/ GroupDocuments/McKinsey_Cloud%20matters.pdf [12] MorganStanley report, Cloud computing takes off, market set to boom as migration accelerates, May 23, 2011, http://www.morganstanley.com /views/perspectives/cloud_computing.pdf [13] Alford T., Morton G., The economics of cloud computing, 2010, http://www.boozallen.com/media/file/Economics-of-CloudComputing.pdf. [14] A. Khajeh-Hosseini, D. Greenwood, and I. Sommerville, Cloud Migration: A Case Study of Migrating an Enterprise IT System to IaaS, IEEE 3rd Int. Conf. on Cloud Comp., Miami: 2010, pp. 450-457. [15] A. Khajeh-Hosseini, I. Sommerville, J. Bogaerts, P. Teregowda, Decision Support Tools for Cloud Migration in the Enterprise, IEEE 4th International Conference on Cloud Computing, 2011, pp 541-548. [16] C. Ward, N. Aravamudan, K. Bhattacharya, K. Cheng, R. Filepp, R. Kearney, B. Peterson, L. Shwartz, C.C. Young, Workload Migration into Clouds Challenges, Experiences, Opportunities, IEEE 3rd International Conference on Cloud Computing, 2010, pp164-171. [17] Magne Jrgensen, A review of studies on expert estimation of software development effort. Journal of Systems and Software 70(12): 37-60 (2004). [18] Boehm B., Abts C., Chulani, S., Software development cost estimation approaches A survey, Journal Annals of Software Engineering, Volume 10 Issue 1-4, 2000, pp177-205. [19] A. Khajeh-Hosseini, D. Greenwood, J.W. Smith, and I. Sommerville, The Cloud Adoption Toolkit: Supporting Cloud Adoption Decisions in the Enterprise, In press, Software: Practice and Experience, 2011

[5]

[20] Usman Nasir, Mahmood Niazi, Cloud computing adoption assessment model (CAAM), 12th International Conference on Product Focused Software Development and Process Improvement, 2011, pp 34-37. [21] Klems, M., Nimis, J., and Tai, S, Do Cloud Compute? A framework for estimating the value of cloud computing, Designing E-Business Systems, Markets, Services, and Networks, Lecture Notes in Business Information Processing, 22, 2009. [22] Islam S., Lee K., Fekete A., Liu A., How a consumer can measure elasticity for cloud platforms, Technical report, http://www. Sydney.edu.au/engineering/it/research/tr/tr680.pdf. [23] A. Khajeh-Hosseini, D. Greenwood, and I. Sommerville, Cloud Migration: A Case Study of Migrating an Enterprise IT System to IaaS, IEEE 3rd Int. Conf. on Cloud Comp., Miami: 2010, pp. 450-457. [24] E. Deelman, G. Singh, M. Livny, B. Berriman, and J. Good, The cost of doing science on the cloud: the Montage example, 2008 ACM/IEEE conference on Supercomputing (SC08), Oregon: 2008. [25] Kewei Sun, Ying Li, Jing Luo, Network Traffic-based Automatic optimized Migration from Physical to Virtualized Cloud Environment with UCM Tool. 2009 IEEE International Conference on Broadband Network & Multimedia Technology [26] Liang Liu, Li Ying, Qian Ma, Ke Wei Sun, Ying Chen, Hao Wang, Automatic Model-Based Service Hosting Environment Migration, IBM Research Report, RC24437, November 27, 2007. [27] B. Boehm. Software Engineering Economics. Prentice-Hall, Englewood Cliffs, NJ, 1981 [28] Putnam, Lawrence H., A General Empirical Solution to the Macro Software Sizing and Estimating Problem, IEEE Transations on Software Engineering, Vol. SE-4, NO. 4, 1978,pp 345-361 [29] Kjetil Molkken and Magne Jrgensen, A Review of Surveys on Software Effort Estimation, Proceedings of the International Symposium on Empirical Software Engineering, 2003. [30] Adam Trendowicz, Jrgen Mnch, Ross Jeffery, State of the Practice in Software Effort Estimation: A Survey and Literature Review, Proceedings of the Third IFIP TC Central and East European conference on Software engineering techniques, 2011, pp. 232-245. [31] V. Tran, K. Lee, A. Fekete, A. Liu, J. Keung, Size Estimation of Cloud Migration Projects with Cloud Migration Point (CMP), in 2011 Interntional Symposium on Empirical Software Engineering and Measurement, 2011. [32] X. Li, Y. Li, T. Liu, J. Qiu and F. Wang, The Method and Tool of Cost Analysis for Cloud Computing, In IEEE International Conference on Cloud Computing (CLOUD-II 2009), Bangalore, India, September 2009, 93-100. [33] Glenn Ammons, Vasanth Bala, Stefan Berger, and etc., RC2-A Living Lab for Cloud Computing, IBM Research Report, RC24947(W1002042) February 17, 2010.

91

Das könnte Ihnen auch gefallen