Introduction

This workshop is for .NET developers who are interested in restructuring their legacy application into microservices. In this workshop you will apply the strangler fig pattern to extract multiple services from a sample monolithic application and re-implement them with modern AWS services.

Microservices

Definition

Here is a definition of microservices from Wikipedia:

Microservices are a software architecture style in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. These services are small, highly decoupled and focus on doing a small task, facilitating a modular approach to system-building.

In other words, a microservices architecture is a model of developing software systems that focuses on building single-function modules with well-defined interfaces and operations. This trend has become more and more popular in recent years as enterprises look to become more Agile and move towards DevOps and continuous delivery. For more information, you can watch this Video by Sam Newman.


Why Use a Microservices Architecture

When developing applications that will grow in features over time or which need to flexibly and rapidly scale. Microservices provide an architecture that allows the number of teams to grow, and functionality to scale independently, without the bottlenecks of monolithic architectures. The table below shows the main differences between monolithic architectures and microservice architectures.


  Monolithic Microservices
Code Maintenance Large, complex code base, long dev cycles Smaller units of code
Deployments Lengthy, complicated process, often becomes the bottleneck Each service has its own roadmap and pipeline
Ownership Many developers, same codebase Smaller teams own services
Scale Difficult to scale efficiently Each service can scale independently
Tools Limited technology choices (e.g. programming language) Polyglot environment
Dependencies Tight coupling, difficult to manage Loose coupling, standardized communications

Strangler Fig Pattern

Definition

The strangler fig pattern is a code refactoring method proposed by Martin Fowler that takes an incremental approach to refactor code.

“Strangler fig” is the name of a tropical plant, which has a growing habit called “strangling”. To be specific, this kind of plant will germinate at the top of a host tree and grow downward by wrapping around that host tree. After the strangler fig plant becomes strong enough, the original support tree usually dies and the strangler fig becomes an independent plant. As Martin suggests in his blog, when you are modernizing an application, you will incrementally extract services from the original monolith application and make the extracted service work seamlessly with other parts. Since this application modernization pattern resembles the “strangling” growing habit, Martin refers to it as the “strangler fig pattern.”

Why Use the Strangler Fig Pattern

The strangler fig pattern minimizes the risk of modernizing a legacy application. It allows for incremental migration to a new system, which means you can stop at any step during the modernization and the application will continue to work properly. Also, if you find something is wrong in a certain extracted service, you can easily revert that step and use the legacy app to serve those requests.

How to Apply it

This pattern generally involves these steps:

  1. Fully understand the architecture of the legacy application and identify various bounded contexts in that app.
  2. Implement a selected bounded context as a microservice
  3. Keep the legacy app running. Then, gradually route corresponding calls from the legacy app to the new microservice until traffic is fully redirected to the new service.
  4. If the new service works fine, get rid of that legacy module.
  5. Iterate the above four steps until you either feel satisfied with your architecture or the legacy app has been totally replaced by microservices.