Refactor, Rebuild and Reinvent

When you refactor/rebuild, you’re essentially changing the way an application is architected and developed by employing cloud-native features. Refactoring and rebuilding is driven by strong business needs to add features, scale, or improve performance that would otherwise be difficult to achieve in the application’s existing environment.

Before we begin, it is important to understand the difference between refactoring and rebuilding. While refactoring means keeping most of the code the same and only changing 10-20% of it, rebuilding is when you change 80% of the code.

Rebuilding requires more effort but also provides more benefits when it comes to becoming cloud-native and further enhancing the innovation flywheel.

In this blog, we discuss all you need to know about refactoring and provide you with tips and resources that will help you refactor smoothly and successfully.

Reinventing your business

Keeping the main goal of digitally transforming your business in mind, refactoring and rebuilding is when you truly become a software expert within your organization. Built on the same principles as AWS re:Invent, the biggest cloud computing conference in the world, refactoring & rebuilding follows the philosophy that any company can reinvent itself and leverage the scalability of the cloud.

This approach means that you’re moving into the digital economy and reinventing your business in the digital age. At this stage, cloud computing becomes more than just about saving money in the long run, it becomes deeply connected to your organization’s core values, long-term goals and driving factors. While refactoring is an easier place to start the digital transformation journey, some applications are not suited to be refactored and would have to be rebuilt. Both, refactor and rebuild, allow you to enhance existing customer experiences and build new services.

This is where you need to ask yourself what your business model is and if you’re ready to put in the work to commit to this modernization strategy. To do this, let’s start with why we might choose to refactor or rebuild an existing software system your company owns or uses. For this we need to understand the difference between a monolith and a microservice software architecture.

Refactoring 101: Monolith vs microservices

A monolith, which is a traditional model of a software program, is built as a unified unit that is self-contained and independent from other applications. Most software systems today are considered monolithic in how they were built simply because the alternative, microservice architecture, has only been around for a few years.

When refactoring on AWS, a monolith is broken into many different microservices which are tiny services hosted on AWS that run your business. The benefit of microservices is that they can be deployed in different cycles to make small, incremental changes. With microservices, you no longer need to have big bang releases where everything is deployed at the same time and there is a higher risk of things going wrong.

Microservices include the same features and functionality as a monolith but are composed of tinier programs that can communicate with each other and work together to achieve the same goal. Using microservices helps isolate the problem areas so you can quickly remediate any issue that occurs. Moreover, they’re smaller than a monolith so you don’t need big teams to work on them and can easily establish a pragmatic culture of agile working.

Using Domain Driven Design

A common question customers ask is how to scale up a microservice architecture from hundred microservices, for example, to a thousand or even tens of thousands. The key is to use the principles of Domain Driven Design laid out decades ago.  

The most important benefit of using Domain Driven Design is that it ensures that naming stays consistent across all your coded microservices as well as on the business and consumer side of things. For example, a bank uses terminology like accounts, balances, payees, etc. and, through Domain Driven Design, you can use the same language when building out your microservices. A naming convention is a simple design feature you can implement to identify and separate your microservices without causing any overlap, confusion or, what is professionally known as, microservice spaghetti.

Tips, tools and next steps

We’ve come up with a list of tips, tools and next steps to guide you through the refactoring journey.

Tips:

• Before beginning to refactor, go through an in-depth assessment and discovery process with your team to assess all the services you will need to achieve your business goals.
• While refactoring on AWS, it’s important to have an expert AWS architect on the team to help map out all the components according to your unique existing systems and business needs.
• When creating microservice architectures, make sure to invest in DevOps and automation as every dollar invested in DevOps pays across all the teams at your organization.
• Establishing coding standards is a good practice because you need to have a technology stack identified and key frameworks fleshed out for developers who will be using them. Coding standards ensure you scale up smoothly and don’t end up with a pile of spaghetti code that no one can understand or maintain.

Tools:

• AWS Refactor Spaces acts as a starting point for incremental application refactoring to microservices in AWS and is a useful tool when refactoring.
• By using the AWS Well-Architected Framework, as discussed in our blog, you can create a microservice architecture and build out your entire modernization process.
• Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans is a great resource as it talks about how to build out software systems, principles of microservices, and the importance of using Ubiquitous Language. 

Next Steps:

Perhaps the most important thing to keep in mind is that to successfully refactor/rebuild, you first need to establish a solid cloud foundation. Our next blog lays out what makes a good foundation on AWS and how you can achieve one.

Already have a cloud foundation in place? Keep an eye out for our next blog for more information on how to refactor using AWS Refactor Spaces. Remember: moving forward through the modernization process takes grit and courage. Are you ready for the challenge? Let’s get started building out your cloud foundation.