The evolution to MACH architecture

Good to know: This is a transcript of the Keynote by Christoph Hautzinger, our Managing Director Engineering, at the MACH Masterclass 2024.

The question of which architecture should be used to build software is just as much a philosophical question as the question of how to deal with technical dependencies. Approaches and solutions are a dime a dozen - and yet one framework is emerging that is proving to be particularly scalable and future-proof. We are talking about MACH. Because MACH makes things possible. We have outlined here in 4 evolutionary stages how existing systems can be converted step by step into a MACH architecture.

Dependencies within technical systems

Let's start with the question of how to deal with technical dependencies. You often see the following picture here: We have a component A and a component B, whereby B is dependent on A. This means that changes to A also require adjustments to B. Ideally, A would remain stable so that B can be modified more frequently. However, the reality is often different: An external system D (such as Typo3, a Symfony application, Magento or another vendor system) is in play. The code written within this system is always dependent on this external system. The problem with this is that the vendor system is constantly changing due to regular updates. These updates in turn often require adjustments to your own code.

Traditional monolithic systems

In traditional software architecture, we often find monolithic systems. A classic example would be a CMS such as Typo3, in which the entire business logic, presentation layer and data persistence are closely linked. This close coupling has several advantages, such as the easy use of existing frameworks and tools as well as fast results for developers, especially for beginners.

However, there are also significant disadvantages:

• High dependency: changes in one part of the system often require adjustments in several other parts, which makes maintenance and further development more difficult.

• Poor scalability: Scaling a monolithic system is more complicated as all components are linked together.

• Slow adaptation to new trends: Modern requirements such as Google's Core Web Vitals are difficult to implement as the entire system has to be adapted.

In the dynamic world of software development, flexibility is crucial. The MACH architecture (Microservices, API-first, Cloud-native, Headless) offers a modern solution for this. In this article, we look at the various stages on the way to MACH architecture and the respective advantages.

In our MACH check, all the lights are still red for the traditional monolithic system.

Stage 1: Decoupling the presentation layer

The first step towards MACH architecture is to decouple the presentation layer. The frontend is first detached and UI components are outsourced to a separate project. With the help of modern tools and techniques, developers can use modern frameworks and tools, which improves the developer experience.

The frontend can be provided as a static file via a CDN, which increases performance. Overall, removing the frontend has the great advantage of improved performance. Faster loading times through distributed provision via a CDN also improve the user experience. In addition, frontend development can take place independently of the backend, which increases flexibility.

However, this first stage is not without its challenges: managing a separate frontend infrastructure requires additional tools and knowledge. Furthermore, specialized frontend experts are needed for the increased technical requirements of frontend development.

In our MACH check, the headless traffic light is already green and API-first and cloud-native are still yellow. However, the microservices traffic light is still red.

Stage 2.1: Decoupling the business logic

The next step is to decouple the business logic from the monolithic system. The technical detail that is the focus here is the "inversion of control". This means that the dependencies are reversed so that the business logic is no longer part of the vendor system. In the application, this means that the requests from the front end are delegated to the business logic via small entry points.

The advantage of this decoupling is that changes in the business logic can be made independently of the rest of the system. In the case of updates, only the small integration points that delegate the requests to the business logic need to be adapted within the vendor system.

It should be noted that this inversion of control requires careful planning and expertise. Advanced software architecture expertise is also required to ensure that the business logic is properly decoupled and integrated.

However, the traffic lights in our MACH check remain the same as in the previous stage, as only the dependency between the vendor system and business logic is reversed.

Stage 2.2: Introduction of API-first and microservices

In the third expansion phase, the business logic is further outsourced to a microservice and provided via APIs. This means that the vendor system is only limited to the actual functionality and only has one responsibility. The desirable "single responsibility principle" therefore applies - because the fewer responsibilities a component has, the better. The API-first approach describes how the individual components communicate via clearly defined APIs. Each functionality is implemented as an independent microservice, which increases modularity.

The advantage of this approach is that APIs enable a clean separation of components and facilitate development through clear interfaces. Flexibility is also significantly improved: components can be developed, exchanged and scaled independently of each other.

Challenges can sometimes arise here too, as the management and documentation of APIs requires additional resources and tools. Different teams must also work in a well-coordinated manner to ensure consistent APIs.

In the MACH check, the microservices traffic light is now also turning yellow, which means we are moving more and more in the direction of MACH architecture.

Stage 3: Complete MACH architecture

The final stage is the complete implementation of the MACH principles:

On top of the use of microservices and the API-first approach comes the cloud-native infrastructure at this stage. The entire architecture is operated in the cloud in order to take full advantage of the cloud infrastructure. In addition, the front end is completely decoupled from the back end and communicates exclusively via APIs (-> it is headless).

This means that even the vendor can be replaced with a modern system in this evolutionary stage. This means that the "best of breed" approach is fully implemented: depending on the use case (e.g. for the content management system itself), various options can be examined and the existing solution can be replaced with the best one. The entire architecture is therefore highly flexible and can be easily scaled.

It should be noted at this point that the infrastructure is naturally quite complex. Managing a cloud-native, microservice-based architecture requires advanced knowledge and specialized tools. It therefore makes sense to have development expertise on board that is familiar with the latest technologies and concepts.

And in the MACH check, all the lights are now green - so we have finally arrived in the MACH world.

Conclusion

The transformation to MACH architecture can take place in several stages: from the decoupling of the presentation layer to the complete implementation of all MACH principles. Each stage brings its own benefits and challenges, but overall offers a more modern, flexible and scalable architecture. By introducing these concepts in stages, companies can future-proof their systems and respond more quickly to technological changes.