Cloud Migration Strategies: 4. Refactor, aka 'back to the drawing board'.

Refactoring involves a complete “back to the drawing board” reimagining of a workload that gives due consideration to the full set of cloud services available on the target platform.

This post will break down the refactoring method, taking a deeper look at:

• Refactoring explained;
• Drivers for refactoring;
• Benefits of refactoring;
• Risks of refactoring;
• How to refactor.

The information in this blog post comes from our Migration eBook: What everyone needs to know about migrating applications to the cloud. You can get your copy here.

Refactoring explained

Refactoring may impact every aspect of the migrating workload—architectural style, programming languages and runtimes, data representation and storage, observability and operational processes—and can require rewriting a significant fraction of the code.

It is cloud-optimisation turned up to 11: self-managed components are swapped out for higher-order AWS services; code is rewritten in a modern style, often structured as loosely coupled microservices; functionality is deployed as containers or serverless functions-as-a-service like AWS Lambda.

Data stores can be chosen to suit the different types of data. Instead of a single monolithic RDBMS for all of the application functions, an application might now consume multiple database sources including AWS DynamoDB (NoSQL), AWS Aurora (managed RDBMS) and AWS Redshift (data warehousing).

Drivers for Refactoring

Typically, this is driven by a strong business need to achieve scale, performance or agility that application cannot meet with its existing architecture. This project will take many months or even years to deliver value, but sometimes that is the correct business decision for the application.

Benefits of Refactoring

All of the benefits of refactoring are delivered in the future, this is a non-trivial method. 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.

• Long term cost reduction: matching resource consumption demand, in some cases down to per-transaction, eliminating waste.
  
• Increase resilience: by decoupling the application components and wiring together highly-available and fault tolerant AWS managed services.
• Responsive to business events: leveraging the auto-scaling features of AWS services that scale up and down according to demand.
• Simplify operations: cloud-native architectures, particularly serverless, are much simpler to operate. This is because the cloud provider handles much of the day-to-day operations, such as scaling, recovery from failures, patching, etc.
• Exploit AWS innovation: inherit improvements in AWS services, and be well placed to move to new features and services

Risks of Refactoring

Because refactoring is more complicated in terms of changing from a non-cloud application to a cloud-native application, it can take a long time before it delivers and creates business value.

• Getting it wrong: because refactoring requires changing everything about the application, it’s the maximum exposure to getting it wrong. It may be less risky to migrate first by a different method, and then iteratively refactor the application. This alternative approach gives faster user feedback.
• Skills: refactoring requires the highest level of application, automation and AWS skills and
  experience. Refactoring is not for beginners! An AWS Advanced Consulting Partner like Cloudsoft can help you avoid the pitfalls.
• Lock-in: the more cloud-native your application is, taking maximum advantage of cloud services, the more tightly coupled it is to the cloud you are in.
  

How to Refactor

This is a highly variable activity, dependent on the current application architecture and complexity: is it a monolith, is the codebase structured into separate modules or spaghetti code, is there tight coupling with the database technology with business logic inside stored procedures?

There are many resources that give advice on moving from a monolithic application to a microservices architecture, and techniques for this like the strangler pattern.

An incremental approach is recommended whenever possible. It has been demonstrated that releasing a sequence of small changes is lower risk than less frequent, “big bang” changes. This may suggest that the application should first be migrated to the cloud as a rehost or replatform, before then being refactored.

Migration Strategies Blog Series

This is post 5 of our Migration Strategies blog series. We're posting new blogs daily, each exploring a different migration strategy in more depth.

You can get a head start by downloading a copy of our Migration eBook: "What everyone needs to know about migrating apps to the cloud", which explores each of these approaches in detail.

Working with a partner like Cloudsoft

For many firms, deep knowledge of cloud platforms is not a core competency central to their mission. For them, the sheer breadth of cloud services and the nuances of different migration approaches can be hard to untangle. In such cases, working with a cloud partner can de-risk the options and accelerate the firm’s cloud adoption strategy.

Cloudsoft partners with organisations at all stages of the cloud journey: lending crucial strategy advice through the assess and mobilise phases, guiding the selection of migration methods for different workloads, and assisting with the technical planning and implementation of the migration itself. Staffed with experienced application developers, we also frequently continue to work with customers post-migration, refactoring and modernising the migrated workloads.