From E-Commerce Platforms to Microservices Omni-Commerce

Background

Traditionally, retailers have used e-commerce platforms such as ATG, WCS, Hybris etc. to build and manage their online storefront. These monolith applications were based on a three-tiered architecture. Over a period, the modules were customized, integrated with many other enterprise systems and a lot of investment was made in running the operations. In recent years, however, many of the retailers have started to shift away from these platforms towards a microservices based commerce to have the flexibility to implement customized features and scalability to meet omni-channel demand in an agile way. The path to refactoring has traditionally been long although rewarding in the end. This is a point of view on this shift with a suggested approach towards accelerating this journey. Recommending a specific technology stack or framework for microservices is not the goal here.

E-Commerce Modernization: Context

Customer experience is becoming truly omni-channel, contextual, and personalized. This puts new challenges in terms of availability and scalability of the website functionalities. Businesses need to be quick in preparing for the ever-changing environment and in their reaction to competition. eCommerce applications need to evolve to meet the challenges while supporting continuous delivery.

The main drivers for the shift towards microservices are:

• Ability to quickly implement changes, quick deployments, and rollbacks
• Need for a responsive UI, real-time data, and immersive user experience
• Website’s unavailability could greatly impact revenue and reputation
• Need to scale up during sudden spikes
• Different features require different levels of availability and scalability
• Keeping the cost of operation low
• Omni-channel personalized experience (not supported out-of-the-box and difficult/slow to customize)

SaaS and Cloud Offerings of E-Commerce Platforms

Although SaaS platforms can address some of the concerns such as cost and availability, retailers often need custom differentiating features and true omnichannel capabilities that are not supported through these platforms. Businesses want to run new experiments quickly or bring efficiency to a process that is typical to their organization. Cloud offerings of traditional e-commerce platforms also do not provide that flexibility.   

Industry Trends

Many of the Tier 1 retailers have been moving away from monolith eCommerce product platforms towards microservices, cloud, CI/CD and DevOps. By doing this they have been able to have more control over quickly releasing features that are unique to their business vision. Others are going to follow the trend as the need for being quicker, omni-channel and available becomes critical to their competitiveness.

Microservices for Enterprise Applications

While microservices can be used for almost anything, the real driver is the ability to make quick change. For many Enterprise applications (such as Finance, HR etc.), focus is usually on stability than agility. However, there are certain enterprise applications which have started to transform (such as driving efficiency in WMS using ML/AI/IoT) and these might be good candidates to try microservices. Event driven design will help to seamlessly integrate with legacy applications.

Approach to Microservices-Based E-Commerce

Refactoring e-Commerce platforms to microservices is a long journey. Through planning ahead, following established architectural patterns and preparing the ecosystem before making major changes to a running system, this journey could be made quicker and risk-free.

It is often a good idea to start exploring and building capabilities around Agile Delivery, Continuous Integration and Deployment, DevOps, 12-factor app design, DDD, cloud-native, polyglot programming as the foundational work for building microservices. Domain driven design is an evolving process and the microservices should be designed for easy refactoring.

With DevOps, cloud-native design, and continuous integration and deployment in place, microservices can be run on-premise on private cloud or hybrid/public cloud. Public cloud is always a better choice for eCommerce application.

Team Organization

Decomposing a complex monolith into microservices requires identifying cohesive business functions and entities (domains) and model them in independent bounded contexts. This granular separation results in identifying microservices (and the teams). The teams are typically small with mixed skills in development and operations.

12-Factor/Cloud-Native Apps

12-factor apps are built based on methodology/guidelines to deploy, scale and manage them independently. They are easy to be moved from one platform/cloud to another and can be started/scaled quickly and shut down gracefully.

DevOps

DevOps practices help build collaboration in the team and provide a framework required for automated, fast and frequent delivery by removing dependencies, handoffs and repeatable manual configuration.

Microservices Framework

It is recommended to use a microservices framework that can take care of cross-cutting concerns for services, such as

• Service Registry
• Service Routing and Filtering
• Access Token
• Circuit Breaker
• Client-side load balancer
• Instrumentation

Additionally, choose a framework that is easy to be replaced/upgraded in parts and supports multiple platforms.

Refactoring Sequence

The diagram below depicts a traditional monolith implementation of eCommerce application.

Typically, e-commerce platforms are componentized by layers (presentation, business, persistence etc) and not by functionality. This is often reflected in the data model which tightly couples different functional domains.

Dependency on other components makes it difficult to refactor that component into a microservice. Usually, it is recommended to start by making the platform headless and building a new reactive UI layer over it.

One of the risk mitigation strategies for large migration projects is to apply Strangler pattern in place of a complete cut-over. E-Commerce platforms are comprised of different modules such as Catalog, Cart, Promotions etc.

The critical content/components need to be moved first to cloud for availability. The home page and browse/search pages have the maximum hits. This is usually followed by product description pages.

Here is a list of domains from eCommerce engines and a possible sequence for migrating them:

• Search
• Catalog
• Product Pricing
• Inventory
• Shipping
• Delivery
• Customer account
• Promotions
• Cart
• Associate facing tools

While this is a typical sequence, the sequence should be driven by the criticality. It also helps to start small with a lean team. Also, it does not necessarily have to be a complete migration from the platform i.e. if an organization’s needs are fulfilled by just transforming some critical functions of the platform to microservices.

To make the new services organize data and semantics within its bounded context, an anti-corruption layer is required to translate context while integrating with the legacy platform during the transition. An incremental journey can be adopted by a small team where only the critical functions are migrated to microservices first while building an interim architecture.

With the monolith being split in different domain services, there will be a need to build materialized view comprised of data from different microservices. For instance, product catalog materialized view needs to be built and be kept updated based on product, price, inventory, promotion events. By keeping it event driven, we avoid coupling between services and also avoid latency. Different consumer applications would require their own materialized views based on individual need.

Multiple levels of distributed cache and cache eviction through event-based subscription is recommended.

The diagram below is the target architecture for microservices based e-commerce.

Challenges

As eCommerce platform turns into services, the goal should be to make the services golden source of truth. There should not be channel specific inventory service, for instance. However, retail enterprises have traditionally been organized in a way that such a move would require synergy among a lot of teams with their own priorities. In the interim, it might be required to create copies with a roadmap for other teams to start using the service.

Often the refactoring is done by a new team (with different skill sets). As a risk mitigation step, it might be required to implement some enhancements in both old and new platform (unless it is a new capability that can completely be implemented in a separate service that both old and new platforms can integrate to).

Microservices increases the complexity of application management. Using a container platform is recommended. Microservices frameworks can help address cross-cutting concerns such as API Gateway, observability etc. Choose a framework that is easy to be replaced in parts and supports polyglot.

The Road Ahead

I expect the trend to be moving towards microservices from monolith e-commerce systems to continue. But this will apply more to large retailers who feel their existing e-commerce monolith systems are inflexible and want to do more but are unable to do so.  Another key driver for retailers will be their internal technical strength and their ability to onboard quality FSDs (Full Stack Developers).

Smaller sized retailers are also likely to test the waters by starting to build one or two microservices, such as search or browse before deciding to continue with the core cart and checkout features.