AWS Partner Network (APN) Blog
Using CAST and AWS Migration Hub Refactor Spaces to Modernize Legacy Applications
By Gaby Choucrallah, VP Solution Design – CAST Software
By Dinesh Raveendran, Sr. Partner Solutions Architect – AWS
 |
| CAST Software |
 |
Many organizations still rely on monolithic applications for their most critical business operations, where knowledge of the internal application structure is limited. This can lead to increased time-to-market and error-prone software updates. Simply put, adding new business functionalities and scaling the platform becomes a major hurdle for organizations.
Naturally, these organizations turn to application modernization to alleviate some of these challenges and enable them to innovate faster and remain competitive in the market. There are two approaches to modernization—the first and more risky option is a big bang where the application is completely overhauled and re-written.
A more pragmatic approach is following the Strangler-Fig pattern where you incrementally modernize the monolith over time. This means you’d have a hybrid solution for a period of time where modernized components run alongside the monolith.
To ensure a robust and low latency connection between the monolith and modernized components, organizations typically follow a two-step approach where the monolith is migrated to Amazon Web Services (AWS) first and then modernized.
This approach offers several advantages such as reduced operational expenditure (OpEx), improved app availability, and reduced complexity when refactoring. In this scenario, the monolith gets offloaded as soon as a new microservice is released, until the complete monolith is fully decommissioned or strangled.
In this post, we will discuss how to solve challenges related to transforming into a microservices architecture through recipes driven by CAST Software and AWS Migration Hub Refactor Spaces. CAST is an AWS Migration and Modernization Competency Partner and a technology provider for software intelligence that enables digital transformation.
We will focus on the challenge of monolith deconstruction, which includes activities such as monolith decoupling, database splitting, communication among services, and effort estimation. We’ll then focus on a second challenge of enabling Strangler-Fig with scalable infrastructure that facilitates traffic routing between the existing monolith, new microservices, and the end user.
For the purposes of this post, we’ll assume the monolith application is already hosted on AWS, as this a good practice to start a modernization journey to help minimize latency between monolith and new microservices.
Application Discovery
For many organizations, the software architecture of existing applications is largely unknown, irrespective of whether documentation exists. Furthermore, organizations typically find that existing documentation does not contain sufficient detail or is no longer a reflection of what’s been implemented.
Application discovery is therefore the first step on this journey. CAST Imaging is used to analyze application source code and other artefacts of a custom-developed application (extracted from source repos like AWS CodeCommit and Git.). It automatically creates a visual representation of all its components—from mobile and web interfaces down to the database and their dependencies.
In the figure below, you can see the full map of the application describing the relationships and dependencies of the various components and databases.
Figure 1 – Application map of technologies and their interactions.
The development team can navigate the architecture to understand how to better maintain portions of the system, while at the same time start to carve out functionalities that can be put into new microservices.
Visualize and Identify Interactions to Better Split Schema
Functional understanding is key to isolate components through modules (business capability, subdomain, or set of transactions). Let’s assume the monolith is a core insurance application, represented by several modules where each module is a candidate for a new microservice. You can see below the different levels of abstraction for this application.
Figure 2 – Application abstraction.
More importantly, this allows you to understand the interaction between different modules and transactions with the database to visualize CRUD (create, read, update, delete) accesses.
You can also see the external libraries that are referenced by the analyzed code, and architects can easily search for modules or objects calling or being called by those libraries.
Identify Candidate Modules for Refactoring into Microservice
The challenge is to look at all interconnections between components to see where you may have good break points. The process here is typically to identify clusters of components in a specific functional area, which can be “cordoned off” into a microservice. The impacts of that change need to be assessed, and then the project can be estimated and implemented.
The development team will start with a functional entry point (such as claims-proc.jsp) and explore all components going down the chain of that transaction, and up from the used tables.
They will look at all related areas to determine which components need to be reviewed to either, 1) include inside the microservice for that specific functional area, or 2) insert into a shared module that will handle common technical services like authentication, authorization, and logging. The next figure describes how this is visualized for the architect.
Figure 3 – Functional transaction in claims processing module.
Irrespective of the decomposition approach (per business capability, subdomain, or transaction), you can allow the visualization of interactions between the different modules that compose the monolith, and filter in CRUD accesses where the records in the SQL database are modified. Typically, this is relevant to INSERT or UPDATE queries.
Eventually, the team will be able to identify loosely-coupled transactions and figure out the first candidates to shift to new microservices. This is a pragmatic approach to implement a coherent boundary, and is bounded context in domain-driven design.
Let’s now assume in the insurance application that claims processing is the next candidate to be refactored into a new microservice. Precisely knowing the objects in the module and their attributes is key to first estimate the rewrite effort for the new microservice. In fact, attributes like number of objects, callers to and callees from other modules, their size and (cyclomatic) complexity are key to understand the work needed to implement such a service.
Aside from the coding of the new service, most of the upfront effort here is the impact analysis to understand what else needs to be accomplished to ensure consistency of data between the monolith and the new service.
Rewrite and Expose Data Through APIs
Now, it’s time the new service gets implemented by the development team using a consistent technology stack. This solution currently supports a wide range of programming languages such as Java, C#, JavaScript/TypeScript (Node.js), and Python.
The development team typically starts with business rules extraction for the service or transaction to be refactored. By sorting objects in the selected module as per cyclomatic complexity, the team can quickly identify components where business logic exists. This capability allows for a more focused investigation of the application components which saves manual trial-and-error efforts.
Figure 4 – Accelerate business rules investigation.
The development also team needs to expose data attributes, including the private schema of the microservice, through an API. Filtering in read accesses (such as SELECT queries) helps narrow down those attributes to only those that are needed by other microservices.
Once developed and tested, the service can be released on a more modernized AWS service.
Implementation
AWS Migration Hub Refactor Spaces simplifies using the Strangler-Fig pattern to effectively deconstruct a monolith into various microservices, as well as extending existing applications with new features built as microservices.
As a managed service, Refactor Spaces provides all of the necessary infrastructure for incremental application refactoring to microservices, greatly reducing the effort involved with scoping, building, and operating that infrastructure manually.
As a best practice, the solution is deployed following a multi-account approach to ensure stronger security boundaries and reduced deployment coupling. It also keeps teams independent, which limits the blast radius of one team’s service causing unforeseen outages in other services.
The diagram below shows the resources Refactor Spaces orchestrates in your accounts using the recommended account architecture. This example has an account where the old monolith lives along with a new account for new microservices.
The account holding the networking elements are held in another account and used to route traffic between the monolith and new microservices based on service endpoints. The cutover of new microservices requires configuration changes to route new endpoints accordingly and this effort is manual.
Figure 5 – Refactor Spaces reference architecture.
With the standard Refactor Spaces environment enabled for the monolith, you can now superimpose the application analysis and continuous modernization aspects of the solution.
In the diagram below, you can see a CI/CD pipeline enabled to deploy assets to both the existing monolith and the new microservices environment. In the continuous process, CAST Imaging is extracting and analyzing code changes to the repo and providing the assessment back to the development teams. These teams are now enabled to carve out microservices based on insights provided by CAST.
The new service is deployed to production environment as a new microservice (serverless or container), and subsequently Refactor Spaces is updated to enable appropriate routing to the new service.
Figure 6 – Production and development environments.
Continuous Update of Application Map
During a modernization journey or even maintenance, new business functionalities are added as new microservices or enhancements to an existing module or service.
Hence, the full map must be periodically refreshed so that a comprehensive (legacy and modern) architecture view is available. CAST would then serve as a knowledge management system for that application through its complete lifecycle.
In Figure 6 above, you can see that CAST is connected to the CI/CD pipeline and a new map can be generated whenever development of a new release is accomplished.
The team can also leverage the application map to ensure best practices are enforced, and communication between microservices is coherent.
Figure 7 – Service-to-service dependency.
Once all the services are implemented and released into the Refactor Spaces environment, the monolith can now be fully offloaded.
Conclusion
This post illustrates how CAST Software and AWS Migration Hub Refactor Spaces can be leveraged together by an organization to accelerate their ability to modernize monolith applications.
CAST Imaging empowers the development team and accelerates the discovery of the monolith by reverse-engineering the complete source code. This provides you with the full map of the application across various layers, technologies, objects, and their associated relationships. This includes the data access layer.
Refactor Spaces provides the infrastructure, security, network and associated mechanisms to deploy and host the existing monolith and the new microservices. For example, one of these mechanisms is the routing logic between modernized components and the legacy monolith.
When these two solutions are tied together using any CI/CD pipeline, the process becomes continuous in nature. Therefore, when the development team rolls out a new microservice or an update to an existing microservice, Refactor Spaces automatically adjusts the infrastructure while CAST Imaging works on providing a new application map.
To learn more, CAST has technical workshops available for Portfolio Assessment, Application Discovery, and Refactor Spaces. You may also refer to the CAST-AWS webpage and explore CAST products on AWS Marketplace.
For questions to CAST, send your request to aws.contact-me@castsoftware.com.
.
.
CAST Software – AWS Partner Spotlight
CAST is an AWS Migration and Modernization Competency Partner and technology provider for software intelligence that enables digital transformation.