The strangler pattern provides the ideal migration strategy from monolithic applications to microservices-based and composable architectures. With a low risk of disruptions and downtime and a faster time-to-value at the same time, your replatforming project no longer needs to depend on time-consuming and high-risk “big bang” migrations.
When software developer Martin Fowler visited Australia’s rainforests, he was in awe of Queensland’s colossal strangler figs. These natural wonders grow in upper branches and gradually work their way down, weaving themselves rather beautifully around the tree. Once the strangler fig takes root in the soil, it chokes and kills the tree that was its host. The metaphor that came from this natural process was appropriate in the software development world, thought Martin; after all, when transitioning to a modern system, it’s easier to gradually create a new system around the edges of the old — until the latter is “strangled” and comes to its inevitable end.
This eureka moment gave birth to what Martin named the strangler pattern; in short, it is a migration process from an old system to a new one that replaces functionalities piece by piece. In digital commerce, the strangler pattern has become a popular way to migrate from monolithic applications to microservices because the chances of system disruptions are relatively low. At the same time, businesses can reap the benefits of new applications without waiting months — or years — until the entire architecture is microservices-based.Get Started with Composable Commerce Today
Big bang and strangler pattern, compared
The strangler pattern counterpoints “big bang” migrations, which have given replatforming projects a bad rep over the years. With a phased process achieved via the strangler pattern, your business can avoid issues like disruptions and downtime while achieving ROI (return on investment) faster. Here’s how the big bang and the strangler pattern compare:
When replatforming from one (monolithic) system to another in the past decades, businesses had no other choice but to use a “big bang” (also known as a “greenfield”) approach. Companies using this traditional process would rebuild the complete commerce architecture and release it entirely in one operation. In short, the platform would remain in place until the big bang event to switch to the new infrastructure.
Migrating the whole system in one event means developers get a clean slate and don’t have to interface with legacy code or parallel systems.
Defined cut-off point.
No need to decouple the existing system to implement a new system.
Risk-prone options due to unpredictable errors and downtime.
Requires thorough planning.
High margin for error: A complete rollback is usually required if the migration fails.
Requires a high upfront implementation cost.
Business value/ROI takes a long time to realize.
The strangler approach breaks the legacy commerce platform into small pieces as microservices and slowly replaces single components incrementally. Over time, the monolith will start to “suffocate” and eventually disappear. Using this approach, tech teams can monitor progress easily and control the migration every step of the way with smaller-scale deliverables. If something goes wrong, it’s easier to pull back any changes without affecting the entire infrastructure.
Control every step of the migration process while minimizing disruptions and downtime.
Experiment with components easily, as you can freely swap them.
Low margin for error: If a single phase fails, only this phase needs to be rolled back and repeated.
Deliver business value/ROI faster.
Lower upfront effort in planning.
Effort and costs to keep two systems running in parallel for technical staff and users.
The migration in itself takes longer.
Requires source system to be decoupled so the target system can serve functionalities bit by bit.
3 migration steps with the strangler pattern
More than migrating from a monolith application to microservices, the strangler pattern reduces complexity with an automated CI/CD (continuous integration and continuous delivery) pipeline for each microservice. That way, it’s possible to deliver business features faster.
To streamline the transition from monolith to microservices, you need to follow three main steps:
Transform the application by creating new versions of existing services: Once the new component is built, you can test it against the current legacy code.
Co-exist with the old application running alongside an ever-increasing number of microservices. The legacy as well as the newly built components must be functional for some time.
Eliminate the old when the new services completely replace the old system.
When each of your applications has migrated away from the monolith, each microservice has its own data store and CI/CD pipeline.
Why use the strangler pattern
commercetools’ customers have repeatedly chosen the strangler pattern instead of the big bang approach when migrating to composable commerce. This is because composability's microservices-based and API-first nature enables the incremental migration of components rather than a “big bang” traditional process, as it reduces risk and sets up a virtuous cycle of release-win-learn-iterate. Also, you can create minimum viable products (MVPs) to establish a first base for what the rest of your commerce solution will look like — and upgrade over time.
In addition, waiting 12 to 24 months for a sizable replatforming project to kick in doesn’t make sense in an environment of constant change. That’s why C-level executives, business executives and other internal stakeholders usually agree that transitioning step by step diminishes the risks associated with large replatforming projects while reaping the benefits of a more flexible and agile system in the short to medium term.
Migrate now to commercetools Composable Commerce
There are three main migration routes you can take with the strangler pattern:
If your developers aren’t experienced with microservices or you’d rather test the waters before tackling advanced components, select a low-risk system or location to start.
Tackle a pain point, like a difficult-to-navigate product catalog, and move it to microservices as step number one.
Implement the backbone of digital commerce with Cart and Orders APIs to tackle Checkout. Starting with Checkout means you can secure the most critical part of the customer journey and focus on building differentiation across all other steps and touchpoints of the customer experience while accelerating ROI.
Regardless of how you migrate to commercetools Composable Commerce, the strangler pattern enables you to get started at your own pace, create your MVP and test the best approach for your business.
Want to migrate to commercetools Composable Commerce in a step-by-step way?
Download the migration guides for Salesforce Commerce Cloud, Oracle Commerce Cloud, Adobe Commerce or SAP and Homegrown. You can also create your MVP or proof of concept (POC) with commercetools' free 60-day trial.Unlock the Power of Composable Commerce