Refactoring in AWS

Refactoring is a significantly more complex method of adjusting and migrating an application for the cloud.  This method is more directly intended for mainframes that are much more antiquated and that the architecture needs to change much more drastically to have access to the benefits of AWS.  Additionally, this is for more monolithic applications that require greater care during migration.

A More In-depth Overhaul

Refactoring (sometimes called “re-architecting”) as detailed in our main article is strongly recommended for businesses that need to drastically optimize application architecture for the cloud.  This includes a lot of older parts just being replaced, including rewriting old code, replacing otherwise self-serving services with their AWS equivalents, and some functionality that could be replaced with either containers or serverless functions-as-a-service.  There is a fairly generous upper limit to the number of data storage services available to developers who want to bring over existing workloads.

Why Consider Refactoring?

Not every application still running in legacy or physical infrastructure can be ported over to AWS easily.  Sometimes, the architecture an application was designed for is now so old that it will require extensive retooling of the architecture to be compatible.  The transition to the cloud could take months or a year, but it is a good decision to allow for continuous optimization of software that is locked to legacy limitations.  The main risks of refactoring are poor execution over the course of just how long this process can take.

 

Long-term Cost Savings

Compared to legacy systems, resource consumption can be more easily limited to physical demand.  This is especially good for certain business events or more expected times of the year when traffic is expected to see a surge.  On the cloud, new computing and storage resources can be easily acquired and retired when they’re done being used.

Better Application Stability

On the cloud, connection is expected to be overall more stable compared to physical infrastructure.  Through AWS’ regional presence, the application can be allocated locally within certain continents or countries to offer the best latency to expected customers.  Should a cloud server go offline, there are more than enough contingencies in place to ensure that if an application or its server fails for whatever reason, it will experience as little downtime as physically possible.

Simplified Business Operations

AWS’ primary feature is the simplification and self-management of much of the overhead operations.  Through AWS, many of the more common maintenance tasks are simply automated.  Scaling, patching, recovering from failures, and monitoring user activity are all by default basic features of AWS and its various services.

Faster Innovation

The AWS Cloud catalog of services and features is long and vast in what it can provide in terms of functionality.  Based on the needs of the company or application, developers can continue to tinker with the application’s architecture to best accomplish business objectives.

Preparation

During this stage, clients will be working with certified AWS experts such as ourselves.  They will review the pre-confirmation app questionnaire the client has filled out and further interview the application owners to validate server inventory.  Along with the original application developers, we will be thoroughly evaluating the application for what needs to be changed to improve performance.  As they continue to evaluate the application, they will conduct the following:

• • Validation of the network and storage dependencies/requirements
  • Ensure high availability and disaster recovery (HA/DR) for data works
  • Evaluating what needs to be replaced and begin preparing corresponding AWS services to match
  • Put together a diagram of the application in the current state
  • Acquire server information and server groups
  • Add any missing server details
  • Code and data refactoring
  • Prepares a map of the infrastructure applied to the target AWS instances

Migration

In preparation, the Application Migration Service Refactor Spaces will help developers through this process incrementally.  Our specialists will need a running list of all dependencies and inbound/outbound network ports and access to generate all the balancer requirements, firewalls, subnets, and security groups at the AWS landing zone.  Meanwhile, the application’s QA team will need to prepare test scenarios to run the application through once the migration is done to check dependencies.

It’s important to have backup strategies derived before the migration to rollback in case of disasters mid-migration.  In short:

• • Create the cutover runbook document and validate it with stakeholders - everyone will want to know
  • Validate the Application Migration Service blueprint, tag information, Domain Name Service (DNS), and security groups
  • Obtain approval from stakeholders
  • Perform tests once the migration is complete.

After everything is complete, the owners will need to run some sanity checks or testing to make sure everything works according to the application’s requirements.