From Monolith to Microservices: A Guide To Replatforming

Early on in my conversations with executives and decision-makers of retail brands, our talks inevitably turn to one of the biggest issues facing many e-commerce businesses today: how to successfully execute a replatforming project from a monolithic e-commerce platform to a microservices-based platform.

Companies and their IT teams can be apprehensive about taking on such a monumental task. On the one hand, a successful migration can offer many tangible benefits, including better flexibility, scalability, user experience, security, and profitability.

Yet on the other hand, the process can be expensive, long, and grueling, and there are no guarantees that it will work as intended. In fact, fabric CTO Umer Sadiq recently summed up the experience when he said:

“Replatforming is commonly viewed as a tax and a burden and not as an opportunity for companies to innovate and excite.”

Monolith to Microservices: Ending “The Pain Of Replatforming” The Right Way

While “replatforming” has become a word associated with pain and discomfort, it shouldn’t paralyze IT teams with fear and force them into inaction.

While leading the Retail Sub-Business Unit at Tata Consultancy Services (TCS), I spearheaded the digital transformation and legacy modernization efforts across many of our clients. These organizations had technological debt and legacy platforms that had expanded due to acquisitions, organic growth, and lack of rationalization strategies. Some had more than 2,000 applications, many doing the same function across different business units.

Most importantly, I led the initiatives to move off licensed e-commerce monolith systems to a microservices-based open technology stack—giving our clients far greater scalability and flexibility by allowing the adoption of best-of-breed technologies.

In this article, I’ll break down what you need to know about monoliths, microservices, replatforming, and how to complete a successful migration from a legacy e-commerce platform to a microservices-based platform. We’ll go over the optimal sequence of steps that businesses should take, which lays out a “top-down” approach to e-commerce functionality.

First, to gain a better understanding of how to initiate a replatforming project, let’s take a look at several key terms that relate to the process of migrating an e-commerce platform.

What Is A Monolith?

In software engineering, a monolithic e-commerce application is a single, self-contained, and unified unit where all the commerce functionalities required to run an online business are built into one system. With these all-in-one structures, everything from product information management, order management, pricing, and other e-commerce functions are combined into a single, rigid application.

However, there are some common drawbacks to monoliths:

• Changes require updating the entire tech stack by accessing the code base and building and deploying an updated version.
• Changes also require extensive testing, which slows down any deployments.
• A single point of failure means that problems can affect the whole application and bring the entire system down.
• Size, complexity, and interconnectivity of applications affect speed, scalability, and ability to adopt new technologies.

In some scenarios, monolithic architecture can be cheaper, but businesses often get stuck paying for tools and services that they don’t need or use. Furthermore, companies can get locked in with single software-as-a-service (SaaS) providers, making it difficult to upgrade systems without the provider’s help and making it complicated and expensive to access services from third parties.

What Are Microservices?

E-commerce microservices are applications that are independent, self-contained pieces of business functions or services. Unlike the all-in-one structure of monoliths, microservices break down each commerce function into separate applications, including cart, pricing, items, orders, payments, and more.

With microservices-based architectures, functions connect through application program interfaces (APIs), which allow systems to talk to each other, share services, and exchange data. Speed, flexibility, security, and scalability are achieved because each microservice can be changed or updated without disrupting other systems. Key benefits include:

• Modularity: allows different components of a software system to be divided into separate functional units.
• Composability: allows enterprises to select, assemble, swap, and pair components in different combinations.
• Scalability: allows enterprises to scale individual microservices up or down based on usage because they are independent of each other.
• Extensibility: gives companies the ability to extend existing systems to allow for the addition of new capabilities or functions.

A microservices-based ecosystem allows companies to switch e-commerce platforms or evolve existing platforms, and they can also enable both headless commerce and modular (composable) commerce.

Replatforming From Monolith to Microservices: What You Need To Know

When running applications on time-tested legacy technologies, businesses need to decide whether they should keep the lights on (KTLO) or modernize the system.

