A Legacy Laced Cloud

The times they are a changing! And with all of the external forces driving change into organizations, plenty of internal forces are ebbing away at the status quo. I wonder is cloud the impetus for change or the reaction to the need for change? I think the answer is both, but the former is a tactical answer while the latter is a strategic answer.

Cloud helps companies in dramatic ways as proven by early adopters. The primary use case for cloud technology deployment to date has been to reduce costs within IT. A second emerging use case is the time to market benefit as cloud resources are often easier to procure, configure, and/or build solutions atop. However in the adoption of cloud we need to have a pronounced, intentional plan, especially when it comes to legacy applications.

I have witnessed situations where dropping an application to a cloud environment increases risk more than value. Not all applications benefit from virtualization: stable applications with little fluctuation in usage of resources often look identical with the single benefit being the sharing of unused resources (which may be enough of a benefit to argue for cloud). However many of the open questions when moving legacy applications into the cloud (or any alternate platform) include:

• software library support
• level of coupling (operating system, libraries, other applications, utilities, etc.)
• component versioning
• development, test, qa, and staging environment setup and certification
• test cases and automated testing
• testing of the application and its associated components and certification
• migration to production
• training of developers and testers
• update of disaster recovery plans
• update of systems management services (monitoring, troubleshooting, backups, etc.)

This is the easy short list and assumes no change in functionality!

Finally lets not forget the law of unintended consequences. Something will go wrong as a result of the change that was not forecasted and is a direct result of the new architecture.

Minimizing these risks is possible through a methodical, structured migration program governed by the following concepts:

• Establish a framework - define an application framework to align redevelopment and future development with the growing capabilities of a cloud, even if only a portion of the cloud functionality is available.
• Challenge conventional thinking - there is no reason to assume clouds cannot benefit siloed applications, mainframes cannot participate in a cloud, CICS applications cannot be executed in a cloud, or that the end game is even cloud (it should be delivered value).
• Crawl, walk, run - learn from the first efforts and cascade that learning into following efforts until an optimization loop becomes part of the DNA of migration projects.
• Components or Containers - for each application determine whether its better to componentize, optimize the application for the new environment adopting a SOA model, or containeraize and keep the application isolated as a whole solution perhaps using web services to map inputs and outputs extending the reach of the application. In an earlier blog post I provide four options to handle legacy applications.
• The learning curve - architects, designers, developers, and testers will all need to relearn significant parts of their job. If internal development is a core need make sure the necessary skills are identified, quantified and present within the teams.

Legacy and cloud can coexist in many forms. The reality is many applications do not deliver enough value to justify their migration to a cloud environment. The goal should be to maximize the value delivered which means applying cloud capabilities where there is a business case to do so.