Migrating to AWS Method 4 - Refactoring, aka Cloud Native
Refactoring is the most advanced method of migrating applications to the cloud, the outcome being a cloud-native application that fully exploits cloud innovation. Depending on the starting point of the application -- how cloud-native it is to start with, and how amenable it is to adapt to cloud services -- the effort and skills required are highly variable. However, it is generally true that to successfully refactor an application you need more application and cloud skills than any other migration method.
Refactoring is cloud migration and cloud-compatibility turned up to 10.
This method transforms everything about the application: it’s components, the application code, and the data itself. It is not for the unskilled, inexperienced, nor faint of heart. It is, however, the most rewarding method in terms of long-term business outcomes because it truly exploits the pace of cloud innovation that continuously reduces cost while increasing performance, resilience and responsiveness.
This is the fifth and last in a five-part series covering the practical realities of migrating applications to AWS:
- Part 1 – A Practical Guide to Understanding the 6Rs for Migrating to AWS
- Part 2 – Migrating to AWS Method 1 – Repurchasing, aka Drop-and-Shop
- Part 3 – Migrating to AWS Method 2 – Rehosting, aka Lift-and-Shift
- Part 4 – Migrating to AWS Method 3 – Replatforming, aka Lift-and-Shape
- Part 5 – Migrating to AWS Method 4 – Refactoring, aka Cloud Native
In this post we explore the Refactoring migration method in the same consistent manner as the other three methods using the following outline:
- Defining Refactoring
- Drivers of Refactoring
- Benefits of Refactoring
- Risks of Refactoring
- How to Refactoring
- What you need to Refactor
- Refactoring Summary and Next Steps
If you want to access the whole series in one sitting, you can go get the Cloudsoft white paper:
Everything you need to know about Migrating Applications to AWS
1 Defining Refactoring
Let's look at the activities and outcomes of Refactoring to understand what it is and what it does
- Your database-in-a-VM is swapped out for not just AWS RDS, but you also break out into multiple database types such as NoSQL and SQL in the same stack.
- Code is deconstructed and decoupled to run in modern, managed cloud services such as AWS Lambda or Step Functions, aka Functions as a Service: no servers for you to manage.
There are two significant outcomes of Refactoring:
- Your cloud consumption is fine-grained and coupled to your demand: that is, your billing goes from per hour to per transaction.
- The complexity of your application increases relevant to the distance from the "non-cloud-native" ways of working, that is, if you're not used to cloud-native, it's going to be difficult.
2 Drivers for Refactoring
Typically, Refactoring is driven by a strong business need to add features, scale, or performance by exploiting the cloud -- benefits and outcomes that would otherwise be difficult to achieve in the application’s existing, non-cloud environment. That is, the old ways just don't cut it and if you stick to the old ways, your business faces an existential threat in the face of more agile competition.
If your organization is looking to boost agility or improve business continuity by moving to a service-oriented architecture and words like "micro-services" are used because there is a real benefit to the business and not just because it's cool and shiny, then this strategy may be worth pursuing - even though it is often the most expensive solution in the short-medium term.
Refactoring has the promise of being the most efficient cloud model because your app is cloud-native is will exploit continuous cloud innovation to benefit from reducing costs and improvements in operations, resilience, responsiveness and security.
3 Benefits of Refactoring
All of the benefits of refactoring are delivered in the future, the time-to-value being a function of the complexity of refactoring which is highly dependent on the application and its current environment configuration.
By turning an application into a cloud-native application it will unlock all of the benefits of the cloud more than any other migration method.
3.1 Long-term cost reduction
Matching resource consumption demand, in some cases down to per-transaction, eliminating waste, giving a better, continuous and lasting return on investment compared to less cloud-native applications.
3.2 Increase resilience
By decoupling the application components and wiring together highly-available and AWS managed services the application inherits the resilience of the cloud.
3.3 Responsive to business events
Leveraging the auto-scaling features of AWS services that scale up and down according to demand.
3.4 Exploit AWS innovation
Inherit improvements in AWS services, and be well placed to move to new services, such as a move from AWS Aurora to Aurora Serverless.
4 Risks of Refactoring
Cloud native increases the coupling between your application and AWS. To get the most AWS benefits, you have to tie your application into their higher-order services and away from EC2 instances and standard storage. This can increase the feeling of lock-in, though other leading public cloud providers offer similar higher-order services.
4.1 Lock-in
The more cloud-native your application is, the more tightly coupled it is to the cloud you are in.
4.2 Skills
Refactoring requires the highest level of application, automation and AWS skills and experience. Refactoring is not for beginners!
4.3 Time
Because refactoring is more complicated in terms of changing from a non-cloud application to a cloud-native application, it can also be the longest piece of work.
4.4 Getting it wrong
Because Refactoring requires changing everything about the application, it’s the maximum exposure to getting it wrong. Each wrong thing can cause delays, cost increases and potential outages.
5 How to Refactor
This is a highly variable activity, dependent on the current application complexity (is it a monolithic, single-threaded Ruby application with one database or a distributed Java application that has integrations to separate on-premises systems?).
During the Discovery Assessment process, it's not possible to predict how long an application Refactor will take. One could budget for three-to-six months depending on complexity and previous experience.
There are examples (see More Resources below) of people using a Platform-as-a-Service intermediary layer for making application cloud-native, rather than tying their application directly to a 'raw' cloud layer. This is a complex picture, however, as the definition of PaaS is widely varying. Examples of PaaS platforms CloudFoundry and OpenShift, but some people consider Containers as a PaaS (and others vehemently do not!).
6 What you need to Refactor
A bloody good reason and skills to do it. You will need people who understand the whole business domain where the application fits in addition to application, automation and AWS experts.
Very few migration plans have Refactor in them, it is almost like a planet in the outer ring of a solar system. A planet that is only visited by people with the resources, technology and know how to get there.
What you most need for Refactor is the reason and ability to do it, and therefore Refactor is often only found in the wheelhouses of large, niche and technology-driven companies. Uber, for example, completely rewrote their application. As have Twitter. Facebook. But all of these companies are niche, "special cases".
The only way to get cloud-native if you aren't a niche company is to leverage a partner that is special and that can get you there. Look for experience DevOps and Cloud qualified partners, they need the applications, automation and AWS skill combo to make this happen.
7 Summary of Refactor and Next Steps
Refactor is almost like the upper-class, Hogwarts alumni: the only Wizard in a migration world full of Muggles. It has huge promise and benefits, but getting there for the average isn't usually an option.
If you have never done a cloud migration, Refactoring should not be your first choice because of the deep application and cloud skills required. You can mitigate this buy finding a partner like Cloudsoft who have staff with deep application, automation and AWS skills. One of the best approaches to Refactoring is to do it iteratively over time, refactoring parts of the application and checking progress with collected data, rather than a big bang.
It wouldn't be wise for an inexperienced team to, overnight, change a monolithic web app into microservices and functions-as-a-service. Not only is this difficult and highly skilled, the operational tools and processes for cloud-native are different compared to "traditional" applications.