Loading Form...
Oct 11, 2023 | 3 minute read
written by Bryan House
As I’ve written about before, breaking up with your commerce monolith might be hard to do — but it doesn’t have to be as hard as you think. Ripping and replacing entire legacy systems isn’t just costly in terms of an up-front technical investment — it’s risky and disruptive. One of the patterns I outlined in a previous blog is the “Strangler Pattern,” which involves replacing components of a legacy system step by step.
It’s the subject of an in-depth white paper my technical colleagues recently authored, and it’s worth highlighting some of the key ways in which an architect might approach restructuring a monolithic system piece by piece.
While it sounds like a great true crime podcast, the Strangler Pattern was originally named by Martin Fowler in 2004, after Australia’s abundant strangler figs. These plants seed in the upper branches of a tree, working their way down to the soil until they’re fully rooted. In the process of their growth, they strangle off the original host tree. It’s a great analogy for the way microservices-based systems can be used to gradually replace legacy systems until they’re obsolete — commerce systems included.
The great thing about an API-first, composable commerce approach is that you can theoretically start with any component that’s most urgently needed, “strangling” what isn’t working for you step by step. For some retailers, that might be search or navigation capabilities, a headless content management system (CMS), a Javascript-based frontend for your storefront, or catalog management capabilities. The answer of where to start is as personal as what matters most to your business’ bottom line. An experienced architect can help you determine how to replace capabilities of your monolith with microservices-based applications, and in which order.
Access a free Elastic Path trial today to see our leading composable commerce solution in action.
Some monoliths lend themselves better to outside integration than others. For example, some provide points of integration through REST APIs, and some do not. This important consideration will make a big difference when it comes to your approach to gradually replacing your monolith.
One approach is to integrate the new or replaced functionality directly into the existing monolith. Modern, microservices-based systems like Elastic Path are designed to be used as individual pieces and make this possible. For example, an item can be added to the Elastic Path cart, even if it does not exist within the Elastic Path catalog.
A second approach is to move the existing system into a supporting role. In this scenario,the existing monolith can remain the source of truth for most of the data and will not disrupt the business functions until the project is closer to completion. It’s possible to sync the data between the existing monolith and the new composable commerce solution. The monolith maintains its integrations, but the new system serves customers, ensuring they see the new functionality — making it possible to improve the customer experience and increase conversions.
To learn more about how my colleagues recommend making the gradual migration from a commerce legacy system to a modern, API-first composable commerce system, check out Strangler Pattern: Monolith to Modern Composable Commerce.
Subscribe to our blog to stay up-to-date with the latest commerce industry insights, tips & tricks, merchandising and development best practices, and more!
You'll receive a welcome email shortly.