AWS Migration Hub Refactor Spaces: Getting Started

What are AWS Migration Hub Refactor Spaces?

AWS Migration Hub Refactor Spaces is a service by Amazon Web Services (AWS) that acts as the starting point for incremental application refactoring to microservices in AWS. Refactor Spaces help eliminate the undifferentiated work of building and operating AWS infrastructure for incremental application refactoring. It also helps reduce your risk when transforming applications into microservices or adding new microservices capabilities to applications. It allows customers to focus on the refactor of their applications, and not the creation and management of the underlying infrastructure that makes refactoring possible as the Refactor Spaces environment provides the infrastructure, multi-account networking, and routing that you need to modernize incrementally. Refactor Spaces bridges networking across AWS accounts so that legacy and new services can communicate while they maintain the independence of separate accounts.

By providing a structured and simplified approach to refactoring, AWS Migration Hub Refactor Spaces helps organizations transition to modern, scalable, and more manageable architectures. This transition is crucial for businesses aiming to enhance their agility, improve scalability, and speed up the development and deployment cycles. Refactor Spaces supports gradual migration, allowing organizations to modernize their applications incrementally, thereby minimizing operational risks and disruptions. 

When should you consider refactoring?

Deciding when to refactor an application is crucial for maintaining and improving its long-term performance and scalability. Here are some examples of when you should consider refactoring:

Scalability of your application is impacted

If the scalability of your application is a problem, refactoring becomes essential to ensure the system can handle increased user demands and growth effectively. Scalability issues can lead to performance bottlenecks, reduced reliability, and a poor user experience as the application struggles to accommodate more users or data. Code refactoring plays a vital role in ensuring scalability by improving the underlying architecture and design. 

Through refactoring, developers can identify and eliminate bottlenecks, optimize algorithms, and enhance performance. Refactored code also tends to be more modular and loosely coupled, making it easier to add new features, modify existing ones, or scale the application at a component level to handle higher loads. By enhancing scalability through refactoring, you can maintain a high level of performance and reliability, supporting the application's long-term success and adaptability to future demands.

Need to update to new technologies

Refactoring is crucial when organizations need to update to new technologies, as it ensures the codebase remains compatible with modern frameworks, tools, and practices. By refactoring, outdated and inefficient code can be restructured to leverage the advantages of new technologies, such as enhanced performance, security, and maintainability. This process helps in mitigating technical debt and future-proofs the application, making it easier to integrate with other modern systems and adopt new features. Refactoring from legacy codebases to more modern frameworks can also help with acquiring and retaining talent to maintain the applications. Ultimately, refactoring in this context enables organizations to stay competitive and agile, responding swiftly to technological advancements and market demands.

Technical debt

Refactoring is important to maintain the long-term quality of the code and platform of which the code is a part. If the developers don’t do some refactoring on a regular basis, technical debt will creep into the system. Refactoring can help address the inefficiencies and complexities that arise from quick fixes, outdated code, and shortcuts taken during initial development. Technical debt can lead to increased maintenance costs, reduced development speed, and higher risks of bugs and system failures. 

Refactoring allows for the systematic improvement of the codebase, replacing suboptimal code with more efficient, maintainable, and scalable solutions. By reducing technical debt, organizations can enhance the overall quality of their software, making it easier to implement new features, improve performance, and ensure long-term sustainability and resilience.

Standardization

Organizations should consider refactoring to avoid standardization problems, which can arise when multiple developers contribute their own code. Lack of standardization can lead to difficulties in maintaining and scaling the system, as well as challenges in onboarding new developers who must navigate varying styles and conventions. Refactoring in adherence to uniform standards and best practices promotes consistency and reduces complexity. This harmonization simplifies maintenance, improves code readability, and enhances collaboration among development teams, ultimately leading to a more robust and cohesive application.

What to consider when refactoring

Refactoring an application is a complex yet rewarding process that requires careful planning and execution to ensure that the changes made lead to a more robust and scalable system. Here are some considerations you should take into account when refactoring:

Monitoring and logging

The biggest challenge is trying to figure out where the monitoring & logging data is going. If there's already a centralized logging solution in place, we like to leverage that because it's comfortable & familiar, but the goal then shifts to not capturing that data from a central location, but capturing it from multiple endpoints.

You can integrate your log shipping and metric collection at the application level so that it's actually ingrained in the container or the serverless function that you're deploying, and then ship that data directly to your centralized logging and metric collector, allowing you to essentially bypass any middlemen that you have to create. In AWS, many of these services are naturally going to be shipping metrics and log data to services like Amazon CloudWatch. This makes it a natural centralized monitoring and logging solution for many customers, however inertia or featureset may keep your organization on an additional centralized logging solution; in those cases there are solutions where you can deploy an extra service that will go and collect all of the information from Amazon CloudWatch Metrics & Amazon CloudWatch Logs and then ship them to wherever you need the endpoint to go. But realistically, bypassing that and eliminating the need for additional infrastructure that you then have to manage and deploy is going to be a much cleaner approach.

