--
In 2020, our (or at least mine) LinkedIn timeline was full of it: MACH this, MACH that, MACH … Every digital professional seemed to talk about it, and so were we.
I expect that 2021 won’t be any different, and MACH will continue to grow and accelerate.
So what’s the fuss all about?
In this article we explain what MACH is, what benefits it brings and what it means for your organisation when you embrace the approach. And we did not succeed with keeping it short ;-). But there is a lot to say!
For the last few years, the digital experience & commerce platform industry have been undergoing a big transition in terms of how those platforms are offered to their customers (usually big companies). Moving from ‘suites’ to ‘stacks’ is a commonly heard expression, and systems in this category are identified as MACH systems — which stands for the technology and principles they are built with: Microservices, API-First, Cloud-Native and Headless.
At Lab Digital we have been building MACH-based platforms for a number of years, and closely follow the industries developments. We’ve noticed a big change in terms of acceptance of these types of solutions — from being very niche a couple of years ago, to more and more acceptance of them today.
The last year especially, a lot of things have happened. commercetools being positioned as a Leader by both Gartner and Forrester, signals a change in how the industry looks at these types of technologies. Or as Forrester describes it: a fundamental shift in the commerce technology industry.
The general consensus around MACH systems is that systems that are comparable to how commercetools is built (and cloud-based SAAS solutions in general) are the future — according to the analysts.
Feature-wise they might still lack features compared to legacy platforms. However, architecturally they are fundamentally different and bring in numerous advantages that are simply not possible/achievable with ‘old’ solutions. In our view, MACH solutions provide a level of stability, extensibility and future-proofing (is that a word?) that cannot be met by traditional solutions — even though some might claim they can. Though you must be prepared to make some investments, before benefiting from all of that.
As Lab Digital’s CTO, my focus goes largely to these types of developments — both from a practical perspective with being strategically involved in our next-generation builds/projects, and an advisory perspective: many (potential) clients ask us for guidance on building their MACH ecosystem. So we have some thoughts (and tools) around it, which we will talk about in this article.
In this article we will analyse what it means to build digital platforms using modern technologies that fit the MACH pattern. We will look at decisions you will need to make as well as capabilities you need to have (which have impact on your organisation).
MACH is an acronym for systems and services that adhere to ‘modern architecture’ practises that the industry has adopted (introduced by commercetools and recently anchored in the MACH Alliance), and stands for: Microservices, API-First, Cloud Native & Headless.
Any modern SAAS vendor could adhere to this patterns and make their service available in a way that their customer can consume the services through a web service interface (REST, GraphQL), without having to worry about scaling the platform, upgrades that might be implemented, securing the platform, etc. All of that is outsourced to the vendor of the platform, which in turn most likely outsources a lot of their work to an underlying cloud infrastructure vender, such as Google Cloud Platform, Microsoft Azure or Amazon Web Services.
MACH systems are modern SAAS services, that you use to compose your digital experience & commerce platforms by leveraging their APIs.
On top of these modern systems, companies are able to build digital experience & commerce systems, which the industry also has invented a name for: composable commerce. In other words: building modern digital experience & commerce platforms becomes a matter of composing (or: orchestrating) the right MACH services.
Let me give you our perspective on MACH’s building blocks below.
Microservices
The use of microservices architecture is considered ‘best practise’, though opinions vary about the granularity of these services; ‘Macro’-services being a perfectly sensible solution for certain use cases.
We see microservices as the ‘glue’ that fits the different MACH services together with each other, or with your legacy platforms — i.e. a microservice that submits an order to an order management system once it receives an order event from your commerce platform.
Or for business users: a microservice encapsulates a specific feature or functionality, in a given area, and not more than that. By having clear boundaries, these microservices can become the ‘lego blocks’ to build your solutions with.
Microservices are the lego blocks that you compose your applications with.
The idea is that by using microservices, one is able to build teams around individual services (or domains), gaining the ability to scale and develop these individually, with little dependency on each other. One team could even manage more than one microservice.
Or, to put it another way, MACH architecture means no more monolithic applications.
In any case, we believe that the architecture you choose should fit the problem you have, because they all come at a cost. Sometimes that means microservices, sometimes a bit more macro, and yes, sometimes even a monolithic architecture is the best way to start a new project.
That also means that building a system using MACH components is in itself not a solution you can simply pull off the shelf and start profiting from. There are still decisions to be made, depending on the case you have.
API-First
To us, the declaration of API-First (or API-Only) might be the most important feature of MACH architectures. My interpretation of this is as follows: (almost) everything you do against the platform can be done through an API. And that includes deploying and tearing down new instances of the platform, applying certain configuration or creating data types within the platform, etc. Anything to use the platform, both for end-user functionality as well as working against the platform as a software/cloud engineer, should be doable via its API.
Being able to do everything via the API also means that you can configure the platform through it. And that is exactly what drives the ‘infrastructure-as-code’ approach that you see a lot at cloud providers such as AWS and Azure. And we’ve translated this approach to comercetools, by creating the Terraform Provider for commercetools: because all configuration for commercetools can be done through the API, we are able to completely codify a complete commercetools environment using Infrastructure-as-Code.
API-First means that all interactions with a MACH system, go primarily through its API
In other words, because these services have an API to facilitate any interaction with them, we are now able to automate large parts of setting up the platform, and more importantly: do this in a ‘self service’ fashion, without needing the vendor to do it for us. And as a (sort of) side-effect, these platforms tend to be very open and easy to integrate in any way you want.
Particularly interesting about this is that MACH-vendors tend to keep a ‘single version’ policy of those APIs. “APIs are forever” is a commonly heard expression we hear among them. This means that updates/upgrades of your systems are a thing of the past.
All of this is delivered and scaled on modern Cloud services, such as AWS and Azure, which makes the platforms very scalable — taking away the need for yourself to maintain, secure and scale the underlaying infrastructure, which brings us to the next topic: Cloud Native.
Cloud Native
The cloud has only existed for a bit over a decade (2006). However, it has fundamentally changed the way we (can) engineer software, by providing services through APIs, that can be leveraged from anywhere, by anyone.
The resemblance between cloud infrastructure providers and MACH systems is undeniable: MACH vendors seem to borrow many principles that Cloud Infrastructure vendors tend to follow — primarily AWS has been a key driver for this, instigated directly by Jeff Bezos.
Today, building platforms in a cloud native way, means much more than just renting a virtual machine in the cloud. It means leveraging the many services that the cloud has available, for you to consume just via API call. Leveraging those services in the most extensive way, means that in terms of managing, scaling and securing your platform, most of the tasks are handled by the cloud vendor, allowing you to focus on solving your customers’ problems instead of worrying about infrastructure.
Cloud Native means leveraging the many services that the cloud has available
MACH systems are built on these principles and leverage services available in the cloud, to deliver their system to their customers (and their end-users).
In turn, MACH system providers provide the same characteristics to their clients that cloud infrastructure providers do: they provide the infrastructure with guarantees in terms of scaling, securing, ongoing improvements and innovations. Customers using MACH systems can therefore focus on the experience that they want their customers to have, instead of worrying about the CMS, commerce or search platform underneath (let alone the cloud infrastructure underneath that, that powers the MACH service).
Headless
Then the last piece: Headless. This largely describes the decoupling between front-end user interfaces, and backing services.
MACH systems do not provide a built-in front-end. They might provide example sites built on top of their API, to get started with, but the idea is that they don’t have a head packaged within the system, to allow for any user experience to be built on top of it — and this user experience can live anywhere: it can be a typical website, a mobile app, a chat bot interface or even an infotainment system residing in a car. And even digital personal assistants can theoretically leverage the APIs directly, to interact on the users’ behalf.
Headless means that front-end touch points are decoupled from the back-end — made possible by being API-First
Headless is not exclusive to MACH systems. We see many systems available that are not MACH but are, in fact, Headless. Usually this means that the software vendor has decided to build an API on top of their existing system, to allow their customers to build any user experience on top of this. And for many use cases, using that approach makes sense.
In our view, the two most important aspects of MACH systems are the facts that they are API-First and Cloud Native. Both imply a modernness and future-proofness of the system, that can’t be achieved when not having those characteristics.
The other two aspects of MACH, Microservices and Headless, are either a design decision in your project that might make sense or not (microservices), or are already implied by the other aspects: API-First is Headless by definition.
Perhaps the marketing people liked MACH better than MAC, or AC :-).
Building your next digital commerce platform using MACH technology is not simple and you need to be prepared to make several investments. Not only in technology, but mainly in your engineering culture and organisation. You need the right mindset in order to be successful with MACH and get a return on your investment.
In order to profit from a MACH approach for building your digital platforms, these are areas that should be part of the digital strategy of your organisation.
To name a few;
Agility in your engineering organisation is important. Combining that with a high degree of automation and a DevOps mindset in general, is essential.
Infrastructure-as-code is a foundational principle for building your MACH ecosystem. Both your cloud infrastructure as well as headless services (like commercetools, but in the future probably also other services that fit this pattern).
Using (and knowing how to) a high degree of cloud native services that are provided as-a-service and managed through automation, will provide a lot of benefits in terms of scalability, security and resiliency guarantees.
Sometimes, you need a micro services architecture to deal with discrepancies as well as distributed development & extensions to MACH technologies. In general a micro services architecture, and particularly when using serverless technology, plays nice with MACH services.
Having a zero-downtime & blue/green deployment model for a microservices architecture is important to succeed; releases can be done by any team, during any time of the day — this should not impact the end-user.
Having a clearly defined and mature, engineering operating model for patterns used throughout the system, supporting different programming environments, will help you build and maintain your platform in a consistent manner.
CI/CD to automate deployment of all components of the ecosystem is a must; CI/CD is essential to deliver a larger distributed system, which MACH architectures are by definition.
Chances are you need to support and orchestrate different cloud and SAAS services, including future services that need to be integrated at a later time. So having a clear vision on how to manage these, will help you organise your teams.
Which brings us to loose coupling with SAAS services, that you manage in a consistent way, as part of the ecosystem — and this includes ‘development environments’ that will soon consist of a set of distributed SAAS services, combined with self-built microservices that extend/augment these.
These are practises that are most likely already present at your organisation in some form. When embracing MACH technologies, it is time to shift the adoption of those practises into the next gear! When implemented right, the benefits will be noticeable throughout all of your digital initiatives.
The first thing to debunk is that platforms you build yourself using MACH technologies need to fit the MACH pattern themselves. This is not the goal and is in most cases not necessary. After all you are not building a B2B SAAS service for public usage. You are merely ‘using’ MACH-based systems to accelerate and future-proof the platform you build on top of it.
Each MACH vendor provides only a piece of the puzzle, and you select the right pieces and lay out the puzzle yourself.
That being said, a lot of MACH principles can definitely be used and are more or less incorporated when you use MACH technologies in combination with a Cloud Native approach for your own additions on top of those, including the way you orchestrate platforms through infrastructure-as-code.
When talking about building a ‘modern DXP’, we can identify a couple of different types of systems that you use.
MACH services: SAAS services that provide a particular set of features (i.e. digital commerce, CMS, search, customer identity, etc) that are cloud native and exposed via an API.
Bespoke services that interact with and extend the SAAS services, which power the user experiences built on top through custom APIs, but for example also facilitate integration with other systems.
Front-end user experiences that the end-user actually interacts with, built on top of the MACH services and Bespoke services that you’ve added yourself.
As you can see, building a modern DXP requires many different components that you need to integrate with each other. Each MACH vendor provides only a piece of the puzzle, and you select the right pieces and lay out the puzzle yourself, in order for it to become your modern and future-proof DXP.
While individual MACH technologies are great pieces of software to use/consume, by themselves they won’t make you any money or improve your customers experience. It is the combination of those tools that leads to that. And how that is done, is usually determined by your Systems Integrator, as there is no ‘standard’ for this.
As the technologies are mostly new to the integrators as well and require a high level of competency in modern engineering practises, the chances of projects resulting in MACH-spaghetti, are quite big.
Composing a MACH system is not only an architecture matter, but has fundamental impact on the way you work as an engineering organisation, including the way you collaborate with clients.
In order to manage MACH platforms as a whole, we think the MACH industry is in need of broader standardised way of orchestrating more services like that, to prevent MACH spaghetti, with corresponding business outcomes.
Orchestrating MACH ecosystems is an area that we have been working on for the past couple of years, and we have developed our own tools around as well. That resulted in our own framework to solve many common issues with building your MACH platform. And in our next blog post we will talk about that!
With MACH we think the industry has adopted a model that is truly different, and will allow for a much higher pace of innovation, while at the same time requiring a much lower maintenance burden and less need to replace these platforms every X years.
Adopting it however, means you have to go through quite a steep learning curve, with many companies still only in their infancy when talking about adoption of Agile, Cloud or DevOps practises, let alone micro services.
Selecting and integrating a set of MACH technologies is something not to underestimate. It can become a mess quite easily and requires organisational change as well. But if done right it can give you a solid foundation for the future.
Currently the industry does not offer much guidance or standards on how to compose your MACH systems. And this is absolutely needed we feel, as that is what makes or breaks your MACH project. To solve this, we’re committed to sharing our tools and ways of working the upcoming months to take MACH adoption to the next level, by introducing a framework that solves many of the needs when building MACH-based platforms.
Personally, I believe that building digital commerce and experience platforms using MACH technology will have a big role in the years to come. The time that ‘every platform is unique’ is long gone, with cloud services and their APIs being very mature and providing the ability to build pretty much any user experience on top of them. And at the same time offering you ‘one way’ to do that, which allows for standardisation and automation of many things that used to be ‘custom’.
This allows us to accelerate the creation of value for our clients, and at the same time create longer-living platforms and products for them. However, at the same time it is also quite demanding for engineering organisations, that need to be aware and up to speed on many of todays technologies. Lab Digital being a young company makes this slightly easier, because of our ‘born with’ cloud native mindset and many patterns and practises that we have been applying since we’ve started.
I’m looking forward to the further developments in the industry, in which we as a company are invested as well. And we will continue working on creating tools and methodologies to simplify and accelerate building MACH architectures.