How To Migrate To The Cloud

Transcription

1 Moving to the Cloud: Workload Migration Techniques and Approaches Joydipto Banerjee IBM Kolkata, India Abstract The paper presents an important aspect of cloud computing technology, namely migrating enterprise level workloads to a cloud environment, without re-architecting or reengineering the existing applications. How readily an application can be lifted and shifted onto a cloud platform depends on factors like nature of the application, the type of cloud etc. In this respect, the paper explores the methodology of migrations along with the challenges and issues that usually acts as a barrier for organizations trying to pursue this goal. An effort is also made to see how the cloud migration framework maps to the cloud Computing Reference Architecture model. Finally, a set of migration patterns which span the continuum from legacy IT environment to the cloud are included as a common framework for aligning the various migration approaches developed in support of using cloud as a delivery paradigm. I. INTRODUCTION Although much has been discussed about the benefits of cloud computing and the implementation details, there still exists some gap when it comes to giving a direction on how to migrate an organization s workloads to cloud environment. The skills and technology to assess the options, costs and benefits of different clouds intelligently, then make a selection and execute the move may be scant or non-existent. The paper does not delve into how to cloud-orient the existing applications such as componentizing the solution so that individually scalable components can be distributed to separate nodes allowing independent auto-scaling. Instead, the focus is more on how to move the existing applications to cloud with minimum effort. Organizations can typically be categorized into two broad groups one that have not considered moving to cloud and the other one that have already moved to cloud. The first group may be looking to transform their IT organization but may not have considered migration to cloud as part of the modernization journey, although they may very well be aware of the benefits that cloud brings. On the other hand there are organizations that have already adopted cloud but still need help to move their existing applications to the new environment. II. CLOUD MIGRATION FRAMEWORK Migrating workloads into cloud models is inherently an application centric activity where each image/instance in the cloud typically runs a single application workload. As such, moving workloads to cloud environments need to follow a multi-step process to get those applications running correctly in the targeted cloud environment. First, the targeted applications need to be identified and segregated from the other applications running on that same server. Then an image of that application, its underlying Operating System and infrastructure management agents need to be created and added to the cloud catalog. Finally, the image needs to be instantiated in the cloud environment and verified to run with acceptable Quality of Service (QoS) characteristics. The technical considerations for a migration can be summarized as: Software compatibility Reference architecture Workload characteristics Platform dependencies Across all of the migration patterns there are some common themes. These themes are described here in the context of the five phases/steps of moving workload to the cloud and form a high level reference model. Figure 1 illustrates the phases. Initial Screening and Analysis Final Testing and Go-live Planning and Design Tuning the Target Implementing the Migration Fig. 1. The Five step methodology to Cloud Migration A. Initial Screening and Analysis This involves collecting key data on existing workloads, applications and their dependencies, analyzing these data and determining probable migration candidates. Major activities for this phase are: Server Inventory Verification Gathering information on machine and OS type, collection of hardware and software characteristics, establishing a baseline. Server Affinity Analysis - Capturing server application dependency information to establish any undefined /12/$ IEEE

