Editor's Note: In part one of this series, contributor Tom Nolle discusses the business side of migrating applications...
to the cloud. Here, in part two, he explores technical considerations for cloud application migration.
As described in part one, companies clearly have options for validating the business case for migrating applications to the cloud. But it's just as clear that technical issues involved with cloud migrations can destroy the business case, destabilize applications and even create problems with other aspects of application performance and stability.
Application architects considering cloud migrations need to review their entire application lifecycle management (ALM) process. Beyond that, though, they should pay particular attention to managing performance and resiliency, ensuring compliance and security, and -- above all -- securing operational efficiency and stability in the cloud.
Applications that have mostly static resource commitments and are subject to change only occasionally are often deployed, redeployed and managed through largely manual processes. For example, about a third of all ALM activities use only minimal tools for deploying applications and components, while less than 15% involve the use of automated tools for testing performance and validating security. The largest single technical issue in cloud application migrations is the creation of a more agile and automated framework for ALM. Deployment is the heart of that process.
Reconsidering application models for cloud migration
Security and compliance are also issues to consider carefully in cloud application migration.
It's critical to rethink the application model for effective cloud migrations. It's no longer a software image committed to a server or virtual machine, but rather a kind of graph -- a picture of virtual components linked by virtual networking, hosted in a library of machine images and ready to be committed to resources.
That model reflects the fact that application component relationships are predetermined by the application architect, but these relationships have no real meaning until the application is deployed. To do that, the entire virtual structure must be committed to the cloud and connected via network services as a unit. Manual deployment simply can't accomplish that. The solution: Apply DevOps tools.
DevOps is a collection of open source and commercial products designed to "script" or automate deployment or redeployment of multi-component applications. Ideally, the tools will support server, network, database and even application machine image storage using a form of modularized scripting/modeling (a popular tool for Ubuntu called Juju calls these modules "charms").
Picking the right DevOps tool is critical, and there are many to choose from (other examples are Chef, Heat and Puppet). It's difficult to assess these tools out of context. Your best bet is to pick some representative applications, then conduct a trial deployment with each tool to see which offers the easiest operation, the best control and the widest range of application. You'll need to build your ALM practices for each new cloud application around this common DevOps framework.
One area where deployment tools require special consideration is in managing availability and performance through redundancy. Load-balancing and failover often require application-design-level attention to manage database integrity and assure that the performance and availability processes properly maintain context and state during switches.
These same factors typically require special attention in deployment and ALM because the decision to spawn additional copies of components is normally triggered by some management process that's monitoring response time or component availability. The connections triggering the instantiation of additional component copies must be made during deployment, and launching these new copies should be done through modules in the DevOps tool rather than with independent scripts or manual processes. Otherwise, practices may get out of sync between the baseline deployment and incremental changes.
Keep compliance, security in mind during cloud migrations
Security and compliance are, of course, critical issues to consider in migrating any application to the cloud.
It's now generally understood that encryption keys and authentication details can't be stored in machine images in the cloud unless image security is very high (and auditable). What's sometimes missed is that deployment tools that integrate components of applications in the cloud or between cloud and data center can present a security risk if the tools themselves are compromised. A contaminated deployment script can deploy a Trojan as easily as a legitimate component, so keep ALM tools for the cloud fully secure.
Internal auditors should also include the tools in their compliance audits or they risk incomplete reviews that could lead to loss of certification.
All these points intersect with the basic issue of cloud resource dynamism. The location of cloud hosts in a geographic sense, and the quality and availability of the network connections between hosts and users, can vary significantly. This can have a major impact on response time and worker quality of experience, which means that when an application is migrated to the cloud, it's important to validate the application over the spectrum of cloud hosting points where it could be run. If some provide unacceptable results, then be sure that cloud service contracts limit where the application can be run to avoid additional problems.
Resource dynamism also affects security and compliance. Application images and application data may move from place to place in the cloud, and each new site may have a different level of physical security and a different legal jurisdiction governing factors such as tax collection or the hosting of certain types of information or content. Test each of the application's assumptions for the full range of hosting locations, not just where you think the application will be run.
Be particularly careful if the cloud provider has a federation agreement with other providers to cover remote geographies or provide for additional capacity under load or to respond to failures. These agreements may not protect your core performance, availability, security, compliance or even operations assumptions, so you may need to factor federated capacity out of your equation when judging a cloud service for suitability.
Recognize cloud's unique characteristics
Technically speaking, the cloud is different than other environments. If the differences in the key areas outlined above can't be managed as suggested, that may be a big enough problem to invalidate the business case for migrating a particular application to the cloud.
If that's the case, be sure to record the issues and outcome so that applications with similar requirements can be given "guilty-until-proven-innocent" treatment in their own cloud assessments. Migrating an application when technical conditions can't be guaranteed will only hurt cloud credibility in the long run.