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.
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.
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 |
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.”
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.
This pattern generally involves these steps: