MACH Aligned for Retail: Microservices

Prashant Juttukonda and Miquel Nieto

MACH is an approach to architecting modern applications through open tech ecosystems. It is an acronym representing Microservices, API-first, Cloud-native SaaS, and Headless. With the accelerating digitalization of retail experiences requiring new technology stacks that provide agility, flexibility, and performance at scale, MACH is especially relevant for retail and ecommerce, a far cry from current legacy, monolithic architectures.

The MACH Alliance is an organization, of which MongoDB is a member, dedicated to educating and driving the adoption of the MACH framework and to “future proof enterprise technology and propel current and future digital experiences.”

This is the first of a series of blog posts dedicated to MACH and how retail organizations are leveraging this framework to gain a competitive advantage. Let us begin with the first letter of MACH: microservices.

What are microservices and why should I care?

In simplest terms, microservices are an approach to building applications in which business functions are broken down into smaller, self-contained components called services. These services function autonomously and are usually developed and deployed independently. This independence means the failure or outage of one microservice will not affect another. Each service serves a particular business function or objective.

The benefits of a microservices-based architecture are clear. The modular approach of microservices provides companies with quicker time to market and value, ultimately leading to a better customer experience. Development teams can work independently on different app functionalities, consequently shortening development cycles to get more features deployed in less time, which means the reaction to changing customer demands improves dramatically.

Also, since services are deployed in independent environments, scalability concerns are managed in a much more convenient (and efficient) way, and resilience is strengthened significantly because there is no single point of failure, as there would be with monolithic applications. Microservices provide a modern architecture for app development, which ultimately delivers the best experience for customers.

Applying microservices for retail

What does a microservice-based application look like in a real-world scenario? Let’s say an ecommerce application is being built. Microservices will greatly optimize the following challenges:

  • Dynamic product catalog: An ecommerce app might involve a large number of products (maybe from different suppliers) with changing availability. With each supplier and/or product category as a part of a microservice, it becomes easier and more efficient to manage and provide an always up-to-date product catalog for users.

  • Changing customer needs: A microservice-based architecture increases speed of development and testing, ultimately allowing new features to be deployed faster and enabling developers to quickly pivot to new customer needs. Different teams can work in parallel and independently, with little to no dependencies, rolling out or rolling back features as needed without risk.

  • Scale flexibly: Independently scale app functionalities up during peaks or down for valleys with on-demand cloud-based microservices.

The world before microservices

Before microservices were an option, the typical data infrastructure would look like a data access layer on top of a database in order to get all the datasets containing information needed for running the application, as seen in Figure 1. There would be many databases to pull data from and various information silos, making for a painful process. Business logic had to be generated to transform these datasets to perform specific functions, namely a product catalog, cart, checkout, payments, and the like. Before building any application, the relational data objects would need to be mapped out to match an object-oriented programming paradigm.

Figure 1: The monolithic application diagram before microservices

This is not easily scalable or flexible for modern applications because every change in a dataset needs to be pushed upstream, and every new feature request for the app implies a data schema change downstream. This complicates life for developers and makes adaptation to customer needs a nightmare.

Decoupled app functionality with microservices

With microservices, business functions are decoupled as much as possible in order to create a bounded context that is clearly independent of the others, meaning a failure or outage in one does not affect the others. This often means having a separate database per service, as seen in Figure 2.

Figure 2: A first approach to microservices

In this first approach to microservices, decoupled application functionalities can be developed, maintained, and scaled independently. However, having a separate database for each business functionality is not the ideal. It adds operational complexity, defeating the purpose of a microservices approach since maintaining and scaling a distributed system is not a simple task. But there is light in all of this: a middle ground between strong decoupling and operational efficiency can be found with MongoDB.

MongoDB and microservices

MongoDB is built under a number of fundamental technology principles that ensure companies can reap the advantages of microservices, specifically around a flexible data model, redundancy, automation, and scalability. MongoDB can be deployed in any environment (on-premises or cloud for example), but all industries are moving or have already moved toward the cloud, with its lower cost of ownership and flexibility. Retail is no exception.

The cloud is again the natural next step for microservices. It provides dynamic scalability and high availability, freeing teams of the operational burden of maintaining a distributed system in-house. This is why MongoDB clients are choosing MongoDB Atlas as their cloud database-as-a-service to deploy applications based on microservices.

As a step to modernization, MongoDB can be used as an operational data store, as seen in Figure 3. Legacy data silos are needfully connected via change data capture (CDC) and/or ETL processes in order to have an up-to-date copy of the data, stored as JSON documents. This is a first major advantage, since now applications can be developed against a data model that fits how developers think and code, therefore providing unprecedented agility to the development cycle.

Figure 3: Microservices with MongoDB, acting as an operational data Store. Applications can be developed taking advantage of its flexible data model and scalability

MongoDB Atlas allows for all of the benefits and flexibility of a fully managed, API-driven database. It allows for environment automation without dealing with every detail of database operation and scalability. This makes development teams more agile so that they can evolve applications at the pace customers expect and require today.