For many businesses, competing in the digital world requires adapting and deploying updates to applications at a rapid pace. As a result, monolithic architecture is becoming a thing of the past for many teams, and taking its place are new approaches, like MACH architecture. While MACH is just one of several similar approaches, it’s an interesting participant in this movement that emphasizes four key areas:
- Microservices
- API-first
- Cloud-native
- Headless
Below, we’ll explore what MACH architecture is, as well as its origin and key principles.
What is MACH Architecture
MACH architecture is an approach to building applications that allows developers to build more reliable and usable systems by implementing principles that emphasize composability.
Origins and Philosophy of the MACH Architecture
The architecture eschews building applications as large, monolithic apps with the frontend and backend all living in a single project. Instead, projects utilizing the MACH architecture leverage microservices, APIs, headless CMSs, and cloud deployment platforms. MACH Architecture is primarily promoted by the MACH Alliance.
What problem is MACH designed to solve?
MACH is designed to solve the challenges posed by monolithic applications. But why is monolithic architecture a problem? Monoliths are a powerful force when a product is just getting started and trying to find product-market fit. Monolithic applications can be easily modified and redeployed in the beginning.
However, as they grow larger, and more teams start to work on a monolithic app, the benefits start to break down. This can lead to communication overhead for the team anytime a change has to be made to the application. If a change in one part of the application can have unintended downstream effects on other parts of the application, engineers on every critical component will need to be consulted to ensure that no business functionality will be disrupted.
Stay on Top of New Tools, Frameworks, and More
Research shows that we learn better by doing. Dive into a monthly tutorial with the Optimized Dev Newsletter that helps you decide which new web dev tools are worth adding to your stack.
How does MACH solve the problems of previous architectures?
Monolithic architecture breaks down because different parts of the project become tightly coupled. Making a change in one part of the application cannot be separated from the rest of the application. This means that a single change leads to the entire project needing to be tested and redeployed.
If the different concerns of the application are decoupled, then they can be worked on, tested, and deployed independently of one another. This can be achieved in many different ways by implementing composable architecture. MACH architecture is not just making the case for a composable architecture, though; it is also suggesting specific types of decoupled architectures and deployment paradigms (more on this later).
How does this relate to Composable Commerce or the Smoke Stack?
The great thing about good ideas is that they're guaranteed to be reappropriated multiple times over with different branding. MACH architecture is just one of many different brands for this new programming paradigm and larger movement away from monolith applications to more composable approaches. Other common terms include composable commerce, the SMOKEstack, and API-first architecture.
According to Sitecore, composable commerce is a development approach of selecting best-of-breed commerce components and combining or ‘composing’ them into a custom application built for specific business needs. Redmonk defines the SMOKEstack as Serviceful, Mashable, Open, K(C)composable, and Event-driven. Not to be outdone, Gartner suggests that the future of business itself is composable.
What does MACH stand for and why are these values important?
MACH stands for microservices, API-first, cloud-native, and headless. We will explore each of these virtues individually to explain what they are and why they are important.
Microservices - Individual programs delineated by business functionality
Microservices are an offshoot of service-oriented architecture, which emphasized having individual, discrete services instead of monolithic applications. Microservices take it a step further by advocating for even smaller, decoupled services that interact with each other through clearly defined APIs that define single responsibilities.
They allow for developing, updating, and scaling specific, independent pieces of an application. This reduces risk and impact if something does go wrong. Phased roll-outs can be executed for light prototypes and gradual replacement of services over time. The ability to slot in different pieces also enables selecting optimal approaches for different functionalities.
API-first - All functionality specified and exposed through APIs
Paul Graham said, ”an API is to a piece of software what falsifiable predictions are to a scientific theory.” This means that an API requires a clear definition of intended behavior from a piece of software. Inputs must lead to predictable outputs. Once an API contract has been defined, users can depend on that API always behaving the same way.
This predictability allows for building workflows and more complicated functionality on top of the baseline functionality. APIs are also beneficial because they can provide a wide array of pre-built functionality that can be reused from one application to another.
You may have also heard of the Jamstack, an architectural style originally defined by Netlify, which included JavaScript, APIs, and markup. The acronym is no longer associated with the term, but the Jamstack still lives on APIs. These APIs can expose functionality or content. There are now hundreds of different companies exposing APIs of all different types.
Cloud-native - Utilizes third-party infrastructure hosting providers
One of the biggest software trends of the last decade has been the move to the cloud. It has allowed for more flexibility and scalability for businesses of all sizes. This has been led by pioneers like AWS and imitators like GCP and Azure.
These companies rent out their excess servers to customers looking for computing, storage, and networking capabilities. Since AWS defined the cloud landscape, we have seen a number of "layer 2" clouds, which build services on top of the layer 1 clouds. These services can provide nicer UIs and simpler workflows for working with cloud services.
But regardless of which layer of the cloud you are using, there is a very good chance that you are not racking and stacking your own servers these days. Since keeping a global network of computers available, performant, and secure requires hiring an entire team of DevOps and Site Reliability Engineers, using the cloud can lead to massive operational cost savings.
Headless - Decouples the backend for flexibility in frontend development
To make a system composable, it is useful to separate out the presentation from the content itself. Headless APIs give the ability of consuming data from an API and displaying it with a developer’s tool of choice.
Whether using React, Vue, Svelte, Solid, or just vanilla JavaScript, a headless API can be consumed by any kind of frontend. This is useful for developers who want to use their own preferred tool, but it’s also useful if a frontend needs to be quickly swapped out for a different frontend.
As long as the backend is always exposing a clear contract through an API (as explained in the previous section), then the frontend can be easily replaced with another frontend accessing the same API. SaaS headless services can also do all of the work of maintaining the editing and content management UI for you, so that you can focus elsewhere.
You should also check out:
Who is using the MACH Architecture today?
Founded in June 2020, the MACH Alliance was referred to as ‘The Coolest Tech in Town Club’ by Forrester. The MACH Alliance has companies and individuals as members with over 50 member companies in three categories: vendors, system integrators, and enablers. MACH Ambassadors advocate for the architecture and are individual expert members with no ties to any of the member companies.
Conclusion
MACH Architecture is more of a descriptive than prescriptive architecture. It describes a shift that is already being observed in companies that are moving away from monolithic architectures. By decomposing their applications, companies find patterns that allow them to move faster and more reliably, which is essential in the modern landscape.
These patterns typically involve using APIs and microservices hosted in the cloud with a focus on a headless approach between the frontend and backend. By separating out the core units of business logic, teams can become more autonomous and confident in their ability to continually improve their own systems.
