How: Ways to Migrate
The third piece of the puzzle is the how of the migration process. Most businesses looking to move out of their data centers or from one platform to another broadly do so in one of the following ways.
Lift and Shift (Rehost)
It is the easiest and least expensive way to migrate to a cloud platform from an on-premises setup. As the name suggests, this mode of migration involves moving your application as-is without any code modifications (shallow cloud integration). It provides the original application experience on the cloud and can use the same security mechanisms that were used on-premises. Consequently, rehosting can be effected fast or within a limited time. However, you may have to come back later to optimize the cloud solution for cost as well as performance.
When to Rehost
- If you are new to cloud computing, rehosting is an easy way to migrate to the cloud.
- It is also the most viable cloud migration strategy when you want to cut down on-premises infrastructure costs almost immediately.
- You can indeed consider lift and shift for applications that just need to be kept running without disruption or modification.
- In the face of a disaster, you can choose to rehost your applications to be up and running quickly.
As the demand for their flagship recruitment solution soared, it became necessary for our client to migrate their application infrastructure to a robust platform that offered a high level of scalability and security. They had to move urgently and without disrupting customers.
We adopted AWS cloud migration strategy, migrating their servers (live recruitment portal, testing site, and blog site) to the AWS platform using the lift-and-shift approach. Failover mechanisms and elastic computing were implemented to ensure optimal performance and better user experience. Read the full story
Cloud Native (Rebuild)
This mode of approach to cloud migration seeks to take advantage of cloud-native features such as elasticity and availability. You may need to rebuild the application or recode some portion of it to take full advantage of cloud frameworks and functionalities. As a result, the process is time- consuming as well as resource intensive but provides a mature solution. This cloud migration strategy offers a fallback option where you can implement canary deployments before transitioning in full and roll back to the old setup if any problem arises.
When to Rebuild
- When your application is old and outdated, you may opt to start from scratch since the value you get out of rebuilding it exceeds that of maintaining it.
- If you want to scale your application, add features, boost performance, or improve business continuity, you could rebuild it cloud-natively.
- You can also use this approach when you are ready to move to service-oriented or microservice architecture.
Our client wanted an IoT processing Lambda layer in the cloud. The solution had to be highly available and capable of supporting multiple deployments per day. In parallel to the solution development, the client wanted us to create the architecture for their environment in the cloud.
We designed a highly available solution based on services available on the AWS cloud, which included ELB, EC2, VPC, Subnets, RDS (Multi-AZ), and S3. To build the solution from scratch, we created Cloud Formation templates and maintained the scripts to be used as infrastructure as code. Gitflow Workflow was used for source code management. For Python, React, and Java-based apps, we created docker images to easily move the code between environments. For the remaining Spark and Scala apps, we used traditional deployment procedures.
We created Ansible playbook for each component within the tool. The playbooks would install all the various packages being used within each server in the environment. Another set of playbooks would deploy the codebase (docker and non-docker) to the respective servers. Finally, we used Jenkins to create custom jobs that could be triggered to pull the code, build the respective solution, and deploy the artifact/docker image to the respective environment.
An increasingly popular and commonly used cloud migration approach is the containerization strategy. This involves creating a container for your application that bundles together necessary components (application, libraries, configuration files) and migrating the container to the cloud. You can make use of a container orchestration mechanism to organize your containers. This approach affords portability as the container is abstracted away from the underlying OS and the infrastructure.
A small amount of up-versioning may be effected during this migration approach to take advantage of basic cloud features such as autoscaling or managed database. It may involve modifying the application, application framework, or runtime environment without making major changes to the core app architecture.
When to Containerize
- When you want to move your app to a different environment quickly and make it immediately scalable, containers help you do so.
- It is a good option if you want to cut down on development and testing time.
- Containerization approach also allows you to distribute your application across multiple environments to optimize for cost and performance.
Once the alpha phase was completed, our client required the solution to be moved out to either their cloud or a custom data center. So we created a DevOps platform for the solution. We decided to build the solution based on microservice architecture with Docker containers for each service. To host and manage these docker containers, we opted to use Kubernetes and to ensure the containers remained stateless, we followed the “twelve-factor” methodology.
This approach allowed us to easily migrate the solution between clouds and data centers. It also ensured the solution was independent of the system it was being built upon. Most importantly, since containers remained stateless, it allowed us to easily carry out multiple deployments and rollbacks on a daily basis, with minimum worry.