Queuing and messaging

Refactoring from legacy codebases is often about embracing an architecture where everything can be completely distributed. Queuing can be a major part of that because you want messages or events to go somewhere and not necessarily be handled at the same exact time by everything. Amazon SQS is a backbone for a lot of these services and provides the core features of any Message Queue service you would expect to enable distributed application development.

There are also other message bus services in the background like Kafka or Amazon's Managed Kafka Service that you can leverage and they'll create streams of data so that other clients can pull that data out of the stream and process it asynchronously. These kinds of moves are critical so that you don't end up shooting yourself in the foot by thinking you’re refactoring into a microservices-based architecture, but actually ending up with a distributed monolith.

Strangler pattern

So how do you refactor and modernize effectively? There are some consistent application modernization patterns we're seeing, starting with one of the things that AWS came out with at AWS re:Invent 2021 - AWS Migration Hub Refactor Spaces - that makes it easy to manage the refactoring process. One of the things that Refactor Spaces is designed to do is to facilitate the strangler pattern, which is often used when you have a monolith and you want to take this thing apart, but you can't do it all at once.

When working with this pattern, you introduce a facade. Once this clean facade is built around the old monolith functionality, you can begin carving that functionality out in order to rewrite it (and only it!) safely and effectively. You may move that functionality into containers, or you might utilize a serverless approach, but now it can be treated as a microservice, and it can be managed and agile in that way. 

With the strangler pattern, you are concerned about the application layer in the interface. You are, however, still perfectly capable of shooting yourself in the foot by pointing back to one data store. So it really is about due diligence and making sure that as you’re decomposing the monolith or taking apart a legacy application, you're not just separating out the functionality but also making sure that all of the dependencies are decoupled. Going even further, sometimes we’ll see synchronous calls across dozens of services. Effectively now I've got a distributed monolith again. One of the better practices we encourage is things like queueing or leveraging a bulkhead pattern where you're making sure that you're able to short circuit some of these calls.

How Caylent can help

The other piece of that is that on Day 2, sometimes there are almost always some sort of DevOps or iterative operations and monitoring that maybe the customer doesn't want to do. Just like with AWS services, where AWS takes off the undifferentiated heavy lifting in a managed service, Caylent can also engage in what we call a Pods model, which involves ongoing service delivery, working from a shared backlog with the customer. So Caylent is equipped to help with that too. There are a lot of ways that we can also set up just for a successful Day 2 if customers want to do that on their own, however by leveraging Caylent in a “do-with” delivery model, we gain the benefit of increased velocity: Typically, when we're going to migrate & modernize a workload, a lot of automation comes along with it. Rather than doing a one time activity, like a lift & shift approach might be, the automation that we've built into the migration is going to be the same automation that's used in Day 2 operations as well.

So now we don't have a different process that was used for this one time migration event. We have a migration that's used as the first iteration of a number of successive events. The value that that brings is that the product owners are able to sort of make change faster.

Caylent Catalyst

Now, every customer is unique. They're going to have unique business objectives. But what we do see is there starts to become some commonality in the industry. Let’s consider Kubernetes. Amazon has a number of ways that you can host containers on AWS. That's a recurring pattern we have observed for customers that are coming from a virtual machine based workflow or Amazon EC2 bare metal instances. They're more comfortable with the approach of thinking about little machines. For them, what we've done is we've built a Kubernetes Caylent Catalyst that gets those people started on the right foot.

The goal of the Caylent Catalyst is to let the customers focus on the containers themselves, rather than the infrastructure and the complexity that's involved in caring for the containers, the registry, the monitoring and the other services that accompany it.

Cloud Native Application Foundation Caylent Catalyst

On the other hand, sometimes we'll have customers that come to us with what we might call a greenfield approach where they're building a new application and don’t have anything in place. 

For that, what we like to do is to steer towards our Cloud Native Application Foundation Caylent Catalyst, which sets them up to use any of AWS’s native services like AWS Lambda or managed services like Amazon RDS or Amazon DynamoDB, so that they're using modern managed services that save them from having to worry about the underlying infrastructure. They're just worrying about the code and we're helping them develop pipelines that deploy that code. So there's a lot of acceleration due to not having to worry about the legacy technical debt.

These Caylent Catalysts basically help customers get on the right path, and we offer a plethora of Caylent Catalysts, helping our customers choose the best path for their needs.

Caylent also offers custom professional services where we can develop bespoke solutions to address our customer’s unique needs. Caylent Catalysts, however, were designed to be starting points for use cases we see repeating across companies. They may not be the right starting point for every customer but they can be a great starting point for a lot of customers. And these customers may pick up from those engagements and run on their own or they may continue with Caylent and build out something that's even beyond the sort of starting point.

Next Action

If you’re interested in modernizing your legacy applications on the cloud or would like to build new cloud native applications from the ground up, Caylent’s experts are well equipped to support you. Get in touch with our team to find out how we can help!