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:
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 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).
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.
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.
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.
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.
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.
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.