2 systems, constraints, complexity and establishing the appropriate migration move groups. Measuring Server Utilization - Capturing server utilization metrics to determine source to target mappings. Various methods like manual and automated data collection tools, conducting requirement workshops with stakeholders etc. are employed to get the data for analysis. Some of the important questions that are usually raised at this stage are: Will the workload run in the target cloud environment, for example, compatible infrastructure, middleware and operating system image? Will the target cloud environment satisfy performance, availability and other non-functional requirements (NFRs)? Will the target cloud environment comply with applicable security, privacy and regulatory requirements? Will benefits be realized from migration, for example, lower ongoing operating costs, or increased flexibility and responsiveness? The outcome of this phase is generally identification of workloads(e.g., Web Serving, Web applications, Business Intelligence and Data Warehouse, ERP and SCM, Analytics) suitable to be hosted in a given cloud environment, the costs involved and the migration impact. The same is usually provided in the form of Application Report. B. Planning and Design Once the inventory of targeted applications has been identified and prioritized, the logical design of the applications in cloud needs to be accomplished.this step involves detailed planning and design of the target environment(memory, processor, disk storage etc.) as per the given requirement. It includes taking key architectural decisions and hardware sizing after studying the software stacks and patterns of utilization. The rationalization criteria considered during design and planning activities are: Application Criticality, Availability / Downtime Tolerance, Migration Complexity, Application Scheduling Factors, Application to Application Interfaces, Business Constraints. Key work-products from this phase are: Detailed design of the target infrastructure A technical solution document identifying the set of remedial actions that are required to minimize the implementation risk in the subsequent steps A migration plan that identifies sequence with which applications/workloads are to be moved. The target environment is chosen such that it minimizes the amount of remediation/adjustment that needs to be done to the application stack in order to improve the likelihood of success of operation after movement. Once approval for movement has been granted, a more detailed plan is developed including pre and post migration activities, duration of any planned outage window and interlock with any dependency owners (eg. Testers for acceptance testing). C. Implementing the Migration This step is where the workloads are moved to the cloud platform using the most appropriate technique. It involves the following multi-step process: 1) Prepare the target At this stage, it is important that we have a clear vision of the target cloud environment. Depending on wheather the landing zone is a private cloud, public cloud or a hybrid cloud, the target infrastructure preparation is tailored accordingly. The level of preparation also depends on the actual migration scenario adopted(details in the next section). However the common requirement is usually building a virtual machine instance from one of the available images in the target cloud catalog. 2) Migrate - Migrating/creating images from existing workloads, or reinstalling the software stack of the existing workload on the target cloud platform. There are essentially three scenarios for implementing the actual migration: a) Like for like migration: It is the easiest and the most cost-effective way to move workloads from the non-cloud environment to the cloud environment. It usualy takes place for like-for-like environment, i.e those migrations involving Physical-to- Virtual or Virtual-to-Virtual movements with the same OS in the source and target. In this technique all of the applications running in physical servers (or in a virtual machine) are packaged up into an image and added to the cloud catalog and instantiated into a virtual machine on the cloud platform. Technologies such as VMWare Converter and Platespin are used to perform the migration from the customer s source environment to the target cloud environment. This approach will migrate the operating system, middleware, application and any customization, to the target environment in an as-is form. Due to same nature of OS and software in both the source and target, the amount of remediation or porting required in this type of migration is almost negligible. The benefits of this approach are: It is applicable for a variety of existing workloads, even business-critical and those requiring regulatory compliance Requires minimum outage window during migration Minimizes the risk of application failure after standardization and on-boarding It is mostly an automated process and thus has low and predictable costs However the drawback is that this approach minimizes the amount of standardization that is achieved and therefore some of the agility benefits of the cloud environment are obviated. Furthermore, some cloud platforms do not support the ability to import images due to technical limitations, issues with license management and bandwidth limitations that make it difficult to move

