Cloud computing is a new norm for most organizations. A 2020 survey by IDG shows that 81% of organizations surveyed have at least one application or infrastructure component in the cloud. Gartner is optimistic about this trend, predicting that cloud adoption will continue to accelerate as high accessibility provided by cloud environments is vital to support remote workers and maintain data center operations.
But to reap the benefits of cloud computing, organizations should thoughtfully prepare for cloud migration, choosing the best strategy for their particular case and the best tooling for managing infrastructure in the cloud. Gartner states that in many companies, cloud adoption decisions are made by line-of-business leaders without central IT governance. Due to this, through 2024, 80% of companies that are unaware of the mistakes made in their cloud adoption will overspend by 20% to 50% on maintenance.
The cost of mistakes made during migration is high. That’s why we want to help you through this process. Previously, we talked about the benefits of cloud migration and provided step-by-step migration instructions. This time, we want to discuss in detail strategies for cloud migration and our experience using them.
Six R’s of cloud migration
What are the 6 R’s of cloud migration and where do they come from? In 2010, Gartner published its five strategies for cloud migration. Later, AWS slightly changed this list and introduced their so-called “6 R’s”. These are six common cloud migration strategies: replatforming, rehosting, refactoring (or rearchitecting), repurchasing, retaining, and retiring. Let’s talk in detail about each strategy.
Replatforming
During replatforming, also known as “lift, tinker, and shift,” developers make several minor optimizations before migration. This doesn’t include changes to the app’s core architecture, however, as that falls under refactoring.
Yalantis experience in replatforming
We had been collaborating with a particular client for a long time, and previously we had developed a solution in the AWS cloud using cloud-native solutions like the AWS Elastic Kubernetes Service and AWS Managed Kafka.
Then our client decided to expand their business. They had a problem with the expansion, however, as the country targeted had strict laws regarding data storage and processing. All data related to citizens of the target country needed to be stored inside the country. But AWS doesn’t have a data center in that country, so we needed to find the most cost-effective and efficient solution to meet this challenge. At the time, only Oracle had a data center and cloud in the target country. So we replatformed our project to Oracle Cloud with minimal changes. All infrastructure was previously described as IaC using Terraform, which supports Oracle Cloud, so our DevOps made changes before deployment. The front end was unchanged.
We slightly changed the back end by:
-
Adopting the Oracle Email service instead of AWS SES
-
Updating the Kafka client configuration to use SASL authentication
We also adjusted our DevOps practices:
-
Changed AWS RDS PostgreSQL to a PostgreSQL primary/standby cluster in Kubernetes
-
Changed AWS Elasticache Redis to a Redis cluster in Kubernetes
These decisions made expansion possible and helped us successfully launch the project within one month.
Refactoring/rearchitecting
Refactoring implies reengineering the solution in order to create a cloud-native version of it. This strategy is the most time-consuming and costly.
But it ensures long-term cost savings by matching actual resource requirements with cloud infrastructure. Also, cloud-native apps allow companies to quickly adapt to new customer requirements, since developers can easily add or modify existing functionality.
Our case study
We used this technique when a quickly growing company operating in a highly regulated domain asked us to move their back end from on-premises hosting to the AWS cloud. They needed cloud migration services to ensure that their app could withstand high loads.
We assessed the architecture and came up with a few infrastructure improvements.
First, we decided to improve the CI/CD schema, which initially looked like the following:
With this CI/CD process, the app wasn’t dockerized, so we didn’t have library version control.
Also, manual code deployment to the Development and Production environments took significant time and was a potential source of errors.
We made the following improvements:
-
Dockerized all backend applications.
-
Automated deployment to the Development and Production environments.
-
Set up actualized, refactored integration tests to run automatically in the pipeline.
-
Integrated SonarQube for code analysis and built a project code quality dashboard.
-
Wrote documentation about the feature branch strategy and release flow for the full project.
Now, the CI/CD schema looks like this:
Architectural improvements we’ve made:
-
The actual backend design was a monolithic application with a single database, and it was the main roadblock to scalability. All features were encapsulated in one project, but the client wanted to develop a few sub-projects that would reuse the current features of the monolithic app.
-
Our solutions architects proposed a solution to split the monolithic app into reusable microservices and develop new sub-projects based on them. To decrease the deployment, operating, and cloud migration costs, we used a Kubernetes cluster managed by AWS.
The architecture we created looks like the following:
We also made some security improvements. Our client used OpenVPN for external VPN connections from developers as well as DevOps, QA, and support specialists. Each user had the same certificate for establishing a connection, so we didn’t have granular access to services by user role. Our solution was to switch to an AWS VPN with an MFA service and create different access levels for users.
During migration, we updated the backend web framework to the latest stable version; we also updated the database engine to increase performance and introduce new features for future development. Finally, our team reviewed all dependencies and removed or updated them.
As a result of our successful migration, we achieved exceptional reliability, scalability, and security, which is extremely vital for our client’s highly regulated domain. Also, we automated the deployment and rollback processes, so now they take only three minutes instead of 30.
Rehosting (lift-and-shift)
With this strategy, developers simply take system components from on-site servers and move them to the cloud without changing anything. This strategy is easier, faster, and cheaper than the previous two strategies because developers don’t need to change anything in the system. It also boasts easier compliance and security management, since apps don’t change security and compliance properties.
For most projects, however, it’s rather a short-term solution than a long-term option. The main bottleneck of using this service is the risk that apps will suffer from latency or performance challenges after migration, because they weren’t optimized or modified to fit the cloud environment.
Our experience
One of our clients wanted to expand their service to a new country, so they asked us to move an existing project without any changes to another AWS region. This should have been a classic lift and shift case. But after a deep investigation of requirements and the root cause of the move, we found a few issues that caused us not to lift and shift without reengineering.
One of the major problems was a payment provider that wasn’t supported in the country in which the product should work. To address this, we duplicated the product from one region to the new country of expansion. This caused integration issues that needed to be fixed and tested before deployment. In our experience, classic lift and shift cases are rare. In most cases, the lift and shift strategy transforms into replatforming or refactoring.
Repurchasing
You can use this strategy if you have commercially licensed software and want to switch to a SaaS solution. For instance, you can move from a proprietary on-premises customer relationship management (CRM) system to Salesforce.
Retiring
Sometimes in the process of developing an application portfolio, you find applications that you don’t need anymore or that have the same functionality as other apps you use. In this case, retiring them is the best option.
Retaining/revisiting
Sometimes, either for security reasons, due to the need for major refactoring efforts and help plan, or because of regulatory compliance, your app needs to remain on-premises. You can revisit apps of this category later, to check if they can be moved to the cloud after a while.
Before defining the cloud migration strategy to follow, you should conduct a thoughtful app portfolio analysis and choose the right strategy. If you aren’t sure which strategy to choose that will help you make the most of cloud computing, drop us a line. We offer cloud migration consulting – we’ll analyze your business processes and infrastructure to come up with a solution that fits your needs.
Ten articles before and after
How to reduce your bounce rate | hellomedia Hello Media Blog Posts blog | Telegram-Install.com
Top Reasons for Cloud Migration and Step-by-Step Instructions
Which Tool Your Logistics App Needs: Mapbox or Google Maps Platform
How to Use WebSockets in Go: A Comprehensive Guide
Full List of the Best Android App Development Tools in 2021
How to Choose the Best-Fit Tools for Logistics Software Optimization