Welcome to the fifth edition of Observed! Your weekly newsletter, where I bring you a tip you can implement in your infrastructure across many categories like AWS, Terraform and General DevOps practices. This week’s edition looks at MACH architectures.
What are MACH architectures?
A MACH architecture is a set of principles for modern application architectures. MACH is a relatively new term in the industry and is quickly gaining popularity because of the level of interoperability, scalability and composability. Many systems today are being built like lego pieces on cloud infrastructure which may be composed to create larger systems with well-defined boundaries thanks to movements like Domain Driven Design.
The MACH acronym consists of four distinct parts:
- M is for Microservices: Individual pieces of business functionality that are independently developed, deployed and managed.
- A is for API-first: All functionality is available on the API.
- C is for Cloud-Native SaaS: SaaS that leverages the cloud beyond storage and hosting, including elastic scaling and automatic updating.
- H is for Headless: Front-end presentation is decoupled from back-end logic and channel, programming language, and is framework agnostic.
The above definitions come directly from the MACH alliance.
What is the MACH Alliance?
The MACH Alliance is a not-for-profit industry body that advocates for open and best-of-breed enterprise technology ecosystems. The Alliance is a vendor-neutral institution that provides resources, education and guidance through industry experts to support companies on their journey.
What are the benefits of MACH architectures?
There are many benefits of MACH architecture, including the following:
- Faster development with reduced risk: Quickly bring ideas to market with a quicker route to MVP by utilising independent microservices which don’t affect the rest of the architecture negatively.
- Best-of-breed technology: Utilise the best available technology whilst integrating existing functionality where it’s appropriate to do so.
- Reducing the need to upgrade: Automatic and non-breaking releases eliminate the worry of disruptive upgrades as they communicate through your APIs, creating an excellent level of separation.
- Easy customisation and innovation: Quickly adapt to changing customer needs with the ability to change and innovate the customer experience constantly.
What are the drawbacks of MACH Architectures?
When evaluating any architectural design, we must consider the impacts of our decision to ensure that it’s the right one. MACH-based architectures are no different, and it’s not all sunshine and rainbows, especially for smaller businesses:
Microservice can be costly to develop and maintain, leading to a complex architecture. As more microservices are developed, additional technologies such as API gateways, service discovery, and service meshes are needed to manage them effectively.
Ensuring consistency and a well-designed API surface takes a lot of skill, experience and maintenance. Any API would also need to consider how to version the API to ensure that clients do not break.
On-premise deployments are still a problem, typically found in finance and government-related areas.
Cost. Whenever we talk about utilising the cloud and expanding into many microservices, there is always an inherent cost. Some companies can deal with these costs, but purse strings are generally tightening a lot at the moment.
Is a MACH architecture right for you?
Sitecore has compiled 11 great questions to ask before you consider transitioning into the MACH architecture strategy:
- Does it feature true microservices?
- Can you execute phased roll-outs?
- Does it support a best-of-breed approach?
- Is it built with APIs from the ground up, or has it adopted an API bolt-on strategy?
- Can you access quality documentation?
- How are integrations completed?
- Does it offer limitless scalability?
- Is the software delivered as-a-service (SaaS)?
- Do updates and upgrades happen via continuous delivery without breaking changes?
- Can you “see” the administrative or buyer interface without development time?
- Can you develop and deploy the user experience freely and flexibly?
My view on technology is that there is never a one size fits all approach, and MACH architectures are no different. From what I’ve seen, most companies are already ~75% of the way to a MACH architecture. It’s hard for anyone to realise the constraints of any given business from the outside, but these are some excellent principles to follow where we can.
I would love to hear your thoughts on these principals.
📣 Get the Weekly Newsletter Straight to Your Inbox! 📣
Don’t miss out on the latest updates! Subscribe to the Observed! Newsletter now and stay up-to-date with the latest tips and tricks across AWS, Devops and Architecture. Click here to subscribe and start receiving your weekly dose of tech news!