3 large software images over a network from the as-is environment to the cloud platform. b) Cross platform migration: A cross platform (e.g., Solaris to AIX, Windows to Linux) migration is usually slow and expensive but enables more business agility than like-for-like migration. This type of migration is generally complex because it involves change in hardware type (e.g, SPARC to Intel), OS type and software versions when moving from the source to target. It thus requires a thorough analysis of the application, its dependencies, compatibility of the software in the target environment etc.; code remediation, porting and test. Moreover due to application dependencies, it may involve multiple migration phases before all the in-scope applications are moved over to the target and the existing legacy servers decommissioned. On the other hand, this type of migration has the dual benefit of realising the enterprise s broader IT modernization roadmap along with adoption of cloud technology. A hardware and/or software refresh while moving to a cloud environment promises a better ROI for the organization, makes the IT infrastructure much more manageable and also makes it easier to create new business services. c) Application-only migration: Recently there are new solutions like the Zapp Migration Tool from AppZero[2] which extracts only the in-scope application from the source machine and enables it to run on the target without the need of any re-installation, reengineering or re-deployment. Various scenarios exists by which this kind of migration can be made possible. The essential mechanism by which this works is decoupling the application from its OS and encapsulating it along with its dependencies, cofiguration / registry files, services, runtime libraries into a Virtual Application Appliance. The application and its dependencies thus gets encapsulated in a virtual container, minus the source OS. This virtual container having the application can be copied over to the target and made to run with minimum reconfiguration. This type of migration promises to cut down on the overall migration duration and complexity but it still has its limitation in terms of the type of application handled and the choice of OS it is compatible with currently. 3) Data Migration - Data migration from the current environment to the target cloud environment. The tool choice for data migration is highly dependent upon the target cloud environment, the available migration window, network proximity to the source platform and level of administrative access available to the migration team. The available application downtime or the migration window is particularly an important consideration since the decision to use replication based migration tools or the traditional database migration utilities like export-import need to be taken based on that timeline. 4) Standardization - Standardizing or adjusting the created image so that it is compliant with the infrastructure management services of the cloud environment. 5) Integration - Complete integration wherever required to insure the connectivity from the moved-workload to dependent application services and data in the cloud environment. D. Tuning the Target Environment Once the customer s existing instances have been migrated to the target cloud platform, these instances have to go through an adjustment stage to configure them to the target cloud environment s architecture standards. These include: Removal of any non-standard tools and agents Applying any operating system level security patches Conforming to the target environment security policy or regulatory requirements Installation of the target cloud environment s management tools As part of the migration, the IP address of the migrated server will likely change. As such, it s possible that the configuration of the software running on the migrated instance may need to be updated with the new IP address. Similarly there may be other configuration or application specific hardcoded changes which need to be made at this stage. E. Final testing and go-live This is the final phase where it is confirmed that the migrated workload is performing as expected and the cloud platform now becomes the production environment for the migrated workload. The old source servers and images are usually de-commissioned or re-purposed after a pre-defined period of monitoring. III. MAPPING MIGRATION TO CLOUD COMPUTING REFERENCE ARCHITECTURE The Cloud Computing Reference Architecture (CCRA) [1] is intended to be used as a blueprint / guide for architecting cloud implementations. The CCRA is structured in a modular fashion and defines the fundamental architectural elements constituting a cloud computing environment. Elements of CCRA that should be considered when performing a migration are identified below: Cloud Service Consumer :: Cloud Service Integration Tools :: Change and Configuration Management :: Provisioning :: IT Service Level Management :: IT Asset and License Management