Replatforming is a migration strategy for transitioning from an existing legacy e-commerce platform to another platform. Generally, this is done because the legacy platform no longer serves the needs of the business. Some reasons include:

• Upgrading or replacing an outdated system
• Lowering costs
• Improving security
• Gaining access to better features, technologies, and capabilities
• Achieving better performance
• And improving scalability

For strategic alignment, key decision-makers must have a hand in assessing the problem, figuring out finances, and laying out the business roadmap to follow. But once a company decides to replatform from its legacy monolithic system to a microservices-based architecture, there is an optimal sequence that they should follow.

Learn more:

• What Is Replatforming?

Monolith to Microservices Sequence: Changing The Tracks of a Moving Train

When moving from a monolith to microservices, online retailers don’t have the luxury of pausing their e-commerce operations. The migration needs to happen while the business is still running, which is likened to changing the tracks of a moving train.

That’s why it’s important to follow the correct sequence to minimize disruptions. Migrating applications in the wrong order could impact a business’s top and bottom lines. As a guiding principle, the migration should generate the highest business velocity and business benefit during the process.

The strangler pattern for modular replatforming

The strangler pattern allows a business to incrementally migrate a legacy system by gradually replacing specific e-commerce functions with new applications and microservices. When the existing application is successfully migrated over, the old part of the application can be retired.

Service by service, the process is continued until the new microservices replace the entire legacy monolith. Once you’ve “strangled” the old code, it can be abandoned completely.

Learn more:

• Using the Strangler Pattern to Break Down Your E-Commerce Monolith

However, to implement the strangler pattern for an e-commerce replatforming project, you need to follow the correct sequence of steps. The general sequence can be split into four main phases, then further broken down into smaller steps within each phase:

Phase #1: Create an abstraction layer

• Use the strangler pattern
• Separate the frontend from backend

Phase #2: Focus on top of funnel

• Migrate product
• Migrate pricing
• Migrate search
• Migrate inventory

Phase #3: Focus on orders

• Migrate orders

Phase #4: Focus on backend functionality and customer-related services

• Migrate cart
• Migrate checkout
• Migrate users

A Step-By-Step Guide To Decomposing a Monolithic Application to Microservices

Phase #1: Create an abstraction layer

Step one is to create a separation of concerns by creating an abstraction layer, or abstraction level, between the frontend presentation layer and the backend commerce functionality. Also known as a proxy layer or a strangler façade, it allows you to create a separate set of commerce microservices that the frontend can talk to while maintaining communication with the underlying monolithic backend.

This ensures there is no disruption of service as you begin eliminating the concern and migrating piece by piece to the new microservices backend. Separating the frontend from the backend is also called headless architecture, which uses APIs to ensure proper communication between various components.

Phase #2: Focus on top of funnel

E-commerce is based on five main elements: product, pricing, inventory, order, and customer. But following the 80-20 rule, roughly 80% of the traffic to an e-commerce site involves top-of-funnel functions. Therefore, the next logical step is to focus on product, pricing, and inventory, in what’s known as a “top-down” approach to a replatforming migration.

Using the strangler pattern, the first service to migrate is the product information management (PIM) system. A PIM allows you to edit, store, manage, and enrich all of your product information (SKUs, item numbers, attributes, catalogs, images and videos). All of the PIM data can be copied into a new microservice that can be called using APIs.

Product pricing and inventory data can sometimes be stored in a PIM, or they can be in a separate pricing engine and inventory management system (IMS). Nevertheless, separating pricing and inventory into distinct microservices offers long-term scalability as you evolve your product catalog and pricing strategy over time.

Product data from a PIM is published through a content management system (CMS). A CMS publishes product content on the desired channels and stores other useful content on a website. CMS is a straightforward migration because the content is mostly “read-only” website pages.

Product search can also be migrated in this stage as well. Similar to the CMS, search is a “read-only” system that takes the entire product index data and serves up the results. Migrating search over to the microservices platform using the strangler pattern provides the benefit of keeping the search function active for customers while you continue the migration process.

