Organizations are rapidly adopting cloud technologies, but migration is still proving to be a challenge. What should you look out for? What applications make the most sense to migrate? How should applications get refactored to be cloud friendly? What are some lessons learned by those making the move? In this series of articles, you'll get practical advice from those who have experience helping companies successfully move to cloud environments. There is an area that deserves significant attention, and we hope that you'll participate in the conversation.
This InfoQ article is part of the series “Cloud Migration”. You can subscribe to receive notifications via RSS.
Many cloud providers offer services to onboard new customers into the cloud. What advice can they give us on how to prepare for a migration, and what pitfalls to avoid? To learn more, InfoQ reached out to Tim Beerman, a VP of Strategy and Development at CenturyLink.
InfoQ: What other things besides migration are part of cloud "onboarding" in your experience?
Tim: Onboarding is a very broad term that can mean a lot of different things to different audiences. In general a successful platform onboarding program will accomplish three primary goals, all culminating in a delightful customer experience that extends throughout the customer relationship. These three goals are 1) general platform introduction and expectation/goal setting (i.e. What does the customer want to accomplish through onboarding?); 2) account configuration and hands on training to accomplish the goals defined in step 1; and 3) a thorough closure session where the customer understands how to engage the platform support model and what tools and KBs are available to them for continued learning and updates. I like to use the analogy that a good onboarding program should “teach the customer how to fish” so they learn how to be self-sufficient using the self-service capabilities available to them. Of course different size customers may have different requirements based on scale of their operation, so the onboarding program should be able to accommodate as appropriate vs. a “one size fits all” approach.
InfoQ: Which aspects of migration can be faster than expected? Slower?
Tim: Obviously there are a lot of variables that come into play in a migration and it is largely dependent on the complexity of the environment. The one aspect of migrations that can often be slower than expected is the upfront planning. Many people believe that they can just pick up an image and start the migration process and turn everything up on the destination platform. There are a lot of things to consider as you start the process including such things as licensing, IP addressing, performance differences in how the exiting application may perform in the destination, etc. Careful planning and consideration of these elements up front can save a lot of time and effort on the backend. One thing that can often be faster than most people expect is the actual build-out of the destination site. If properly using available automation and tools, the general configuration goes quite quickly depending on the migration method employed.
InfoQ: Are you seeing that organizations start migrating on their own first, and then get help, or start out being guided by others?
Tim: Many customers migrating to a cloud are doing so for the self-service flexibility offered by cloud platforms. As a result, many choose to migration on their own, especially if good documentation and migration tools such as image import are readily available and easy to use on the destination platform. This gives them a great opportunity to really understand the platform which they will be operating within. That being said, this is where a strong onboarding program really shines as it provides an avenue for customers to learn the "in’s and out’s" of their new platform with some professional guidance as they get started.
InfoQ: What types of apps do you discourage a company from migrating?
Tim: Applications that have a transactional reliance on data sources (i.e. Databases, mainframes, etc.) that are not proximate to the cloud location may not be good candidates for migration. Also, some applications that are designed for physical server implementations vs. virtual are not good candidates for cloud migration as HA schemes may not work properly, performance may be impacted due to such things as storage types (FC vs. iSCSI or NFS) or licensing may not be compatible. This, of course, may not be an issue if your cloud provider offers physical servers as part of their cloud platform. (Shameless plug :) )
InfoQ: Do you typically move an entire system (e.g. web, app, DB servers) to the cloud, or just a subset? If a subset, how do you avoid negative performance impact?
Tim: This largely depends on the overall size and complexity of the environment and latency between source and destination. Whenever possible it is best to move the entire stack and if latency between locations is an issue it becomes a requirement. If latency is not a big issue and it becomes necessary to break it up then it is best to move the app and application tier first (the web tier is usually pretty straight forward) because if any problems are encountered that are not a result of the separation it is easier to fail that tier back to the source vs. re-synching the database.
InfoQ: How does your team validate that a migration was successful?
Tim: Validation is an important final step in the migration process. In fact, throughout the entire migration process, certain steps have their own validation such as checksums on data transfers for individual components. Usually, once the new environment is built out, both environments will run in parallel (one in production and the other for testing) for a given period of time to ensure the application works properly and performs as expected before the final cutover. Once satisfied, we work with the customer on a final data synchronization and cutover of the production environment while keeping the original in place for further validation period. Of course, smaller or less complex environments may not need this diligence and cutover and validation can happen very quickly. In all cases, we rely on the customer to give the “thumbs up” that they are happy in their new home and support them as necessary to make that determination.
InfoQ: How does migration to a SaaS or PaaS platform differ from moving to an IaaS environment?
Tim: SaaS and PaaS migrations have their own unique challenges, but the primary difference from IaaS is that all the hardware is abstracted so you are largely just dealing with environment configurations and data transfer. If a customer is migrating a SaaS environment they are typically going from one SaaS provider to another that provides a similar service. In this case the most complex piece is mapping the data elements from one SaaS application to another to facilitate a seamless data transfer where possible. Some SaaS providers provide tools to make this easier, especially if they are trying to capture market from one of their competitors. PaaS can be much simpler, especially if you are staying within the same PaaS framework as you switch providers (i.e. Ruby, LAMP, etc.). In this case it is largely just a data transfer, although you want to carefully consider any performance or billing differences based on your new provider.
InfoQ: What's the biggest misunderstanding that you have to address when first talking to a customer about doing a migration?
Tim: For the most part, customers go into a migration with “eyes-wide-open” since is can be an intrusive process to their business. The biggest challenge is that many customers assume that cloud is completely redundant and that if a component fails it will seamlessly be picked up by another process or virtual machine. Customers often have this impression based on how they may have built internal clouds using common hypervisors configured for those needs. When you move to public cloud platform, they are built for scale and to meet the needs of the many and as such may perform differently and handle component availability differently so expectation setting is key as the migration process begins. It many cases we recommend that customers look at their applications as part of the migration and see if it can be modified to run to take advantage cloud flexibility with features such as autoscale, geographic diversity, etc. This is not a trivial task, but educating customers on the possibilities allow them to make choices during migration or as fast follower enhancements to ensure their cloud migration will be a long term success.
InfoQ: What existing tools do most companies want to keep using when switching their apps from on-premises to the cloud?
Tim: Common tools that customers want to keep are things like their ticketing system and monitoring systems specific to their applications to minimize impact to their current operations processes. This is where it is important for customers to understand the API capabilities of their new cloud platform as they can often “program” elements of their new cloud to interact with their existing systems.
InfoQ: What technique do you see most companies use when performing a cutover? Do they accept downtime, or try techniques to stay online the whole time?
Tim: As with many things this is largely dependent on the customer application and their overall business model. Mature, “born in the cloud” companies, very often have developed their application as a distributed architecture and can often stand up new capacity on a target platform and perform a migration with very little to no downtime. While this is an evolving trend it is still the exception rather than the rule. For everyone else, it is often cost prohibitive to plan and execute a zero-down migration if the application was not built with that in mind (think IP addressing, geographic load balancing, data synchronization, etc.). That being said, with many of the tools available today it is possible to plan and execute a cutover well within established maintenance windows. Tools such as Rackware, Racemi and others allow customers to establish a relationship between each virtual machines in the target and source location and have the entire virtual machine (applications and data) replicated to the migration destination over a period of time without impacting production. The replication relationship can even be “broken” to test the application in the new location and then re-established to do a final synch before production cutover.
InfoQ: Operations departments have the (undeserved?) reputation as being blockers to adopting cloud, but is that your experience? Is there one group that is more likely to slow down a migration to cloud?
Tim: Rightfully so, operations departments are usually very protective of the application(s) they are responsible for maintaining and are wary of changes that may have an impact to their established processes, procedures, tools and expertise. Another fear that operations departments may have is that they will lose control or potentially experience job reduction as some of their current functions are no longer necessary. As such, I would not characterize them as blockers, but as a key stakeholder in the migration planning process. It is important that the operations teams fully understand how the new cloud environment can improve many of the processes they have today because of the ability to plug into robust APIs for better real-time data on their environment and even drive more automation of mundane tasks that will allow them to focus on being more proactive in supporting their business. This is, also, a great opportunity for forward thinking operations teams to learn new skills and for companies to evaluate a broader dev-ops approach to supporting their applications, but that could be a whole different interview. :)
InfoQ: What's the most complex technical challenge you encounter during migrations?
Tim: There can be lots of complexities in the overall migration process, but the most complex technical challenges arise when migrations are between dissimilar architectures. When migrating from one cloud environment to another, things are relatively straight forward since the application is typically optimized for the cloud already. You just need to account for changes in cloud implementation. The real challenges result for customers that are moving to a cloud for the first time, especially if their app is not currently virtualized. The biggest considerations typically include the following:
- License agreements for many Commercial Off The Shelf applications may be different in the cloud or not supported at all
- IP addressing in the cloud can often be different and hard coded IPs within the application could require code modifications
- Often times existing application platform components such as clustering protocols are not supported in cloud environments
- Current application to Infrastructure dependencies may need to undergo an architecture transformation for cloud deployments
- Some application platform components and underlying middleware and operating systems could have direct binding with the current server hardware platform that may need to be addressed
- Performance baselines for a cloud environment are often different and can typically be improved over existing infrastructure, however application system architecture needs to be revised to take advantage
- If moving from an on-premises data center to a cloud, user functionality and experience impacts by network latency sometime needs to be addressed by re-design of the application architecture
- Transformation of proprietary implementation of existing Load Balancers and Security Controls may need to be re-architected for the new cloud environment
- Transformation of services/systems deployment life cycle management tools and processes such as monitoring, backup and recovery, automation (config, build, patch and deploy), ITIL etc. may also need to be addressed
InfoQ: What sort of things should an organization do to make themselves "migration friendly”?
Tim: Perhaps the biggest thing an organization can to to make themselves migration friendly is to begin the process well informed and with an open mind. The first, is to be truly knowledgeable about the applications they are targeting for migration. Often times I see organization embark on a migration and they don’t fully understand all the relationships their application needs to operate effectively. This can include things like data sources, other application dependencies that are not targeted for migration and ports and protocols necessary to enable this communication. It is very frustrating for customers to start a migration and then find that it will not work as planned because of an unknown dependency. Organizations should also be well informed about the capabilities and potential limitations of their chosen cloud platform. This is not limited to just the technical capabilities, but also includes things like SLAs, billing models, how you get support and if premium support models are available and necessary to meet operational expectations. Finally, approach the migration with an open mind. Moving to a cloud platform opens up a lot of new possibilities for how a company approaches application design and future development and to do this it often requires a new way of thinking and operating. If organizations approach a migration from a perspective that EVERYTHING HAS to work just like it did before often ends up being disappointed or left wanting.
About the Interviewee
Tim Beerman is Vice President of Product Strategy and Development in Centurylink focusing on platform migration and onboarding strategy. Having joined Centurylink in 2008, Tim has held senior leadership positions responsible for world-class infrastructure products and application solutions that serve as the backbone of the company’s managed hosting initiatives. Most recently he drove the strategy to implement CenturyLink’s managed services suite of products onto the core Centurylink Cloud, laying the foundation for a broad range of future managed services under a single unified platform. Currently, Tim is responsible for developing the strategy to enable customers on the Centurylink Platform with a focus on migration from legacy products and services and building a delightful and frictionless onboarding service for new customers through core channels.
Organizations are rapidly adopting cloud technologies, but migration is still proving to be a challenge. What should you look out for? What applications make the most sense to migrate? How should applications get refactored to be cloud friendly? What are some lessons learned by those making the move? In this series of articles, you'll get practical advice from those who have experience helping companies successfully move to cloud environments. There is an area that deserves significant attention, and we hope that you'll participate in the conversation.
This InfoQ article is part of the series “Cloud Migration”. You can subscribe to receive notifications via RSS.