What is MACH architecture?

MACH architecture has become a red-hot trend in the enterprise world for the past few years. It's an abbreviation of Microservices, API-first, Cloud native, SaaS and Headless. Companies like Contentful, Commercetools, Algolia and a host of other commerce-focused services have popped up that preach an API, composable model of building systems.

It's a cool concept that our team implemented on a handful of headless Shopify stores and complex web applications. The general idea is that rather than committing to one platform that does everything, your system should be made up of individual services that all specialise in doing one thing really well.

If one service isn't cutting the mustard, it's no sweat. You can pick another provider that's doing a better job, plug its API into your codebase and continue meeting your customer's needs.

This sounds great and almost too good to be true. We're going to dive into a few of the caveats of MACH architecture and explain why all of the providers are so heavily geared toward enterprise clients.

MACH Architecture: Explaining the four principals

A system is only considered "MACH" if it ticks the four boxes.

Microservices

Microservices is another architectural concept that captures much of what MACH is about. Microservices are loosely coupled services that work together to achieve a set of functionality. Popular microservices are things like eCommerce & inventory management (Commercelayer, Commercetools, Shopify, Crystallize), search (Algolia, Elastic Search), content management (Contentful, Prismic, Strapi), product recommendations (Klevu, Search Spring), and tons of other areas.

The MACH alliance has a neat diagram on its website that captures a great overview that categorises the common microservices.

API-first

API-first is the idea that a system should provide a set of modular, well-maintained, and carefully architectured APIs that drive interoperability. The APIs in MACH architecture are the key to integrating with all the other pieces of the puzzle, so they're treated as the lynchpin.

This is different from a monolithic-style API that isn't modular, bundles a ton of different data together, and isn't really appropriate for sharing outside of the context of the application.

Cloud-native SaaS

Cloud-native SaaS is the concept of building an application intentionally to live in containers on a series of cloud-based servers rather than the traditional approach of installing an application on an on-premises server.

There are tons of great cloud-based hosting companies (AWS, Vercel, Netlify, Gatsby Cloud, DigitalOcean, Cloudflare, Linode, Azure) that have developed exceptional tools for services to scale up quickly at a global level. MACH takes advantage of these cloud facilities.

Headless

Being headless means there's no coupling between the frontend display layer and the backend. This allows a completely custom interface to be developed, while accessing all the power of the service's backend.

This concept is best demonstrated with something like a smart fridge that needs to run a custom frontend but also access backend functionality to drive its operations.

Challenges of monolithic architecture - the reason for MACH

Monolithic architecture is one where the entire application's codebase and services are packaged together for simplicity and ease of maintenance. This approach is excellent for most businesses. It's how the two biggest website frameworks are designed; WordPress and Shopify.

The straightforward architecture of a monolith leads to particular challenges that have caused headaches for larger, more complex businesses.

Coupled front and backend slows development

Making a change to the frontend of a monolith may stop delivering data to the backend, leading to a string of problems (breaking analytics, affecting other features that use the same data, and causing null state errors). Similarly, making a change to the backend may break the frontend.

As websites or applications with this architecture grow, the complex coupling between the front and backend can completely tank the development team's ability to implement quick changes.

If part of the application doesn't fit, you're stuck

Say your product requires heavy personalisation prior to purchase, like an individually tailored dog food regime, and you're using a monolithic platform like Shopify; there's no great way to bring in a more customisable cart and checkout service. In situations where you can make changes to fit a requirement, it often requires heavy development, and the results may not be amazing.

Being wedded to how a single platform handles particular operations is limiting for businesses that grow in complexity, especially if their user's demands and requirements are evolving quickly.

Popular monolithic platforms have their own limiting protocols

Shopify is built using liquid templating and WordPress is PHP based but has its own set of rules for how things need to be done. The opinionated way they force developers to build new stores is a dampener on productivity and limits what can realistically be built.

Smaller pool of qualified developers

Being forced to work in a particular way, with a specific (usually outdated) language or framework, is not conducive to how successful companies work. Talented developers typically gravitate towards the most mature and powerful frameworks, which also means that businesses working with monolithic applications have a smaller pool of qualified devs to pick from.

Benefits of MACH architecture

You can sum up many of the benefits of MACH architecture by saying it allows for the best software components for companies that need to stay ahead of the game.

Keep in mind that MACH architecture is focused on enterprise-level companies that turn over hundreds of millions of dollars a year and can find it difficult to change quickly with the amount of process overhead they have to contend with.

Work with the latest cutting-edge technology

The evolution of products over the past few years has been exponential. Just a few years ago, artificial intelligence had no place in eCommerce. Now, its reach has permeated through analytics, product recommendations, marketing and advertising.

An application built with MACH architecture can take advantage of these kinds of big technology leaps. The flexibility to swap in new services opens up an opportunity to trial the latest cutting-edge tech as it arrives.

Avoid traditional monolithic restrictions

There's no need to inherit unnecessary framework restrictions if the applications don't mandate it. The popular frontend frameworks used in MACH architecture (React, Vue, Angular, Blazor) also have limitations, but they're continually evolving and actively seeking to remove inefficiencies.

MACH architecture also bypasses the common problems with scaling and bottlenecks that can plague monolithic setups. Each microservice can provide focused optimisations through dedicated infrastructure.

For example, searching through a product catalogue of 1,500,000 products on Shopify would take... forever.

By comparison, Algolia has a mature, dedicated search service with a ton of infrastructure behind it focused on doing nothing but returning search results. It can execute these kinds of search queries in less than a second - often much faster than that.

Work with a pool of elite talent

Pretty much every professional wants to make their job easier. For developers, this equates to working with a language or framework that helps them solve big problems in more straightforward ways with less effort.

