Over a million developers have joined DZone.

Cloud Migration is Bigger than Image Portability

DZone's Guide to

Cloud Migration is Bigger than Image Portability

· Cloud Zone ·
Free Resource

Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.

Anand Iyengar

Curator's Note: The content of this article was written by Anand Iyengar over at the CloudVelocity blog. 

Perhaps a dozen tools have sprung up over the last ten years that allow images of apps to be migrated across data centers and now clouds. While most are well designed, thoughtful and practical for some hybrid cloud use cases, they still do not constitute cloud migration solutions for the vast majority of existing, multi-tier enterprise applications. Tools need to be more robust and powerful to easily and safely move larger apps and critical authentication services into seamless hybrid cloud operating environments.

That could be why — despite the compelling economics of cloud — most enterprise apps are still operating in the data center or in retail/wholesale colocation and not in the cloud (IaaS). Rather than take a swipe at a range of tactical tools, I would like to offer up my own view of cloud migration and its base requirements. These are not in prioritized order; I’ll leave the priorities up to the enterprise teams looking to migrate apps into hybrid cloud operating models.

Critical Cloud Migration Capabilities

1) Intuitive Configuration and Management – Any cloud migration solution should have a simple and easy to use graphical user interface for configuration and management of the application systems. It should detect as much as possible, and not require significant manual labor or filling out forms. It should first and foremost be easy to use and require minimal manual intervention.

2) Discovering and cloning multi-system and multi-tier applications holistically – The ability to bring all of the component systems of the application into the cloud together (to preserve and check the integrity of the application), can significantly reduce the possibility of error, delay and expense. This level of cohesion makes it economically viable for more apps to easily operate in the cloud as a seamless extension of the data center.

3) Blueprinting of application systems, and configuration – The ability to automatically identify application system components and parameters and corresponding configurations, is critical to cloud migration. This includes system processing capabilities, memory, storage, networking, and other required components. Without this capability tools are heavily dependent upon manual, error-prone processes. The effort required for cloud migration can go up considerably without effective blueprinting.

4) External service and dependency detection – Detection of dependencies on external systems or services, including authentication services such as LDAP, and file services like NFS are important for running enterprise applications in the cloud. Tools that do not detect external system dependencies can create the illusion of an easy migration but leave users to later discover further challenges to effective hybrid cloud operation.

5) Automatic Run-book generation and provisioning of cloud resources needed to create and run whole multi-system applications – All of the resources needed to create and run secure clones of the multi-system application identified in the application blueprint should be automatically provisioned in the cloud service. A run-book should be automatically generated and executed based on the application components and state. This capability again reduces costs and the incidence of error.

6) Automatic Conversion of Application to Run in Cloud – All of the transformations necessary to run the multi-system application in the Cloud should be automatically detected and performed on the cloud. This includes transformations necessary to run the application systems in the cloud (including kernel and library transformation, driver injection, device mapping, etc.). Again, full automation can significantly reduce cost, expense and error potentials.

7) Secure Data in Motion and Data at Rest – Encrypted data should be transmitted from the local data center to the cloud, and vice versa, securing data volumes by automatically converting them to encrypted storage volumes in the cloud. Security in the cloud should not be compromised and should be as close to the highest level of security allowed by the service provider as possible.

8) Layered Security – A cloud migration solution should allow for the creation and application of multiple layers and mechanisms of security for systems running in the cloud. For example, in AWS, this includes VPC, Security Groups, and subnets. These capabilities should be fully utilized. Image migration is not enough.

9) Continuous Application Consistent Synchronization of local changes to the cloud is also essential – A cloud migration solution should be able to synchronize changes to configuration of systems in the application necessary to run in the cloud, including network and storage, and addition or removal of systems. This also includes local system storage, storage on SAN volumes, and NAS storage as well. The synchronization should be application consistent, to avoid data loss. Continuous synchronization allows Recovery Point Objectives of minutes instead of hours. This keeps the cloud apps and services environment up to date, which is a big component of cloud-enabled disaster recovery and the most agile model for software development and test. This is also an important capability for a production environment in the hybrid cloud.

10) High Fidelity Cloning – The clones in the cloud should be configured similarly to the local systems, and not require templating or hypervisor nesting. This includes matching system configuration, storage configuration, and network configuration. CPU and memory should be similar. Storage volume sizes, and mount points should be maintained. File servers should be generated with synchronized data, and exports should match the local systems. Networking hostnames, IP addresses and subnets should be maintained. The hybrid cloud should have no artificial compromises framed by the shortcomings of existing cloud migration tools.

11) Data Center Services Automatically Extended to Cloud – Services in the data center required by the application that cannot be replicated to the cloud for security or policy reasons should be automatically extended to the cloud. Examples of this include authentication services such as LDAP. Without the automation of the migration of those services, cloud migration is again a very labor intensive and costly process.

12) Multiple Simultaneous Clones – Multiple isolated copies of the application should be able to be created and launched from a point-in-time copy of the application state. This allows creation of sandboxes to qualify and assure application integrity at any time. Sandboxes can be created and used for many use-cases such as development and testing, migration, failover, etc. This is the ideal for agile software development and seamless migration from pre-production to production environments.

The cloud migration category has been confused by the lack of consistent standards for automated cloud migration. These critical capabilities should be considered essential baseline capabilities, not luxuries for enterprise apps. If your tool or solution is missing any of these capabilities, prepare for more manual process, risks and costs than are necessary. The image of an app may move, but not enough of the app and services to fully leverage the power of the hybrid cloud. The result is higher cloud costs and a lower cloud payoff. That may likely be why the vast majority of existing, multi-tier apps have not moved to the cloud.

Join us in exploring application and infrastructure changes required for running scalable, observable, and portable apps on Kubernetes.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}