5WH theory of migrating application to the cloud

5WH theory of migrating application(s) to the cloud:

This post talks about how to migrate application(s) to the cloud.

1. Why to move to Cloud
2. Who will perform the migrations their skillsets
3. When will we do it
4. Where i.e. the target Cloud
5. What will move and the sequence
6. How we will migrate applications to Cloud

All the above processes involve in-depth analysis and a realization of the characteristics of each application and the associated fitment to a Cloud based infrastructure and a cloud based application delivery model. At a high level from an application migration perspective we need to understand many features of all the applications. Some aspects that need to be looked at are application & Data access, supported/tolerable latencies, and data security, compliance needs. This would then help us categorise the application as: 

•  Low hanging fruits (migration timeline being less than two weeks, simple applications like installers, websites without and backend DB etc.)
• Simple applications (Non distributed architecture, no dependency on other applications, single environment, single network zone/DMZ, hosted on independent storage, less sensitive data etc.)
• Medium complexity applications (distributed architecture but known architecture, data structures being homogenous, vendor support available, architecture details being available, single operating system, single development stack .net, LAMP etc.)
• Complex applications (highly distributed, very critical to business, 100% availability requirements, hard coded business software, highly dependent on the underlying infrastructure, complex-networking requirements encompassing multiple network zones. Highly sensitive & critical data, Mission critical applications)

We might also encounter applications that cannot be migrated for e.g. end of life applications, applications that were purchased off the shelf and the vendor is no more in the market.

The HOW part of Application migration to cloud is done by the following:

•  Elimination (Entire application is moved to Cloud and on premise hardware is released).
• Extension of the application to the Cloud. (All scaling of the application will happen in the Cloud i.e. Cloud Bursting).

This blog post will only touch upon the above points at a high level.

Application evaluation to migrate to Cloud:

Applications that were once accessed from a single of maybe multiple datacenter and having a user base that is local or over the VPN are now spread across the internet and accessing them from the internet. This forces the application to provide for

Abstraction:

No one really knows where the application is services from or where physically it is located.

Scalability:

The cloud is famous for this, and most enterprises look at this feature when they think of being “Cloud Ready”. For example websites should be able to handle 1000 hits as well as 1 Million hits without the user/customer having to wait to execute his transaction, same panache.

Distributed system:

• Global enterprises who have a user & customer base that is Global would like the applications to be served locally and not having to go under the sea to provide application access.
• An application and its architecture need to be clearly understood before moving to the cloud. First thing we need to understand is the transactions in an application. How a transaction is executed, what are the components in the application architecture that the transaction moves around and when is it complete. Now when on premise the transaction is executed completely within a closely built network system. The process is stateful and transaction is consistent. That is, the condition of the transaction is always known and the result is always accounted for. A coherent transaction either succeeds and is enacted, or fails and is rolled back.
• Now move over to the application in the Cloud and now we need the request to be decoupled from the response, because the transaction is now being executed in multiple places, the transaction is stateless. In order to create a stateful system in a distributed architecture, a transaction manager or broker must be added so that the intermediary service can account for transactions and react accordingly when they succeed or fail.
• Evaluating whether an application can be “cloud ready” would mean that we have to deconstruct the application's functionality into its components and identify which functions can be supported in the cloud.
• An application that refers back and forth to a data store very frequently has to be architect-ed in a way that the application tier is close to the data tier meaning in the same Public Cloud Datacenter or availability zone. E-Com systems are one such example.
• A complete application mapping exercise needs to be undertaken based on the applications attributes.  

Applications having the following functional attributes are good fit for the move to cloud:

• Not mission critical
• Not a core business function application
• No sensitive data
• Have the ability to tolerate high network latency & low network bandwidth.
• Are legacy applications and can be lifted & shifted.
• Is industry standard in technology and architecture?
• No need to be customized to the target platform.
• Have been there since long and have matured over time to be good enough to be moved to cloud.

This will complete studying one side of the coin; we need to understand the other side as well. This understands the attributes of a public Cloud provider.

Evaluating the Public Cloud:

Any public cloud will have the following services in their catalogue:

Here in the below list we have the Public Cloud attributes that need to be mapped to the Application attributes we arrived in the previous section in this document:

Infrastructure:

• Compute
• Network
• Security
• High Availability
• Load Balancing 
• VPN
• HPC

Platforms:

• Web Services
• DB as a Service
• Application execution engine

Storage:

• Cloud instance storage
• Data Storage
• Backup Storage

Applications:

• Software as a service

Cloud Management Services:

• Accounting
• IAM
• Migration Services
• Transactions

Conclusion:

• An application migration to cloud initiative needs to begin with a mission statement that clearly defines what the enterprise wants to achieve in their thinking to be “cloud ready”. As said in the initial section of this document we need to have the clear answer to “WHY”.
• Application migration should not be looked only from a perspective to being able to release infrastructure and data center space; rather moving applications to the cloud has larger benefits to the business. This enables the enterprise to bring its business functions closer to the customer and also widen the customer base.
• It also helps in moving from the CAPEX model to the OPEX model, and save substantially on the management of infrastructure costs.