What are the steps involved in migrating application to cloud?

Below are some of steps which can be taken care while performing any application or database migration in cloud.

1. Identify Application and Database - Architecture and Flow

   • Check all the on-prem application functionalities

   • Majorly focuses on how the application services seamlessly working

   • Write down the requirement specification to enable decision making to application architect/cloud architect

2. Identify Application and Database – Coding Complexity

   • Application is designed in old legacy language i.e. cobol, fortran, c, c++, etc.

   • Check the code coverage and code availability and code expertise people availability

   • Consider the complexity of the application code

   • Consider how data communication happens in current application

   • Consider how much security features covered in current application

3. Discussion – Tech Team / Cloud Vendor

   • Discussion with Tech Team on Application Design and Operations

   • Draw the flow charts and application diagrams accordingly

   • Define time line to make a pilot development and deployment

   • Prepare check list for application and database

   • Identify cloud vendor i.e. AWS, Azure, GCP, OCI, etc. to approach first

   • kick off meeting with cloud vendors and choose which one to go

4. Discussion – Tech Team/Business Team

   • Meeting with Application/Tech Team Management on finalization of further approach for cloud migration

5. Finalize – Tech Stack and Operating Model in Cloud

   • Check and compare the cloud vendors Tech Solutions along with Application and Business Teams, in data, infra, reporting, etc. aspects.

   • Consider Tech Solutions based upon your application scalability, complexity, and budget to migrate and operate

   • Consider current Tech Solutions which also provides SAAS Services in cloud and identify their operating/charging model

6. Finalize – Tech Stack and Operating Model in Cloud

   • Meeting with cloud vendors i.e. AWS, Azure, GCP, OCI, etc.

   • Discuss current application checklist, application flow requirement, budgeting and all other details

   • Ask cloud vendors for their tech solutions - use cases and service model

   • Verified all aspects whether its fulfilled by cloud vendors Tech Solutions or not

   • Identify charging models of cloud vendors, long term or pay per use or any other, carefully understand charging pattern

   • Ideally choose – pay per usage resource charging model

7. Empower – Tech Team / Migration Team

   • Identify or gather Tech Talent based on Cloud Vendor Tech Solutions and make a migration team responsible for migration in cloud

   • Provide training to inhouse teams on Tech Solutions

   • Partner with Cloud Vendor on training services offered by them to upskill our teams

   • Migration team should have more than 2 Architects (Cloud / On-Prem)

   • Provision a Migration Team Lead to supervise – guide team on migration activities

8. Standards – Migration/Cloud

   • Validate earlier prepared check list for application and database with cloud

   • Choose Agile/Scrum/Kanban Model to track migration process

   • According to me, big bang approach is not suitable for migration

   • Divide application based on most used to least used functionalities, if possible

   • Leverage any IaC Tool i.e Terraform, OpenTofu, Pulumi, etc.

   • Consider hybrid approach to create Network connectivity, DNS, Load balancing, etc.

   • Security/Identity and Access (IAM) configs and group/pool level access in cloud

9. Execution – Pilot / POC

   • Perform Pilot / POC with cloud vendor by Migration Team using IaC Tool

   • Test at least 2-3 application flows

10. Standards – Define Strategies

    • Migration Team responsible for defining Enterprise-wide standards for application/database migration, along with environments to create in cloud

    • Define strategies for load balancing along with Automated Stress Testing along with HA of application/database in cloud

11. Migrate – Business/Application/Tech/Migration Team

    • Obtain Management Approvals, upon successfully execution of Pilot/POC of the application

    • Migrate other workloads in cloud

    • Create and Validate DEV first, then QA, TEST and PROD will be last with no manual changes allowed in cloud resources

12. Perform – BACKUP/DR

    • Consider BACKUP and DR as well for Application and Database workloads

    • Define Storage retention policies in cloud

    • Test BACKUP and DR at least once in cloud after every 4-5 Months/ 2-3 times in a year

13. Optimize – application/database

    • Implement performance optimization techiques, caching, memory storage, etc. at database/application level

    • Increase network bandwidth, machine size, disks, if required

    • Add more metrices to monitor performance

what are the application deployment strategies?

 1. Recreate Deployment

“Version 1 is down and version 2 is rolled out on Version 1”

