How to migrate to a composable architecture ?

Do you want to replace your legacy system and move towards a composable architecture?

This approach has many benefits, allowing you to achieve a modern IT architecture fully adapted to your needs. However, the transformation presents some constraints, as it also involves a change in the way of working.

To migrate to a composable architecture, you first need to assess your current architecture.

Then, follow a specific methodology that we present to you with a case study focused on an e-commerce site. Finally, we give you best practices to implement and manage this type of system.

What is a composable architecture ? Benefits and constraints

Understanding composable architecture

Redeveloping your legacy by choosing a composable architecture allows you to move away from the monolithic vision of IT tools. Indeed, the traditional monolith model is presented as a block that combines different business applications, generally integrated as plug-ins. While these allow you to perform different business functions, integrating them is not always enough to meet all needs.

A composable architecture looks different. It uses features embodied by individual components that operate independently. This offers more flexibility, as you can work on one component at a time without impacting the rest of the architecture.

The platform offers an optimal, seamless customer experience. The backend for frontend solution links the platform to the different business tools, such as a CRM, a PIM or OMS, by bringing up the necessary information at the right time.

The benefits of composable architecture

Moving to a composable architecture enables you to :

• own the tools that truly correspond to your needs without going through a plug-in solution. You truly own the tools in question and not just add-ons that complement a system.
• make specific developments based on precise needs.
• offer a seamless high-quality customer experience.

Constraints of this type of architecture

However, adopting this type of architecture requires adaptation. The working methods are very different compared to a monolith. This involves relying on the cloud to ensure the platform’s scalability and working with tools such as :

• Docker/Kubernetes ;
• Infrastructure as code ;
• Automated deployments ;
• APM-type monitoring ;
• Centralized logs.

It is essential to use API first to comply with headless with :

• tools to work locally ;
• a DevOps culture ;
• shorter deployment cycles ;
• dependencies and backward compatibility ;
• a testing strategy.

Furthermore, a cultural change must be led which requires :

• understanding headless e-commerce technology ;
• knowing where to apply a business rule ;
• being able to develop skills for working with the implemented tools.

Taking stock of your IT architecture

Before migrating to a composable architecture, it is necessary to have a good understanding of your IT architecture. This involves knowing precisely what your legacy does:

• direct dependencies of the legacy : which systems does it rely on ? What are the flows and business rules ?
• existing exotic uses : what are the uses made by users that respond to implicit rules ? How important are these uses ? What are the consequences of their possible removal ?
• real business rules : are these rules documented ? If yes, is it done precisely ?

Migrating to a composable architecture : case study with an e-commerce project

Let’s imagine the following scenario when migrating an e-commerce site with an all-in-one legacy. This e-commerce company merges with another company, which also has a legacy system. It is impossible to merge these two architectures. The decision is then made to migrate the e-commerce site to a composable architecture.

For this migration, it is necessary to follow different steps.

Adding a headless CMS

It can take some time to get used to the operation of a headless CMS. Indeed, it is very different from a traditional CMS. A headless CMS has no strong link with the navigation menu. Content management is independent of the tree structure. The different contents can be titles, images, or texts, which are stackable.

Thus, to display content on a product page, you must do the following :

• set up an “articles” field to enter product identifiers in the CMS’ article editing,.
• link the editorial content to the product data at the backend for frontend level.
• at the frontend level, explicitly request to retrieve the editorial content in addition to the product data through a GraphQL call.
  Format the data once it is present.

Planning a PIM integration

To integrate a PIM, the aim is to :

• Expose a method in the backend for frontend such as get_product_by_id.
• Connect the backend for frontend system to the PIM so it retrieves the data corresponding to a product.
• Set up a key/value type cache at the backend for frontend level to avoid querying the PIM for already known data.
• Implement a cache purge method (by expiration or exposing an API).

However, it is possible to propose a transition step, which allows you to plan for the later integration of the PIM. For this, the approach is as follows :

• expose a method in the backend for frontend such as get_product_by_id.
• connect the backend for frontend to the legacy so it retrieves the data corresponding to a product.
• set up a key/value type cache at the backend for frontend level to avoid querying the legacy for already known data.
• implement a cache purge method (by expiration or exposing an API).

The legacy is used as a headless transition tool by being cut off from the front office. The PIM can then replace the legacy without impacting development.

How to disconnect the frontend from the legacy to adopt a transition solution ?

There are two possible options.

In the first case, the legacy is “connected” at the URL level. The entire site is, by default, served by the legacy. When a section of the site is managed by the new architecture, traffic can be redirected there based on the URL. For example, all URLs in …./product_detail/… will be disconnected from the legacy.

However, there are different issues to anticipate :

• Should transversal elements such as the header or footer be reused to maintain a seamless customer experience ?
• Should the graphic style be reused ?
• How to display the cart on the screen ?
• Do you know how to generate links to the monolithic application ?

The second method relies on inserting components into the page coming from the new architecture. It is by a Javascript call initiated in the legacy that new content will be added to the page (carousel, editorial content, new payment method, etc.). Again, some issues need to be anticipated :

• Do you know how to modify the monolith template to insert dynamic javascript ?
• Does the behavior of the injected component depend on the user’s identification ?
• How to adapt to the style of the monolith ?

Best practices for migrating to a composable architecture

Here are some tips to help you prepare your migration to a composable architecture.

Accept the unexpected

It is important to plan certain points, but it also involves adapting by accepting the unexpected :

• The goal is clear, but the details will probably evolve.
• The roadmap is ready, but opportunities will arise.
• Estimates have been made, but they have not yet been reality tested.

Ask yourself the following questions :

• How to distinguish an opportunity from a bad idea ?
• How to prepare to review plans effectively ?
• How to distinguish between the time needed to build skills and inefficiency ?

Prepare the fundamentals

If the composable architecture is partly or entirely new to you, practice it before starting development work :

• Choose your cloud platform.
• Apply the use of Terraform to display a “hello world” on an application composed of the technologies you decided to use.
• Deploy the “hello world” in an automated way.
  If you have network issues accessing specific resources, address them in the “hello world”.
• Set up monitoring and log centralization. It is important to centralize elements to avoid wasting time and quickly detect problems.

Set up continuous deployment

You must also set up continuous deployment to avoid any blockage :

• Deploy as early as possible: you will know what you deploy and have test indicators in real conditions.
• Monitor by collecting and centralizing logs and observing how server load varies with successive deployments.
• Prioritize small increments, as it is easier to track their impacts.
• Learn to rollback, rollback must be simple and fast.
• Prefer activation over deployment: in this case, rollback becomes a deactivation.
• Anticipate data migrations, they are generally more complex than expected.
• Don’t forget to celebrate successes !

Testing the system is essential :

• Don’t hesitate to make POCs.
• Don’t hesitate to deploy them to production (disabled).
• Invest time in setting up automated tests (sparingly).
• Monitor the impact on your users by planning behavior analysis before/after.

Migrating to a composable architecture and anticipating change

Migrating to a composable architecture is not just a technological evolution. It must also be anticipated in order to accept change. Composable architecture use differs greatly from that of a classic CMS, so some adaptation time is required before reaping the benefits.

Don’t hesitate to surround yourself with people who have the knowledge and expertise to support you in migrating your composable architecture. For this, you can contact Kaliop.