4 Cloud Service Provider :: Business Support Services :: Service Offering Management Cloud Service Provider :: Business Support Services :: Metering Cloud Service Creator :: Service Creation Tools Of course there may be other functional components of CCRA that would also be required for a migration activity. However, the above identified components are the primary ones that are almost always required for a successful migration. IV. WORKLOAD STANDARDIZATION FOR CLOUD MIGRATION Standardization is one of the key features of cloud computing and moving workloads to the cloud involves standardization and in some cases, consolidation of the source workload(s). The figure 2 illustrates the concept. Non Cloud landscape Cloud Fig. 2. Migration to cloud can result in Consolidation The non-cloud environment is usually composed of many different types of source systems, which can be categorized into the following types when considering moving onto a cloud environment: Infrastructure as a Service (IaaS) - virtualized hardware, operating system and system management tools. Platform as a Service (PaaS) - messaging, application and database, middleware management tools Software as a Service (SaaS) - business application The workload characteristics, along with the source and target cloud environments, determine the workload migration complexity and cost. Workloads can be constituted into: A. Simple workloads single application with no dependencies. E.g., HTTP servers, Groupware, small Databases. B. Complex workloads single application with many dependencies, or a group of applications that must move at the same time or extensive version upgrades included in transformation. E.g, Partitioned Databases, Disaster Recovery requirement, Korn or Shell based applications. C. Very complex workloads Third party or custom developed application with significant customization. E.g., C, C++ applications. V. COMMON MIGRATION CONSIDERATIONS A. Issues and Challenges Some of the potential issues and challenges that organizations may face while considering to migrate workloads to cloud are as follows: 1) Identifying the correct workload: This is a major challenge and involves evaluating the existing workloads on a number of parameters. A formal fit-for-purpose workshop to identify and categorize the workloads along with their target environment often helps in most cases. The various parameters taken into consideration are: Technical - security and privacy, ownership, level of customization, integration, virtualization, infrastructure, access to technical resources, etc Operational this involves factors like deployment flexibility, speed to implement, agility, migration ease, IT utilization, etc Multi-tenancy this involves issues dealing with sharing business applications with partners, scalability across multiple locations, globalization, etc Cost of Ownership/ Return on Investment 2) Security and Privacy: Data security and privacy remains one of the primary barriers to migrating workloads to cloud. Understandably, sensitive data requires protection and loss of control is not acceptable. Moreover there is usually a requirement to comply with many regulations that require data governance. Enterprises are thus reluctant to give up their control over sensitive data to service providers. Most of the risks have to do with the accessibility, use and control of data and the danger of having unauthorized access to confidential, proprietary information. A generic model for data security might not be adequate for this purpose. For example, consumers who primarily use collaboration tools and systems would focus on access and policy controls, while clients thinking of moving their healthcare applications on cloud are more concerned with data isolation and encryption. 3) Quality of Service: This is one of the major factors that comes into play when organizations think about moving to cloud. Current standards of Service Level Agreements(SLAs), prevalent in the industry might not be strong enough to gurantee uninterupted availability of running production applications on cloud. In most cases, enterprises get compensated for the amount of time the service was down but that does not cover the business loss that cloud consumers might suffer. Without proper service quality guarantee enterprises may not be ready to host their business critical infrastructure in the cloud.

5 4) Cost Savings Potential: Enterprises need to first get a feel of real cost savings before committing to put their workloads on to cloud. The return on investment (ROI), Capex versus Opex costs benefits, utilization, etc. are important considerations for an organization before investing on cloud. 5) Network Performance / Responsiveness: Cloud computing is inheirently network centric. This becomes all the more important when migrating applications on to cloud environment, since network bandwidth becomes a critical factor. Higher bandwidth ofcourse means higher costs and organizations need to find a balance between the two, when considering any cloud migrations. 6) Integration Complexity: Since most business applications are not independent and do not work in isolation, it becomes very important to understand the integration complexity when considering a migration. Possibilities include integration with existing on-premise applications, other cloud applications, up-stream/down-stream connections etc. B. General Best Practices It is very important to understand and determine the target cloud environment at the outset, since the migration strategies and planning would be guided by the choice of the landing zone. A thorough workload analysis must be done to estimate migration costs, potential benefits and identify candidates for moving to cloud. Migration must address the needs of both existing workloads as well as new workloads. It is important to understand that migration may address an entire workload or just one or more of its constituent parts. The organizational impacts of migration must be considered, especially when it is addressing consolidation during migration and those ancillary effects on other systems. VI. CLOUD MIGRATION PATTERNS Some definite patterns emerge from the commonly found repeatable migration scenarios that exist today. Some of these are described below. A. Traditional IT to Public Cloud This pattern is focused on the movement and migration of workloads from an existing, non-cloud style, infrastructure to an off-premise public cloud style environment. In this scenario there is a set catalog of target platforms which are statically defined; therefore, the movement/migration of workloads to cloud must take into consideration, the OS and platform stacks supported by the cloud service provider. In addition, the movement of workloads in this pattern will include any reengineering, updated integration and process updates which may be required to maintain expected functionality and SLAs. Choosing the right workload to migrate to the public cloud is a vitally important process to use in determining when or how to migrate an existing workload to this environment. B. Private Cloud to Public Cloud In this context a private cloud environment implies that a client s infrastructure has been configured in a private cloud style, meaning it is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units) and is on the client s premises (e.g. in their data center facility). A public cloud style infrastructure is one which is provisioned in an off-premise and open use environment exhibiting multi-tenant characteristics (e.g. meaning workloads are likely on a shared physical computing, network, and storage environment). This pattern is focused on the movement (and potential migration) of one or more workloads from the private to the public cloud environment. It s important to note that not all workloads (or workload components) need be moved to the public cloud. It s also important to note the public cloud environment may be owned, managed, and operated by the organization, a third party, or some combination of them, and it may exist on or off premises. C. Private Cloud to Hybrid Cloud A hybrid cloud combines the benefits and challenges contained in both the public and private deployment models. Most notable among these challenges is maintaining the integrity of application and data level integration as some or all of the components of a workload are migrated between environments. Thus this workload movement pattern covers the bi-directional movement of workloads between a public and private cloud deployment model and covers both full and partial migration. This is an important aspect since, in the case of partial movement, the aforementioned integration integrity will be critical to maintain. D. Public Cloud to Private Cloud This is a less traditional movement and migration pattern since there s a lot of excitement concerning the move away from a traditional environment to a cloud style environment and there is a lot of exaggerated assumptions about the guaranteed value that moving to a public model will provide. However there are times when a workload can be developed, built and tested in a public cloud environment (which does not have a focus on production level workloads) and then moved back on premise to a client s internal cloud where mission critical and/or production level applications will run. Moreover, there are many cases where an application can be tested with the need to expose sensitive information in a public model, and then be brought back on premise to complete testing with the data at full fidelity. In many cases, this workload movement and migration pattern also supports a performance testing scenario in the public venue before moving back internally. E. Public Cloud to Public Cloud This is typically expected to be transparent to the user of the cloud environment and involves a migration and movement effort to lift and move a workload between two cloud environments which are using the public delivery model. This is especially evident when a client wants to move between cloud providers, such as moving from Amazon EC2 to the IBM

