If you haven’t heard of MACH, allow us to elaborate on what it stands for. By searching the internet, you may find that “MACH number (M or Ma) is a dimensionless quantity in fluid dynamics representing the ratio of flow velocity past a boundary to the local speed of sound.”
While that MACH is named after Moravian physicist and philosopher Ernst Mach, our MACH is from the Information Technologies world :)
MACH is an architecture that provides a future-proof solution for online retailers as it allows businesses to quickly adapt to any emerging technologies”. But in what exact way?
The abbreviation MACH is about:
- Microservice-based
- API-first
- Cloud-native
- Headless architecture of an application
As a rule, a Microservice is a standalone service with a single purpose. It can be understood as a separate application that serves some specific need. You can imagine a microservice-oriented application as an application that consists of a set of micro-applications grouped together.
A good example is the search functionality in the application. It can be developed as a part of the application itself (monolithic architecture). Or it can be built as a separate micro-application with an API and the possibility to connect to your system. The latter case is a classic example of a micro-service (basically, it’s a service not exactly “micro”, but within the scope of this topic, we may omit the specifics).
API-first means that the application’s architecture is built in a way that allows connecting other applications and services for making complex systems eventually. Imagine building a DIY mobile phone, starting from a base with no camera, no display, no speaker (and no OS :) ). Pretty useless, huh? But then, you can choose any of these components from any vendor that meets your needs. This architecture reflects the API-first idea to some degree. And getting back to the microservice definition – camera, display, and other components are microservices in this example.
Headless, in layman’s terms, means no UI/open to any UI. An example with a mobile phone shows the use-case of this strategy once again. No display and API-first means that you can connect any display to your phone. As you can see, the above three definitions of MACH go hand in hand.
With cloud-based architecture, you are not limited to a set of hardware for your system: you may run an application on a single PC/server or a predefined set of servers. In this scenario, you are limited by the hardware of these servers.To extend or enhance capabilities, you would need to replace the hardware with something more powerful.
In contrast, with cloud-based architecture, you have a million PCs/servers connected in a cloud. You have a predefined piece of the calculation power of this huge cloud, but you may extend it by involving additional computing power from the cloud. And for your application, it’s a seamless process.
Alright, let’s put away the phones and reflect on how all these ideas live in the eCommerce world. From the examples above, we may assume that a MACH eCommerce platform should have strong API coverage, the ability to connect any UI, have microservices as functional parts of the system, and have a possibility to be efficiently hosted on a cloud platform. If you believe that MACH solutions are the future and are evaluating Magento Open Source or Adobe Commerce platforms, the natural question might arise in your mind at this point: is Adobe Commerce MACH compatible?
Adobe Commerce’s ancestor, Magento 1, even though it was cloud-friendly to some extent, had pretty questionable API coverage, was far from headless, and didn’t have a clue about microservices. It’s not a surprise, since the platform was architected in 2007 and no one thought much about MACH back then.
In the year 2015, Magento 2 saw the light of day, and in the early versions (2.0.*) inherited quite a few approaches from its predecessor. But fortunately, things evolved over the years to follow.
How the modern Magento 2 fits the MACH definition
API-first?
One can’t definitively say that Magento 2 (Adobe Commerce) is API-first. But no doubt, it has a strong API coverage. Over the last couple of years, GraphQL API coverage evolved and paved the way for efficient integrations with 3rd party services and UI solutions. Among UI options, there’s a native PWA-studio kit from Adobe that communicates with the platform exclusively via API. As a result, we have a strong headless relationship between Adobe Commerce and PWA-studio.
Headless?
Does PWA-studio mean that Adobe Commerce is a headless platform? The answer is yes and no. It is definitely possible to connect an external UI framework that will serve as the storefront. However, the headless part of the admin functionality is still limited. Fortunately, there’s continued progress here, as more and more API endpoints allow managing your store. We believe that the headless UI for the Magento admin panel will become new standard over the next few years.
Cloud-based?
As for the cloud, we all know about Adobe Commerce Cloud PaaS, which is, technically, a cloud-based platform. The PaaS allows you to automatically scale your backend/database/storage when necessary (for example, during the sales period). There are still limitations from the underlying Platform.sh component that lies under the hood of Adobe Commerce Cloud, however, with the improved cloud architecture that is coming any day now, these limitations will be eliminated.
Microservice-based?
In the Magento world, microservices are quite a debatable topic. The discussion of evolving from the monolith to the microservice architecture has been going on for years, and it may seem that we haven’t seen much progress in this area over time. But is that so?
In recent years we saw a pair of services from Adobe released that connect to Adobe Commerce: Live Search and Product Recommendations.
Essentially these services are standalone applications that replace the standard Adobe Commerce search and recommendations functionality.
The applications are hosted completely separately from the Adobe Commerce platform in the Adobe infrastructure. So, if technically it is questionable whether the new search and recommendations are microservices, ideologically – they are. And I’m sure that shortly we will see more and more services from Adobe that may replace the monolith functional parts of Adobe Commerce. Moreover, with the new Mesh API you may connect your microservices to the platform in a seamless way.
So, answering the question of whether Adobe Commerce is MACH or not, I’d say it is closer to yes rather than no. Magento 2.0.* was about 30% MACH, but with Adobe Commerce Cloud, GraphQL coverage and standalone services, my subjective opinion bumps up its MACH-readiness to about 70%, and this will very likely go up year after year. Arguably, Adobe’s strategy is to fill all remaining gaps as soon as possible and close in on MACH-ready competitors like Commerce Tools.
What does MACH mean for eCommerce merchants, though? What are the upsides and downsides of MACH for eCommerce stores, and when is it smart to use it as an approach? That is a good topic for a follow-up article to come.
Meanwhile, I hope this one helped you understand “how MACH” is Magento :)
