Moving to Cloud computing (Legacy application migration to cloud)

Huge momentum has built to migrate applications to cloud computing nowadays. There are several motivation factors to adapt to cloud:  cost savings IT infrastructure and maintenance, time to market, rapid deployment and provisioning, auto-scaling, flexible capacity, and business continuity.

Moving existing applications is not simply a matter of lifting and shifting to a cloud platform. Migration of existing applications to cloud computing must be done in a strategic and systematic manner. Identify individual business problems with existing applications that cloud computing can potentially address and provide specific business justification that the cloud is the right strategic alternative.

Enterprise applications must be thoroughly assessed to determine which application can benefit most from early migration to the cloud. Key considerations including costs of migration, application redesign, application performance and availability, security and privacy requirements, and regulatory requirements must be taken into account.  Create a pilot for one or two of these types of applications, test thoroughly, and gather customer feedback so that trust and confident can be built before going live.

The important point is that decisions about moving to the cloud need to start from an application standpoint, with a thorough consideration of followings:

Stateless: The thump of rule is keep your application from being affected by dynamic scaling: Build your application to be as generic and stateless as possible.  Avoid singleton.

Hardware dependency: Services that application calls should not be pointing particular host names or IP addresses. Abstracting environment-specific dependencies into a set of property files is still an inadequate. A better approach is to use an external service registry to resolve service endpoints like load balancer with virtual name.

Avoid local file system:  Avoid local file system as a store for temporary information, put temporary information in a remote store such as an S3, Amazon EFS, RDS or NoSQL database.

State-fullness: HTTPSession state is often stored in-memory, which presents a problem if your entire application server can be added or removed or moved at any time in the cloud. The best practice is to push it out to a highly available store that is external to your application server; that is, put it in a distributed caching store, such as  Memcached, or Redis.

Application Log Fie:  Application services are in auto scaling added/moved/removed often and storing log file in the local file system will crash your debugging option or the file you are looking for may not be available for debug. Use an open source aggregator, such as Scribe or Apache Flume, ELK or a commercial product, such as Splunk.

Asynchronous Calls: Consider that asynchronous protocols (Queue & RESTAPI) are still alive and well and can be extremely effective for cloud application programming.

Portability: Avoid OS dependency and application should be portable to any time of middleware.  Use Cygwin and Mono to port between Linux/.Net.

Closing statement:

Management should realize that every significant transition in technology has resulted in a significant rewrite or re-implementation of the technologies that businesses depend on but deep analysis and systematic approach of changing to service-oriented architecture (SOA) can make your transition smooth and success.