Finally, inventory data is needed for product detail pages (PDPs) to show if products are in stock. Inventory data can live in either a monolithic e-commerce platform, or more commonly, in a standalone warehouse management system (WMS). Again, the abstraction layer allows the inventory data feed to be sent directly to the new inventory system in the microservices platform, which lets you retire the inventory management function in the old system.

Phase #3: Focus on orders

The next element to tackle is orders, which is all about the order management system (OMS). To begin an OMS migration, customer orders can be sent to both the old system and the new system, and you can begin building up your new order database.

However, unlike the mostly “read-only” systems that were previously migrated in the product phase, customer orders are a “write” use case. This means that customer orders need to be dual-written to the old system and the new system. Writing to both systems keeps the data consistent, which will eventually let you make API calls to only one system—thereby completing the migration of the order management function to the microservices architecture.

Phase #4: Focus on customer-related services and backend functionality

The final three pieces of a replatforming project are generally cart, checkout, and user, which are also the hardest parts because they involve large-scale data migrations.

To begin, the abstraction layer will again be used for the API calls being made from the current cart and checkout pages in the frontend to the monolithic backend services. The API calls can then be directed to point to the new cart and checkout microservices of the new system. During this process, inventory values must be replicated to the datastore to ensure the checkout inventory validations are accurate.

The final main migration piece is the user. Customer data generally includes profiles, account info, preferences, login, shipping address, billing address, payment info, and more.

Using the strangler pattern, you can migrate users and passwords over to the new system with an active migration. Because a password is a one-way hash and can’t be migrated itself, the process involves authenticating the user against the older system. Then as the user validates their password, the same password can be rehashed against the new system. Hashing user passwords against both systems is an elegant way to get passwords copied over without having to contact users to ask them to change their passwords.

Once users are migrated, you can follow up by copying their existing carts, preferences, and other user data over to the new system. At this point in time, you may also encounter payments. Payments handle tokens which are most likely still valid if your business uses the same payment processor. To migrate, you can use the same token against the user against the new system.

Remember integrations

One final thing to mention is that corresponding integrations to other services should also be done simultaneously. Most integrations with third-party SaaS providers for taxes, address verification, payments, fraud detection, recommendations, or product reviews are prebuilt and can be reused by plugging them into the new system.

Alternative: Bottom-Up Approach

Another approach is the “bottom-up” approach to replatforming. This method starts with migrating orders, backend functions, and customers first, then moves on to top-of-funnel microservices for product, pricing, and inventory.

While this approach also works, it’s usually harder because business demands generally call for the latest top-of-funnel features. Choosing which migration strategy to follow depends on the business roadmap and how much leverage you have to do a platform migration independently.

Final Thoughts on Migrating from a Monolith to Microservices

The incremental steps laid out in this guide provide retailers with the optimal sequence to follow with most replatforming projects. While I’ve outlined one particular approach, the ultimate goal is to “End The Pain of Replatforming” as we know it.

That’s why the true power of microservices lies in its unparalleled ability to be flexible. In other words, the phases of the replatforming project can easily be customized to suit the specific needs of the individual business.

A truly customizable approach that can address several different—and at times conflicting—scenarios are what today’s complex e-commerce operations require. Whether it’s technical debt, business priorities, expiring legacy contracts and timelines, or in-house domain knowledge and comfort levels, businesses don’t have to “boil the ocean” by migrating an entire e-commerce platform all at once ever again.

A replatforming project to microservices can now provide the business benefits of evolving the roadmap and the platform flexibility to move away from an old monolithic platform. By following this guide, you can gain a basic understanding of how to execute a successful migration from a monolith to microservices.

fabric Commerce Platform offers headless and modular technology that allows retailers to adopt a modern, modular commerce architecture without hampering existing operations. If you want to learn more about how fabric can help end the pain of replatforming, get in touch with us here.

---