What is the MACH application architecture and is there a technological breakthrough there – besides PR and marketing
In 2020, when offline stores closed during the pandemic and everyone rushed to buy online, there was a demand for E-Commerce software solutions that could be quickly updated, developed and scaled to meet growing demand, an unpredictably changing market and the whims of customers.
This is where Gartner coined the new term “composable commerce.” The point was that customers of E-Commerce systems would not be strictly tied to one vendor, but could use in their trading infrastructure the best applications and modules available on the market from different manufacturers, glued together using an API. The goal is to take e-commerce to a new level, making both customers and the trading business happy. The idea, on the whole, is sound and ambitious.
Naturally, it was assumed that this would not be done by the customer himself, represented by a retail chain or a product manufacturer, but by the so-called Implementation Partner, or in our opinion, an invited system integrator. This point will be used later when creating the so-called MASN association, and I will talk about it below.
Also, it was assumed that composable applications and other software modules should have limited functionality provided at the microservice level and have interface points in the form of APIs. An example of such a composable module in E-Commerce is the product catalog search module. This could be Elasticsearch, Azure AI Search, etc.
Now we, in fact, have come to the emergence of the term “MACH architecture”, which is the technological basis of “composite commerce”. This abbreviation was first proposed by Commercetools, also one of the E-Commerce system vendors. Surprisingly, the term MACH (Mmicroservices, API-first Cloud-native, Headless) quickly took root in the IT industry for E-Commerce architecture. It is important here that MASN can provide omnichannel service for customers and helps to quickly implement various “hot” new products in online trading.
A headless approach in E-Commerce is needed for omnichannel service – this is when a client can start a purchase on a desktop, continue on a smartphone, then in a bot, etc. For developers, the Headless approach eliminates the need to support a set of frontends for different types of devices and different regional markets, which is also convenient.
If we talk about the declared implementations of the MACH architecture, all of them are for enterprise E-Commerce, and for very, very large companies. This list includes Nike, Puma, Spotify, Netflix, Uber (and without a detailed description of these projects, only about “improved” and “deepened”). The reasons for such a selective implementation of MACH are large budgets for integrator services, the difficulties of building IT systems for the level of large corporations, and many improvements when integrating the so-called “best of breed, best on the market” services and applications from different software vendors.
There are also difficulties with the implementation of information security in MACH. Distributed architecture based on microservices, clouds and headless frontend provokes additional security vulnerabilities, since each composable module or integrated external module/service can represent a potential point of attack.
MACH association as a method of fighting competitors in E-Commerce
In my opinion, the popularization and PR noise around MACH architecture is not only about technology, but also the repeatedly trodden path of creating various initiatives, the purpose of which is to differentiate from competitors and make money along the way by distributing “certificates of conformity” and similar mules.
The state of affairs in the enterprise E-Commerce market is such that all commercial and industrial large enterprises have had some kind of electronic commerce system for a long time. But, in the overwhelming majority, these are monolithic systems that are difficult to quickly update and develop. And these systems really need to be modernized. Therefore, clouds of E-Commerce system vendors and integrators hover around commercial and industrial companies in order to sell their products and services.
And here the technique of dividing suppliers into good and bad guys, similar to the “Green Agenda” with the notorious carbon footprint, works well. The main thing is to convince customers that vendors and integrators with the “MACH Certified Supplier” cartoon are bees with the right honey, and all other players in the market of software and services for E-Commerce are nothing more than a sad city.
Enough to visit MASN-association website, to ensure that the process for certifying and selling mulek “IASN compliance” is well established and operational. And if we go to cases page, then we will find no more than a dozen implementations in large companies, and none of the cases describes the complete MASN architecture. Somewhere they implemented microservices, somewhere they moved part of the system to the cloud or made a mobile version.
Does all this mean that the term MACH architecture is discredited and the architecture itself does not deserve attention? Not at all, in the combination of Microservices, API-first, Cloud-native, Headless there is a rational technological idea. Microservices have become one of the pillars of development today, and APIs and clouds are used everywhere. Except that Headless is a noticeably rarer technology, since not in all projects outside of E-Commerce this functionality makes practical sense and is in demand.
Likewise, an integrator without the “MACH Certified SI” cartoon is no different from one that has such a cartoon, since the development teams of both of them probably have skills in creating microservices and APIs, as well as hosting applications in the cloud.
Comparison of MASN architecture and monoliths
After the previous section about the MASN association and its trade in mules, I would not like to create the impression that MASN is only marketing. To be fair, it should be noted that almost any MACH implementation will be better than a monolith for the architecture of most IT projects.
Monolithic solutions (including E-Commerce), such as those from SAP and IBM, also have a right to life, but are more suitable for companies in the B2B sector, which require a high level of information security and full control over the IT infrastructure. In addition, they continue to work in the B2B sector because they usually do not require frequent changes to the application interface, endless expansion of functionality and constant updating of the user experience.
A small table will help you compare monolithic and MACH systems for functionality:
Monolith | MASN | |
Scalability | Fully scalable. If you need to scale or update a single feature, you will have to update the entire system. | Can be scaled step by step. Each module is updated separately without affecting other processes. It's cheaper, faster, and there's less risk of the entire system collapsing. |
Flexibility | Changing the functionality of the solution requires lengthy preparation. High dependence on suppliers (for purchased monoliths). | If you need to change something, it can be changed relatively quickly. For open source solutions, you can even modify it on your end and offer it to your vendor as a template or add-on. |
Technical support | Most often performed by the solution vendor. All parts of the monolith are interdependent, so completely independent support without a vendor is extremely problematic. | Each module can be fixed separately, without even contacting the software vendor. |
Safety | High level of security, with all data most often stored in one database. | High level of security thanks to separate frontend and backend. Access is possible by user roles. |
Payback time | Very slow innovation makes it difficult to break even. | Relatively quick change of all the functionality you need. |
Integration | Integration with other systems and solutions is difficult, sometimes to the point of “impossible”. | Thanks to APIs, microservices and clouds, it is relatively easy to integrate with other solutions. |
AI as a way to expand MACH beyond the E-Commerce sector
Agree that since the combination of microservices, API-First, Cloud-Native (and, possibly, together with Headless) is quite progressive, you should not limit yourself only to E-Commerce and PR around online trading and distribution.
Today, different teams are working to expand the areas of application of systems with MACH architecture through the introduction of AI. It appears that this will help make systems based on the MACH architecture available to a wider range of customers, including medium-sized businesses.
Developers integrating artificial intelligence into the MACH application architecture are, in a sense, pioneers, trying to bolt AI onto everything they can get their hands on. Something similar happened in the dot-com era, when there was wild enthusiasm for popularizing access to the Internet, implemented for almost any thing.
Here is a small list of those areas of AI implementation in MASN that can be found on the Internet:
1. Using Microservices for AI Functions. This is the most common direction, improving the functionality of products, although it does not directly contribute to the wider adoption of MACH in the market. AI functions can be implemented as separate microservices, each of which is responsible for a specific AI function. Examples are natural language processing (NLP), machine learning (ML), data analysis, hypothesis testing, etc.
2. API when interacting with AI services can be used to perform specific tasks by calling other microservices in the MACH architecture. The API-First approach in the MACH architecture makes it possible to integrate any services, including AI, relatively painlessly.
3. You can add and use cloud AI services to MASN, such as speech recognition, image processing, prediction, etc. from various providers. These services can be integrated via API into the main MACH architecture, also based on the cloud infrastructure.
4. AI can be used in headless application architecture to improve the user experience, for example, through on-the-fly content personalization. It is believed that analyzing user behavior and predicting their preferences helps to offer personalized content that better suits the interests of each individual user. I note that this is a controversial approach, since the user may lose variety in the content offered (just like if you once buy red shoes, then the personal offer will now only include shoes of that color).
Conclusion
The MACH architecture, based on microservices, APIs, cloud and headless architecture, looks like a very promising basis for creating flexible and scalable IT ecosystems. For its part, generative AI offers new opportunities to create dynamic, personalized offers for customers in the B2C and B2B sectors, as well as reduce costs (for example, to optimize content creation and translation, scale development/coding, etc.).
If we move away from the overly marketing interpretation of MASN, then it makes sense for system architects and analysts to pay attention to the MASN + AI combination as a technological basis for new or developing projects.
What do you think? share your constructive opinion)