The technology that solves the problems with the least effort and with the best results is the one that big companies want to pay for, and as a result, it is the same technology that commands the largest pool of elite talent.

Rapid prototypes & reduced time to market

Plugging in a new service's API and rebuilding part of the frontend to accommodate the new functionality can happen relatively quickly compared with building the same functionality into a monolithic application.

Leveraging functionality through a series of flexible services and utilities and manipulating the way they work together within the context of an application is also an efficient way to get to market quickly.

There's no need to spend time reinventing the wheel, but at the same time, integrating API-first services through a MACH architecture isn't restrictive in the same way as adding plugins to a monolithic setup.

Meet evolving business requirements

What consumers expect from online retailers is wildly different now than before the panic. And thinking back even further to 2006, when smartphones hadn't arrived, customers' expectations and business requirements could barely compare with today.

The point is that business requirements in online commerce change quickly, and a MACH architecture provides a way for businesses to adjust their setup quickly.

Future proof

Since MACH architecture is built on the idea of modularity and interchangeable services, it's future-proofed in the sense that it can continually upgrade.

Using the analogy of a laptop vs a desktop computer, desktops are "future-proofed" because you can upgrade the individual pieces to keep the entire system fresh.

Limitations of MACH architecture

We have a lot of good things to say about MACH architecture since we're an official service integrator of some of the most popular MACH alliance services.

This is an unbiased review of the architecture, and there are better fits for some use cases. There are limitations of a MACH architecture that deter a lot of businesses. Most of them overlap heavily with the benefits, but with the context of money and resources, they become determents.

Complexity

MACH architecture is more complex than other architecture for a number of reasons:

• Requires a custom frontend
• Functionality is facilitated through API
• A number of different services involved
• Requires configuration of cloud infrastructure

A ton of minor workflow differences in a MACH setup add complexity, too - it's the difference between a website and a web application.

Organisational workflow changes

On the note of workflow changes, these can cause headaches for businesses wedded to how a particular technology operates. Changing processes and adjusting to a new workflow is never easy. Still, this can be a dealbreaker for businesses where "the whirlwind" is all consuming, and there's simply no overhead to adjust to a new way of business.

Jumping from Shopify to a MACH architecture means using a combination of different services, like a new CMS, eCommerce, analytics, and marketing, at a bare minimum.

Implementation and maintenance cost

Implementing a MACH application with an experienced agency is at least a $100,000 investment at the bottom of the scale. It takes months of careful planning, design and development.

The last implementation we executed took around 800 hours of effort. It's complicated work even for established agencies. We've jumped in to save a handful of headless builds going down the toilet because of poor organisation and optimisation.

Once the build is established, ongoing costs are geared towards enterprise clients that can easily afford them. For small to medium businesses, these costs often don't make sense. Contentful's paid plans start at about $500 a month but are limited; Vercel's sweet spot is $30k a month, and Commerce Layer's full commitment to clients comes at around the $80k a month mark.

Locked into a developer relationship

Companies that don't have the budget to pay for experienced developers shy away from an ongoing relationship which seems like an expense more than an investment.

Once a business has implemented a MACH application, the days of hiring a $15/hour Filipino developer to make "tweaks" is over.

A proper implementation shouldn't need a developer to be constantly involved - each service should provide the tools for non-technical users to do what they need. However, the philosophy backing MACH architecture is continual evolution to meet users' needs, which involves coding changes.

Enterprise focus & baselines

A lot of MACH alliance SaaS companies have a free or "self-serve" plan to cater to small businesses. But that's not where the magic happens. These companies were built to serve the enterprise. They acknowledge that Shopify and WordPress are the entry points and focus on the businesses that have outgrown those platforms.

A MACH architecture might not be a good fit if your business isn't profitable and growing. For example, some services have a minimum volume requirement they expect their customers to hit. If you're not there, that's fine, but they'll still charge you $1000/month.

Is MACH Alliance really necessary?

The MACH alliance is the governing body that is supposed to steer the principals behind MACH architecture but is it really necessary?

Well, probably not, but it's a great thing for the future of MACH services. The idea of Microservices, API-first, Cloud-native and headless is still relatively new in the world of technology. As ideas like this emerge, different businesses tend to head in their own direction and do things slightly differently. Committing to a centralise board (as hypocritical as that seems), will help align the best practices of companies committed to this architecture.

FAQ

I like to throw in some FAQs at the end of the article for SEO purposes but also to answer some questions that didn't fit into the flow of the main article body.

Q: How does Composable Commerce fit into MACH?

MACH is the broader architecture encompassing the internet of things, eCommerce, non-commerce applications and pretty much any software that meets the definition. Composable commerce is almost synonymous with MACH but dedicated to selling stuff online. It preaches the idea of dividing an eCommerce system into composable services connected through API with a custom frontend.

Q: Is MACH the same as headless architecture?

Not precisely, but headless architecture is a subset of theory within the MACH principles. A headless system doesn't need to rely on microservices to provide a complex experience - it can have a custom frontend and a complete backend with no additional services.

Q: Is MACH only for enterprise?

Absolutely not. MACH services' target market is enterprise, but that's simply because the small business to the mid-market realm is saturated with other great products. I've spoken with a number of MACH Alliance members, Contentful, Commerce Tools, Crystallise, Algolia, and Klevu, and they all agree that small to medium business is a perfect fit for MACH architecture.

Wrapping up

MACH architecture is the "next growth play" for a lot of businesses that find their technology starting to be a bottleneck. There's a learning curve involved in figuring out how to enter the scene, and hopefully, we've outlined some information that can be used to help your team make decisions.