MACH is about Quality Engineering.
Endless debates about Microservices have gone in the last years talking about their definition, granularity, and best-practices. These discussions can even make us lose sight of the motivations for building Microservices in the first place.
MACH appeared as a simple acronym standing for Microservices, APIs, Cloud-native SaaS and Headless—all elements of modular services that are composable and scalable. The shortened cool name with a reference to the “MAC” sound speed probably helped its spreading.
This article shares the why, the what, and how MACH fits in the Quality Engineering paradigm to continuously deliver Quality at Speed software. In the second part of the article, 8 success factors of MACH services are shared.
Follow the QE Unit for more Quality Engineering.
Why MACH?
Organizations have an increasing pressure of digital transformation to survive in an ecosystem of accelerated innovation and competition. The “Tech” wave is now reinventing every industry and sector through software, making its mastery a prerequisite for survival.
And transformation cannot wait for months. Companies need short-term gains while they build their digital platform with mid-term increments. The main challenge is for the first increments to be scalable, that is valuable on day one and reusable later.
Building today for tomorrow requires strong “by design” foundations.
Digital organizations are looking to offer their services to a set of users and partners where they can capture value through collaboration like in a marketplaces model. But ensuring that business services are by design pluggable and scalable for many consumers is not easy.
That’s where the MACH acronym takes all its place sharing the need Microservices, APIs, Cloud and Headless—4 key elements for building services that have a high degree of composability and scalability to support the business reinventions through software platforms.
What is MACH
MACH is an acronym extracting the essence of services to build for digital organizations, especially the ones that need most integrations within the ecosystem. It’s equally valid for business and internal services, like CI/CD platform to deliver self-service experiences.
The 4 key elements of MACH are:
- Microservices is about modularity
- APIs emphases the use of interfaces
- Cloud-native SaaS pushes for managed services
- Headless means no coupling to front-end(s).
Microservices in MACH are about building modular services that do one thing well aligned with the business domains they are solving. DDD is one practice that can be leveraged to build equilibrated services with “high cohesion and low coupling”.
APIs is about offering an abstraction through explicit interfaces that help to decouple functionally producers and consumers. Online versioning, documentation, and standard protocols like REST help to improve the connectivity of services.
Cloud-native SaaS put the emphasis on preferring managed services in the Cloud rather than building an internal solution that in the first stage can help, but do not scale with the necessary features, size, and maintenance when the organizations also need to focus on its business.
Headless follows the separation of concerns found in the other attributes of MACH. It is about offering technical APIs so that any consumers can use the services in its own context, being a headless workflow, a web, or mobile user interface. It maximizes connectivity with openness.
MACH for Quality and Speed
The value of MACH services starts by understanding the trade-offs of alternatives. One example is the legacy way to build a Content Management System (CMS) directly connected to a website, because at that time, e-commerce was only about the web.
The benefit is the simplicity of deployment of a single unit. But many problems arise when the business needs change, requiring adaptation of the core architecture, for example to connect the same services to a mobile application on top of the existing website.
One solution is to copy services and part of the back end for the mobile, being quite a risky operation in terms of data management and costs. Another one is to try accommodating the existing with a new channel. With a CMS that built only a web interface, it is a question of time before things start to break or become just too complicated to be changed in months.
The company then ends-up having to transform its content management services into modular services they can plug to different front ends. The organization can then plug the web and mobile app to the same services, and easily scale to omnichannel experiences offering a single back end that can be connected to multiple consumers.
One way to achieve that transformation in valuable increments is through MACH services, allowing to deliver small increments that can be connected in the ecosystem from day one. Adopting off-the-shelf solutions can also help to streamline the integration with packaged MACH services on specific business domains, like an omnichannel Basket.
Building MACH services from day one would have saved a lot of time in this example, avoiding the costly “architecture rework” that reduces the bandwidth available for business iterations.
MACH contributes to Quality with:
- Separation of concerns in layers and domains
- Platform offering modular business services
- Interoperability through headless APIs
- Elasticity improved with independent services
- Security favoring a “share nothing” architecture.
MACH contributes to Speed bringing:
- Automation of granular business services
- Modularity & composition acceleration
- Self-service with composable APIs
- Experimentation capability acceleration.
MACH Success Factors
MACH provides a frame of reference for key attributes of Quality at Speed microservices doing the “right thing”. But their effective implementation requires to ensure to make “things right”.
Here are 8 success factors of MACH services:
- Business-driven
- Start with macroservices
- Interoperable standards
- Cloud-Native for real
- Headless with a purpose
- Asynchronous over synchronous
- Retro compatible
- Available in self-service.
Business-driven
Teams can lose sight of the business focus while focusing on a technical acronym and a “MACH” architecture”. That distance then impacts the granularity and the potential value a service can deliver that end up focused on technology rather than the business.
A systematic business-first mindset is therefore important to keep as a team. Applying the methodology of Domain-Driven Design (DDD) is one good example to keep an alignment between the business domain and MACH services to be built.
When the team can hardly argue why they are building a service or unable to identify the users and purposes, it’s time to stop and get back to the business vision first.
Start with macroservices
“Microservices” is a word full of ambiguity. Some people would understand that all business functions should be implemented as a “functions” leveraging a cloud-native ecosystem of containers or even Functions as a service, loosing sight of applications perimeters.
The danger with a too granular approach is the overly complex set of services built, coupled with a high probability of failures in operating such services without the necessary automation, observability, and other requirements for that level of “grain of sand” complexity.
The first focus is therefore to build granular applications with a strong modularity between applications following the “high cohesion, low coupling” and “separation of concerns” principles. From there, the granularity to appear is already consider of microservices.
Interoperable standards
Exposing an interface with a functional decoupling is the right way to build services in a MACH service. But if the technology used is not a standard within the ecosystem, its potential for adoption drastically decreases in an ecosystem looking for fast iterations.
Ensuring to use interoperable standards in services is a requirement for Quality at Speed services. One recommendation is to use REST/JSON for most of the services fitting in the synchronous cases, adding events, and for some cases rely on a GraphQL federation.
And in some industry interoperable standards also act at the functional layer, for example with industry data dictionaries and interfaces formats. Carefully consider using these standards if that’s the case in your industry.
Cloud-Native for real
The word “native” has its importance in the “Cloud-native SaaS”. Many cloud adoptions are done in a “lift & shift” way to reduce the migration risk and increase the adoption. But that technique of migrations rarely creates nor benefits from “Cloud-native” capabilities.
Services that are cloud-native follow best-practice like the 12-factor application that for example externalizes all configuration, offers a portable deployment across environments, and scales with multiple instances.
MACH services lacking the cloud-native element will suffer from integration issues, slowing rate of iteration, and reach limitations in terms of scalability sooner or later. Knowing what is at stake, it is better to ensure cloud-native is a by design requirement.
Headless with a purpose
Headless services built for multiple consumers can become too large over time with the accumulation of small changes to accommodate for many consumers. The challenge is to keep the modularity in the mid-term, accepting sometimes to create another component.
The culture of “reuse” and “optimization” in IT from history can lead teams to try saving the cost of creating a new service by adding all changes into an existing service. That behavior demonstrates a lack of cloud-native culture and is dangerous in the mid-term.
The decision-criteria should not be the cost of creating the service, at this cost must be residual with the right automation in place. The main decision-criteria is about the modularity and decoupling principles, always knowing the users even being headless.
Asynchronous over synchronous
APIs can give the perception that all exchanges are done through synchronous API calls, biased with the standard of use of REST or previously, SOAP APIs in SOA architecture. The thing is that synchronous calls are rarely needed, and they rapidly reach limitations of scalability.
The success factor of MACH services is to be privileged by default asynchronous exchanges through web-hook and event-driven patterns that still offer services that can be embedded with APIs portals. Synchronous modes are then only by exception and real need
Retro compatible
Even with everything built and delivered in the MACH architecture principles, shipping changes with Quality and Speed remains the number one business objectives. And with an increasing number of users, that means mastering software changes.
Performing changes to MACH services requires to ensure retro compatibility through non-breaking changes patterns. The day a service is published and connected with other applications, being internal or external, changing will be harder.
The main issue is to migrate consumers from one version to another, as it involves costly coordination across distributed actors that do not have the same priorities. Minimizing the changes by design with retro compatibility is therefore a requirement.
Available in self-service
The digital competition requires the rapid deployment of successful offerings across the target scope of users and partners. The level of speed required the maximum of automation in every stage of the lifecycle especially for integrating and maintaining services.
Providing the business services in self-service requires to offer APIs in a user-friendly portal, with the proper documentation, use-cases and necessary information to leverage the services, and then start paying for it—all of that minimizing human interactions.
Delivering the self-service requirement requires to consider it from the design phase, inside the code repository ideally. For some services, it will also require an investment in technical writing with professionals of that area. After all, it’s about growing a digital business.
MACH impacts in MAMOS
The essence of the MACH acronym is simple yet powerful. The 4 building blocks of Microservices, APIs, Cloud-native SaaS and Headless are all valid requirements for you to consider to design and deliver Quality at Speed business services.
The main visible actors leveraging MACH are the headless CMS providers that had stronger market opportunities with companies deploying e-commerce, mobile, analytics & IoT experiences. But it’s already adopted by other actors, including successful startups.
MACH can be adopted by all organizations willing to progress with Quality Engineering. It’s not reserved to newly created companies, the most up-to-date with the technology stack—it’s about building valuable services that follow the MACH success factors.
Ready for MACH?
References
Composable Commerce Must Be Adopted for the Future of Applications. Gartner Research.
MACH Alliance Organization, MACH Alliance.
Marilia Dimitriou, What Is A Headless CMS? All You Need To Future-Proof Your Business In 2022. Moosend.
MACH architecture: Accelerate your commerce without limits. Commercetools.
What is MACH architecture? SiteCore.
MACH Architecture: Principles, Benefits and Examples. Vue StoreFront.
Antoine Craske, The Three Pillars of Quality Engineering Microservices. QE Unit.
Antoine Craske, Business Composability. Maximum Flexibility. QE Unit.