Strangler Design Pattern

The Strangler Pattern is a pattern of migrating the legacy monoliths Architecture incrementally to avoid the pitfalls of major rewrites.

Category

PlatformHub Integration

Scope - Problem

As we are migrating MobileX architecture from monolithic to a decoupled one we can't rewrite whole journeys and bring the system offline. PlatformHub's requirement is to gradually migrate legacy journeys so there is neither need to rewrite the whole code nor need to bring system offline.

Scope - Pattern Context

Migration from a legacy application system often requires heavy code rewrite processes but rather than do a complete overhaul and take the system offline, it might be possible to implement a pattern that slowly deprecates a legacy system over time while incrementally adding new functionality. The solution is the Strangler pattern. The Strangler pattern provides incremental transformation to a system and reduces larger systemic risk to smaller, discrete episodes of change. Taking small risks to achieve a goal is always better than taking a large one. Small failures are easier to remedy than large ones, hence the essential benefit of the Strangler pattern.

When to Use This Pattern

Whenever we plan to change the complete Architecture of application, it's very hard to migrate or rewrite everything from start as per new design and we can't make application offline, so Strangler pattern is the solution for such situation. The Strangler pattern involves creating a facade interface that helps developers expose those individual services and functions as they break them out from the monolith. Eventually, the code behind the facade will shrink as developers write, test and deploy new code. Rather than completely disassemble an application system and rewrite its code. This pattern offers development teams a way to incrementally update sections of code and functionality without the need to completely shut the system down. Eventually, all the services and components will be refactored to integrate with a new application system and the legacy system can retire.

Design and Implementation

High Level View

Issues and Considerations

• Consider how to handle services and data stores that are potentially used by both: new and legacy systems. Make sure both can access these resources side-by-side.
• Structure new applications and services in a way that they can easily be intercepted and replaced in future strangler fig migrations.
• At some point, when the migration is complete, the strangler fig facade will either go away or evolve into an Adapter for legacy clients.
• Make sure the facade keeps up with the migration.
• Make sure the facade doesn't become a single point of failure or a performance bottleneck.
• Requires a lot of ongoing attention to routing and network management.
• A refactor effort can get stuck in "adapter circle." Each instance of strangling an old service in favor of a new one will require special logic to accommodate the rerouting from the old service to the new service. When you have dozens, if not hundreds of services in play, this can be a lot of work.
• Requires making sure that you have a rollback plan in play for each refactored instance. If things will go wrong then you need to be able to roll back to the old way of doing things quickly and safely.

Forces and Constraints

• Every small release should have roll-back plan.
• Legacy journeys should communicate with new journeys through adapter hence direction communication is not allowed.
• After every release, remove the legacy code that could mislead the developer understanding also helps to reduce code size.

Document Reference

Read More Patterns