Monolith to MACH and learnings along the way

Ronak-Shah.jpg


Back in the late 90s and early 2000s, my life as a web engineer was good. I worked with one big commerce packaging, one big code repository, and everyone on my team had a clear understanding of what was happening across the whole system. All of our web needs could be met within the capacity of a single platform, and it was a much simpler decade for digital business.





Over time, as eCommerce adoption increased, expectations rapidly evolved from both end-customers and business users about how our systems should work. The introduction of the iPhone and other new touchpoints fundamentally changed how commerce was consumed, and fueled the disruption of enterprise architecture. There was an appetite for new capabilities, experimentation became mainstream, and “innovation” was suddenly table stakes.

The need to continuously deliver new experiences required frequent enhancements to the system. Organizations started moving to agile, but trying to work in an agile mindset with a big, tightly-coupled code base seemed like trying to fit a square peg into a round hole.

That single commerce platform, which had once made life so simple, was now doing more harm than good. Problems were felt at three main levels:

  • People - All teams working on one large codebase with a single deployment was inconvenient, slow, and risky
  • Processes - Different teams weren’t able to make their own choices around development and deployment
  • Technology - Commerce was unable to scale, and it was too hard to experiment with newer frameworks to support business capabilities

Organizations realized they need to change their approach to enterprise architecture, and many started the journey to microservices, APIs, Cloud, and headless - aka MACH.

At Bed, Bath, and Beyond we started this journey in 2017 by first building a product catalog and search as a service in the cloud. Having APIs for the product catalog made detaching the frontend possible. From there, we have been progressively making our architecture more composable with APIs. For any companies thinking of moving from monolith to MACH, I wanted to share some key stepping stones and considerations I learned along the way.



Start with the “H” (But you’ll need the “A” to do it)


Our first step in breaking away from our legacy monolith was to create a headless frontend, the “H” in MACH, so that we could develop and deploy frequent frontend experience changes. To support this, we used Catalog / Search API and an API gateway, the “A” in MACH, to aggregate data from the monolith and other backend systems that we could feed to our agile frontend.

Our journey - going from a monolithic commerce platform to a headless frontend with an API gateway, took about 6 months.


Consider single-page applications


Another driver to move to this set-up is to use more responsive, single-page application (SPA) architecture driven by react.js or vue.js. This type of initiative would look like building a flexible and modern frontend. When a user comes to the site, the SPA first goes to the browser and then an XMLHttpRequest (XHR) API can be used to transfer data to the browser without having to reload the entire page.



Aspects to Consider:


  1. What is your site size in terms of functional components? Do you have a small team (6-8) who can code and maintain a headless frontend?
  2. A headless frontend shouldn’t become a new monolith frontend. Which services can you separate that add business value and let different teams go at their own pace?
  3. JavaScript is the most expensive resource for browsers. Are you able to minimize the penalty of initial load for SPA including hydration cost?

The above questions helped us decide that we needed multiple SPAs. For larger and feature rich frontends, it made sense for us to have micro-frontends in the area of content pages, pre-purchase (product detail and product listings), and purchase (cart, checkout, confirmation).

If you have a smaller site and can make static site generation operationally possible, that seems to be the best option from a web site performance perspective.



The next incarnation of frontend included multiple SPAs and our journey to monolith to MACH continues.


Identify fast and slow moving data


There’s no right answer for how many services you should start with, as your solution will be unique to your specific use case and what areas can harness business value. However, one approach that we learned along the way is to prioritize our service separations around fast and slow moving data.

Slow moving data doesn’t change much, such as product images and product titles, and can be cached for a longer time. Fast moving data is frequently updated, such as inventory and pricing, and a smooth customer experience needs this data to be available in real time. Approaching services from the mindset of data change speed has put us in a better position for, caching, managing resources and scaling.

Precompute, prefetch, and use Edge to get the edge


Applying precomputing and prefetching principles to our service building allowed us to speed up the delivery of the core information that every user receives coming to the site. This meant that when a user requested a page, there was more time available to use edge computing to invoke personalization and present the page, data or part of the page with content the user would like more. For example, having the user’s favorite color SKU auto selected on the product page or having the product listing page sort results by brands the user likes.

An Overall multistep process


Our journey from monolithic to MACH is an ongoing process. By breaking off our frontend early, creating key APIs and leveraging multiple SPAs, we are able to improve our customer-facing experience quickly and have gradually been composing our backend into services where it makes business sense to do so.

We continue to move towards serverless, low code, low ops as we make choices for future services. Becoming truly cloud native, the ‘C’ in MACH.

As even smaller SPAs get bloated with javaScript, we implemented performance budgets as part of the build process and continue to build the performance culture.




If you have any question on our approach, or would like to know more about the technical aspects of the journey, feel free to get in touch.



The MACH Alliance is very excited to welcome Ronak as a MACH Alliance Ambassador. Our Ambassadors are a carefully selected group of business and technology experts with a wide range of experience across industries and backgrounds. Passionate about the benefits a modern architecture can bring to an enterprise, our Ambassadors have graciously committed their time to support the mission of the MACH Alliance by writing, speaking, and serving as subject matter experts to help empower companies to go MACH.

If you’re interested in learning more about a MACH approach, and understanding if it’s right for your business, you’re invited to reach out to Ronak or get in touch with us at info@machalliance.org to be matched with the MACH Alliance Ambassador most relevant to you.


Insights

2021-09-20

Tom Aniol, Head of Marketing, Vue StoreFront

"Click and Collect" is blossoming, and it will stay with us

2021-08-16

Varia Makagonova, Director of Marketing, Contentstack

Intelligent product discovery fast-tracked by MACH

2020-07-02

Sonja Kotrotsos

machreplatformecommercecustomerexperiencecmsMACH: Business Technology for 2020 and Beyond

”66% of developers find that maintaining and “paying for” technical debt (aka the money, flexibility, and opportunity lost to a bad technical investment) associated with outdated technology is bad for their productivity at work." State of the Developer report 2109, Devada

Show All