6 cloud or vice versa. Considerations of platform, hypervisor, integration, data formats, and lower level IaaS dependencies must taken into account. As the cloud provider market becomes more saturated, there will be more options for clients to choose among the best price or capability offered by the service providers. F. Traditional IT to Private Cloud This is one of the more complex movement patterns as it requires several stages of movement and migration and may also require several stages of re-engineering leading to a final standardized tech stack. The primary reason for additional complexity in this pattern is because this is usually a first time cloud migration activity for the enterprise. Moreover, traditional IT environments typically have a set of custom applications in a heterogeneous technology environment with a myriad of integrations and interconnections (at the infrastructure, middleware, application and data layers). The movement of this complex environment to a cloud requires the potential re-engineering of workloads at some or all of these layers. This is because when setting up the private cloud infrastructure, the enterprise needs to maintain, if not improve, the same level of security, integration and operational efficieny that it is used to in the current traditional IT environment. VII. CONCLUSIONS Cloud computing promises a path to higher efficiency, agility, quality, security, governance and standardization in the delivery, consumption and operation of IT services, all at reduced capital and operational expense. The potential of cloud computing is, however, easily matched by the challenge and effort to transform traditional IT to a cloud model. There is no one-size-fits-all cloud, and it is up to each business to decide how much change is tolerable and to decide how far into the cloud to step. As with all journeys, planning goes a long way in reaching the destination. Taking the time to understand the different layers of cloud, to assess the suitability of applications to different clouds and to acquire whatever skills may be needed to execute the move may make a significant difference. ACKNOWLEDGMENT The author would like to thank the Business Application Modernization department of IBM for providing the opportunity to research and work on this subject. REFERENCES [1] Michael Behrendt et al., Introduction and Architecture Overview - IBM Cloud Computing Reference Architecture 2.0, The Open Group, pp , February Available: MSubmission doc [2] Introduction to AppZero. Available: [3] Joydipto Banerjee, Debasis R Choudhuri and L K Swift, Accelerate to Green IT - A Practical Guide to Application Migration and Re-hosting, developerworks, July Available: [4] Joydipto Banerjee, Real-world Journey to Your Own Private Cloud, Part 1: Prepare the concept, developerworks, July Available: