There has been a great deal of innovation around automated provisioning, scaling and decommissioning of cloud services in the past couple of years. The primary driver of this innovation is the ability to easily consume cloud services and pay only for the services that are being used. Creating cloud servers and appliances has become a remedial task to the end user with point-and-click provisioning being performed via slick web portals, while modern day cloud orchestration systems do the heavy lifting on the backend provisioning of the services that were ordered.
But what happens when it’s time to migrate your production workload to the cloud? Migrating your production applications into the cloud is another story all together. Many vendors are scrambling to develop and package software, positioning themselves as the “easy button” for cloud-server migration. They sell this software to other cloud providers, who then offer complementary migration services with lots of caveats, limitations and exclusions about what is, and isn’t, covered with the migration.
Five Pitfalls and Considerations of Cloud Migration:
Internet Protocol (IP) Addressing – In just about every case, a new cloud environment will have all new public and private IP networks. This adds complexity for any services that are bound to, or referencing, old networks. Web servers may no longer be able to reach their database or other dependent services because the IP address has changed. Will the cloud provider’s migration tools capture the configurations for Apache, Tomcat, IIS, etc. and rebind these to the new interfaces? Probably not.
You need a cloud partner who can develop a future-state network that is compatible with the migration plan. This network design needs to be translated and scoped to include effected-server components.
Domain Name System (DNS) – As with most external-facing services, they depend on DNS name resolution. This is typically outside the migration scope. Even after the DNS changes have been identified, these tools alone will not allow you to ‘flip the switch’ to send production traffic to the new location. Internal DNS also needs to be considered, as some providers will not allow you to have the identical server name you once had.
You need a plan of action to move to a Global DNS load-balancing service, incorporate it into your migration/cut-over strategy, and have a team capable of executing on that plan.
Firewall Security Policies – Another item typically external to host/image migration tools are those that capture, evaluate, translate and migrate firewall security policies. Depending on what type of policy is currently in place, it may be very complex and even incompatible with the target cloud provider’s network.
You need an experienced security engineer who can translate the security policy, taking into account any and all changing networks, both private and public.
Load-Balancing Policies – Complex load-balancing policies can be problematic when migrating services to the cloud because this is typically outside the scope. Do the current load balancers perform SSL offloading? If so, what tool will capture and move the SSL certificates, translate the new IP address, preserve existing health checks and predictors, and move them to the target-cloud environment?
You need a partner who has the expertise and understanding of application flow, and can develop a compatible load-balancing plan that is incorporated into the overall migration plan.
Data Transport and Synchronization (DTS) – This is the sweet spot for image migration tools, as many operate on the premise that you will be doing a one-time export of your server image. This approach works well in a dev/test environment, but is typically unacceptable for production as the data is constantly changing. If the data/ image synchronization options aren’t robust enough, this translates to a lengthy application outage during migration while people scramble to modify configuration files.
Your migration plan should incorporate several facets of data replication and synchronization. Application-level technologies should be leveraged, where possible, to allow these components to replicate as designed.
Configuration Management (CM)– With explosive growth of DevOp tools such as Chef, Puppet, SaltStack, etc., we have grown accustomed to software that can manage the application configuration on these servers. Often companies will use moving to the cloud as an opportunity to refresh these components, and to consider newer operating systems and associated applications and components. The existing configuration may need to be manually modified if it is not compatible with the newer versions.
You need a cloud partner who has the breadth and depth of services, along with the experience to identify these key components and translate the configurations for you.
At the heart of many migration tools are server-image migration capabilities. These tools center on the ability to capture disk images and export them to a target cloud environment. This approach works fairly well for basic (non-production) applications, but tends to fall short in multi-tier complex enterprise applications.
Layered Tech will partner with you to understand your business, as well as your migration objectives, timeline and budget. We will develop a migration plan unique to your business and execute it on your behalf. Hit the ground running in 2014 by letting us help you make your transition to the cloud as pain-free as possible.
About the Author: As Senior Product Architect at Layered Tech, Brian Puglisi is responsible for development of a number of product services and strategies. With more than 16 years experience in the industry, mainly at managed service providers, Brian has been delivering on-boarding solutions, and supporting customers’ cloud and IT-outsourcing initiatives with companies such as IBM and Savvis.