Strangler Figパターン

Welcome to our lesson on the Strangler Fig Pattern! This powerful architectural approach helps modernize large, complex applications without disrupting service.

Imagine a strangler fig tree: it starts as a small vine, grows around a host tree, eventually enveloping and replacing it. That's exactly what we do with software!

Many legacy systems are built as monoliths – a single, tightly coupled application. While good for starting, monoliths can become challenging:

• Slow development cycles
• Difficulty scaling specific parts
• High technical debt
• Riskier deployments

The Strangler Fig Pattern offers a low-risk way to break free.

The core idea is to introduce a new, thin application layer that acts as a facade or proxy in front of your existing monolith. All incoming requests first hit this proxy.

This proxy then decides whether to route the request to the old monolithic application or to a new, modern microservice.

The first step is to identify a small, independent piece of functionality or a 'bounded context' within your monolith that you want to extract.

Look for:

• Features with clear boundaries
• Functionality that changes often
• Areas causing scalability issues

Start small to minimize risk and learn the process.

Once you've chosen a feature, you build a completely new microservice to handle that specific functionality. This new service is developed using modern technologies and architectural best practices.

Crucially, this new service lives independently, outside the monolith's codebase.

With the new microservice ready, you update your proxy. Instead of sending all requests for that feature to the monolith, the proxy now routes them to the new microservice.

The old monolithic code for that feature is no longer used, effectively 'strangled' by the new service.

Let's say your monolith handles user profiles. You decide to extract 'Update User Email'.

1. Build a new UserProfileService.
2. The proxy checks incoming requests for /api/users/{id}/email.
3. If it's an email update, the proxy sends it to UserProfileService.
4. Other profile requests (e.g., changing name) still go to the monolith.

Eventually, all profile features are moved, and the old monolith code can be removed.

The beauty of the Strangler Fig Pattern is its incremental nature. You don't rewrite everything at once.

• Extract one feature.
• Test it thoroughly.
• Gain confidence.
• Repeat for the next feature.

This allows for continuous operation and minimizes the 'big bang' rewrite risk.

Using this pattern offers significant benefits for SaaS evolution:

• Reduced Risk: Migrates one piece at a time.
• Continuous Operation: No extended downtime.
• Modernization: New services use modern tech.
• Improved Scalability: Microservices can scale independently.
• Faster Development: Smaller, focused teams work on new services.

While powerful, be aware of potential challenges:

• Proxy Complexity: The routing layer can become complex.
• Data Migration: Deciding how to migrate data for new services can be tricky.
• Distributed Monolith: Without careful design, you can end up with tightly coupled microservices.

Planning and clear boundaries are key!

Today, we explored the Strangler Fig Pattern, a strategic way to modernize legacy monoliths into microservices.

• It uses a proxy to redirect traffic.
• Features are extracted and rebuilt as new services.
• The process is incremental, reducing risk.
• Key benefits include continuous operation and modernization.

This pattern is invaluable for evolving existing SaaS platforms without major disruptions. Keep building!