Announcing AWS Microservice Extractor for .NET

These days customers are increasingly looking to modernize internally developed applications. These applications could be internet facing products, which were developed as monolithic applications, or applications designed to help with internal processes. Customers seeking to modernize applications have a variety of goals that include making their applications more stable, and moving to newer technologies such as serverless and microservices.

Today we are announcing the AWS Microservice Extractor for .NET , a new tool that helps customers on their path to extract microservices from their monolithic applications; customers can leverage this tool to more easily achieve their modernization goals with a tool that assists in the extraction of microservices.

The Refactoring Process

Some customers will approach breaking up the monolith by allocating time to completely rearchitect and recreate the application. This approach is most common with smaller applications where the effort of rewriting the application is more effective then breaking up the application in to component pieces. This approach may also be taken for larger applications when the customer is performing a major upgrade, and can allocate the time and resources required to start over. In this case, the customer usually has little interest in preserving existing code.

For customers who are not opting to perform a complete rearchitect and rewrite of their applications, the development teams will often employ the strangle pattern, where pieces of the application are selected and refactored out of the monolith, leaving progressively less and less of the application behind in the monolith. Eventually all that will remain as the monolith will be the presentation layer, with all business logic migrated into microservices.

How a customer selects the target code, or domain to be refactored, will typically follow their development methodology. Some customers will opt for a “Low Hanging Fruit” approach, where the selection of functionality is determined by how easy it will be to remove candidate code form the solution. For example, a set of logging code that is called from many different places, but doesn’t rely on other code. Another approach is to refactor parts of the application as the need arises for updates or upgrades. This approach selects functionality for refactoring as the specific area needs some form of other upgrade or bug fix. With this approach, once an area of code has been identified for some other update work, it will be refactored and modernized as part of the process.

One option for code selection is to identify a particular class that contains all of the business logic necessary for extraction and base the refactoring effort using this class as a boundary. A second option is to use a particular controller in your application as the top-level construct. In this case the Microservice Extractor will remove the business logic from the controller and reroute all of the public calls to the new microservice.

The exact steps in the refactoring process will vary from team to team, but generally operates similarly to the following process model:

1. A subset of the application’s code is identified, by one of the above methods, as a good candidate for refactoring and extracting to make a new microservice.
2. Within selected application a group of classes is identified as the boundary of the microservice. This will include the candidate code, as well as additional classes that are required for the candidate code to function.
3. The application goes through a refactoring process to fix any issues that may prevent the code form being extracted.
4. The candidate code is extracted from the monolith, and packed as a new microservice. This may include packaging the new microservice as a docker container, for example, to host the microservice as a container.
5. The new microservice is deployed to a new set of infrastructure. For example, you might deploy your container and supporting infrastructure onto AWS’s Elastic Container Service (ECS).
6. You then need to refactor your original application to reroute calls from the main application to the new microservice. This process will often require several iterations as the original application is updated and tested.
7. Finally, the updated application, and the new microservice are released. The process then starts over with identifying the next candidate for extraction.

This process is time consuming and error prone, especially when it comes to refactoring your application to call the extracted service.

Introducing AWS Microservice Extractor for .NET

AWS Microservice Extractor for .NET helps to automate some of the steps in this process. The steps that have changed color to orange, or partially orange, are assisted by the Microservice Extractor.

Let’s have a look at how the AWS Microservice Extractor for .NET works on your applications:

We start from our typical Visual Studio project.

AWS Microservice Extractor for .NET assumes that you have full access to all of the source code for your solution in order to be able to not only analyze the application, but also to be able to extract the logic from the application.

Projects are onboarded through the tool.

You will select the solution that Visual Studio uses to build the application, and provide a name.

While onboarding project you can optionally provide runtime profiling data to assist in analyzing your application. If you have the AWS Porting Assistant for .NET installed on your machine, you can also optionally turn on analyzing your application for portability to the more modern .NET cross-platform environment.

Once your application has been onboarded into the tool, it will be built (using MSBuild) and analyzed.

Visualization of your application helps you to see all the classes in your application and how they relate to each other.

The view provides a way to navigate your project visually, and locate functionality to extract.

The included search functionality can assist in finding particular classes in the solution.

Using available visualization we can find nodes that are our candidates for extraction into micro services, and create groups of classes that will become part of the microservice, and exposed as end points. This process of creating groups of classes defines the boundary of the new microservice.

In this case a single node has been selected as a candidate microservice for extraction. The legend helps us to identify connections to the group, in this case the only connections are the blue arrows, which indicate only incoming connections.

If you selected the option to enable .NET Core compatibility when you imported the project, this data will be visible when you select the particular nodes.

Note, that this analysis only determines the compatibility of the selected node to be converted to .NET Core, it does not result in the extracted code being converted.

In other cases, your microservice may include multiple nodes that need to be packaged together to form your new microservice.

The microservice extractor provides multiple ways to visualize your project. The alternative views can help to identify classes my name spaces, or to find islands of functionality.

Once you have grouped your required nodes, you can use the Microservice Extractor to actually extract the logic for your nodes and automatically create a microservice out of them.

Extracting the independent microservice is accomplished using the extraction function from the visualization panel.

At this point you can choose to have the Microservice Extractor provide comments in your code about how to refactor your code to call the new microservice, or have the extraction process automatically attempt the necessary code changes for you.

Extraction of the microservice produces a new Visual Studio solution that can be used to build and deploy your new microservice.

New services contain the extracted code, ready to be built and deployed into the infrastructure of your choice. Note that the extracted code may require some additional refactoring in order to successfully build, and that the code may require refactoring before it is ready to be deployed and used.

In addition to creating your new microservice code, the AWS Microservice Extractor for .NET also creates the stubs necessary for your existing application to be able to call the microservice from your original application. This is done by creating a new copy of your project, and adding the necessary code to that project, keeping your original source code intact.

Incorporating the tool into your process

Customers can start using Microservice Extractor today, by downloading the installer here. The user guide can be found here.

In order to use the Microservice Extractor for .NET you need to meet the following prerequisites:

• MS Build available on your machine.
• AWS Command Line installed on your machine.
• An AWS profile configured with access to an AWS account.

Once installed you can open up your .NET applications that meet the following criteria:

• .NET Framework 4.7 or 4.8
• C#

Once you have extracted your first microservice using the AWS Microservice Extractor for .NET you should go back and make sure that your original application has all the calls routed away from the local functionality and to the new microservice. This can be accomplished either in the updated copy of your project that gets created as part of the extraction process, or by porting those changes back into the original project. This will follow your typical build -> Test -> Release cycle. From there, you can select your next microservice to extract.

Conclusion

The new AWS Microservice Extractor for .NET is available today to assist you in extracting microservices from your .NET monolithic applications. By using this tool, you can simplify, and accelerate your migration from monolithic applications to microservices.

AWS can help you assess how your company can get the most out of cloud. Join the millions of AWS customers that trust us to migrate and modernize their most important applications in the cloud. To learn more on modernizing Windows Server or SQL Server, visit Windows on AWS. Contact us to start your migration journey today.