Recreating deployment terminates all the pods/applications and replaces them with the new version. This can be useful in situations where an old and new version of the application cannot run at the same time.

 

Users experience some downtime because we need to stop the application before the new version is running. The application state is entirely renewed since they are completely replaced. if we do decide to roll back, it may cause even more downtime.

 

2. Rolling Deployment (Ramped OR Incremental Updates OR rolling updates OR rolling upgrade)

“Version 2 is slowly in phased rolled out and replacing version 1”

Rolling deployment strategy involves updating the software version in a phased manner, typically by deploying to a subset of servers at a time. This allows for incremental updates and minimizes the impact of any potential issues.

 

If a problem is detected, it can be addressed before moving on to the next set of servers. This strategy ensures a smoother deployment process and reduces the risk of downtime. After replacing all instances of the older version, it will be shut down by Ops/Dev team. After that, the new version is in charge of all production traffic.

 

Rolling deployments are the default Kubernetes (k8s) cluster offering designed to reduce downtime to the cluster. A rolling deployment replaces pods running the old version of the application with the new version without downtime.

 

3. Shadow Deployment

“Version 2 receives real-world traffic alongwith version 1 and doesn’t impact the response.”

In this deployment strategy, developers deploy the new version alongside the old version. However, users cannot access the new version immediately. The latest version hides in the shadows. To test how the new version will handle the requests when live, developers fork or copy a copy of the old version to the shadow version.

 

As a result, the Ops/Dev Team should be careful to ensure that the forked traffic does not create a duplicate live request since two versions of the same system are running simultaneously.

It's expensive and complex to set up, and it can create serious problems. Shadow deployment allows engineers to monitor system performance and conduct stability tests.

 

4. A/B Testing

“Version 2 is released to a specific subset of users under specific condition to test and validate.”

A/B testing is a deployment strategy that involves deploying two different versions of the application simultaneously to different user groups. New version is only available to a limited number of users, who are selected according to certain conditions and configuration parameters. UI UX settings, Request type, location, device type, and operating system can serve as parameters for selecting these users.

 

By measuring the performance and user feedback of each version, Ops/Dev teams can gather valuable data to follow proper decision making procedures for the management. The use of real-time statistical data can help developers make informed decisions about their application. However, A/B testing is difficult to set up and requires a high-end load balancer and robust infrastructure.

 

This strategy allows for data-driven optimization and helps ensure that only the most effective features or changes are rolled out to all users.

 

5. Blue-Green / Red-Black Deployment

“Version 2 is released with Version 1, after testing passed, traffic is switched to version 2.”

The Blue-Green / Red-Black deployment strategy involves maintaining two identical production environments, one currently running (blue/red) and one inactive (green/black). Stable or older versions of the application are always blue or red, while newer versions are green or black.

 

When a new version of the application is tested and ready, it is deployed to the green/black environment. Once the new version is tested and verified, the load balancer automatically switches traffic from the older version to the newer one, a smooth transition is made to routing traffic from the blue to the green/black environment, minimizing downtime and ensuring a seamless user experience.

 

In addition to offering a quick update or rollout of a new application version, this strategy has the disadvantage of being expensive since both the new and old versions must run simultaneously. Dev/Ops team, mostly use this method in mobile/web app development and deployment.

 

6. Canary Deployment

“Version 2 is released to a specific subset of users, then proceed to a full rollout on success.”

Canary deployment strategy involves deploying a new version of the application to a small subset of users or servers, known as canary groups. For instance, at a certain stage in the process, 90% of production traffic may still go through the older version while only 10% goes through the newer one, the team responsible for deployment gradually redirects traffic from the older version to the new one.

 

This allows for early testing and feedback. If the new version performs well, it can gradually be rolled out to the rest of the users or servers to achieve reduced risk of rollback.

 

Canary Deployments strategy reduces the risk of widespread issues and allows for rapid rollbacks if necessary.  It enables better performance monitoring, faster and easier application rollbacks, and facilitates automation in the deployment pipeline. However, it has a slow deployment cycle, requires more time, and demands a robust infrastructure.

This approach allows Dev/Ops Teams to evaluate the stability of the new version by using live traffic from a subset of end-users at varying levels throughout production.