Architecture MACH : Qu’est-ce que c’est et pourquoi la privilégier pour sa solution digitale ?

Concrètement, que signifie Architecture MACH ?

Globalement, MACH est un acronyme de la combinaison de 4 principes de développement d’architectures : Microservices, API First, Cloud-Native et Headless. Tout simplement.

Pour rentrer plus dans le détail :

Microservices	API First	Cloud-Native	Headless
C’est un ensemble de petits services indépendants qui peuvent être développés, testés et déployés indépendamment les uns des autres. Généralement, un microservice correspond à un domaine métier d’une application.	C’est le développement d’une interface logicielle qui permet de connecter un logiciel ou service à un autre service. On met en place une API pour échanger des données ou profiter des fonctionnalités que propose ce service. Cela est lié à un besoin de réponse en temps réel. Dans ce cas, c'est très courant de faire communiquer les microservices via des API.	C’est une approche logicielle qui permet de créer, déployer et gérer ses applications sur un environnement Cloud. Cela veut tout simplement dire déployer ses applications vers un fournisseur plutôt que de gérer soi-même son infrastructure. Mais c’est de toute façon ce qui se fait de plus en plus, même en dehors du principe de MACH.	Cette approche consiste à dissocier le frontend du backend afin de complètement séparer le cycle de vie logiciel et  les responsabilités. Cela implique d’avoir des roadmaps dédiés pour chaque partie. L’avantage est d’avoir deux parties qui évoluent et vivent séparément sans impacter l’autre. Par exemple, changer de technologie sur du backend n’impactera pas le frontend.

“Ces solutions permettent d’offrir aux entreprises de meilleures capacités d’agilité et d’être à l’épreuve du temps. Grâce à ce type d'architecture, les évolutions sont facilitées et plus rapides. Cela permet d’être concurrentiel et d’être à l’affût du marché et de ses changements.“

Quels sont les avantages d’adopter une architecture MACH (Microservices, API First, Cloud-native et Headless)?

Concrètement, l’avantage de ce type d’architecture, c’est l’avantage de chacune des briques qui la compose. C’est ça qui est intéressant.

Mais finalement, ce principe d’architecture existe depuis plusieurs années déjà ?

Effectivement ça existe depuis plusieurs dizaines d’années déjà. C’est très courant dans les projets digitaux de nos jours. C’est une architecture qui s’applique à divers domaines. 

 

Si elle s’applique à plein de domaines, pourquoi est-elle associée au e-commerce principalement ?

Honnêtement, je n’ai pas la réponse à cette question. De nos jours, c’est finalement une architecture qui est de plus en plus standard et qui n’est pas du tout restreinte au domaine de l’e-commerce, au contraire. Elle peut correspondre aux besoins de plusieurs domaines.

Par exemple : 

• Si on a besoin d’avoir des microservices car on a beaucoup de fonctionnalités différentes et qu’on veut les splitter
• Si on veut créer des briques par scopes fonctionnels séparés pour avoir une meilleure maintenabilité
• Si on souhaite avoir un scope défini de fonctionnalités et plus de séparation dans nos différentes briques

Et bien on va retrouver les principes de MACH. Les applications vont communiquer entre elles via une API ou un Message Broker. Celles-ci vont ensuite être déployées dans la solution Cloud choisie. Puis pour plus d’agilité, on aura un frontend dissocié du backend donc on retrouve le principe Headless.

Finalement, c’est un principe d'architectures standards qui correspond à beaucoup de besoins. Evidemment, elle correspond au besoin d'une plateforme e-commerce mais elle n’est pas réservée uniquement à ce domaine.

 

Du coup, pourquoi est-elle souvent utilisée dans le e-commerce ?

Le secteur du e-commerce évolue très rapidement. L’architecture MACH répond parfaitement à ce besoin grâce à son principe agile et évolutif.

Une plateforme e-commerce possède de nombreux canaux de vente différents : le site web, l'application mobile, la tablette dans le magasin, le magasin physique, les items à la caisse… 

Pour pouvoir faire évoluer leurs canaux de distribution rapidement, ces entreprises ont potentiellement besoin d’avoir plusieurs app avec divers front qui vont pointer sur le même back.

Elles peuvent ainsi les développer et les faire évoluer différemment et à leur rythme sans impacter l’une ou l’autre.
Il y a également les pays de distribution. Les entreprises du e-commerce peuvent avoir besoin d’avoir un logiciel de vente différent par pays ou par zone géographique.

“MACH leur permet de répondre à leurs besoins de découpage et d’évolutivité rapide.“

Dans les projets que tu mènes, tu privilégies ce type d’architecture ?

Notre équipe Studio bosse majoritairement sur des gros projets donc effectivement c’est ce qu’on privilégie.

Pour te donner un exemple, sur un projet pour l’un de nos clients, on avait une cinquantaine de microservices. Donc ça commence à en faire pas mal. Ceux-ci communiquaient entre eux, soit via des API REST, soit via un Message Broker. Parce que parfois il y avait des traitements asynchrones donc un Message Broker, comme RabbitMQ, était la meilleure solution pour ce besoin.

Tout était déployé sur le Cloud, notamment GCP et AWS. Rien n'était hébergé chez nous au Studio. Et évidemment, on avait des fronts Headless. 5 applications front différentes associées à des “back for front” en GraphQL. C’est typiquement le type d’architecture qu’on met en place pour répondre aux besoins de nos clients. Souvent liés à des besoins d’agilité, d’évolutivité ou de données en temps réel. Ces briques sont les solutions principales.

Selon tes retours d’expérience, penses-tu que cette architecture soit à conseiller dans tous les cas de figure ?

Non, pas forcément. Je dirais qu’elle est à conseiller sur des moyens et gros projets. Et encore, cela va dépendre du besoin stratégique qui se cache derrière le besoin technique.

Pour te donner un exemple. Aujourd’hui, je bosse sur un projet pour un client pour lequel on est 3 développeurs. Donc plutôt un petit projet. Et pourtant, on a mis en place MACH.

Tout simplement parce qu’on a 2 scopes techniques sur la partie backend, donc on a 2 services qui le font. Nous n’avons pas un seul monolithe qui gère toute la partie back parce que ça avait plus de sens de séparer les 2. D’un point de vue de séparation, de besoin et de logique métier, il était nécessaire d’avoir 2 composants séparés.

“Donc il n’y a pas de cas de figure précis, cela dépend réellement du besoin. Ce n’est pas une question de taille d'application, d’équipe ou de projet mais plutôt une question de séparation, de scope, de fonctionnalités et de besoin.“

Quand et comment se poser la question de passer à une Architecture MACH ?

Si historiquement vous avez un monolithe qui a énormément grossi et que vous avez une application beaucoup trop importante que vous n’arrivez plus à maintenir : il est temps de se poser la question de migrer votre architecture. Vos développeurs se marchent sur les pieds en faisant du code. L’équipe est trop grande et génère des conflits lors des pull request. Ce sont clairement des signaux d’alertes.

Il faut donc se poser la question : Est-ce que j’ai des scopes fonctionnels à découper ?
Si oui et bien j’ai donc des briques différentes qui peuvent être exploitées dans plusieurs services. Cela permettra de découper les équipes par scope, de travailler séparément, de mieux s’organiser et d’être plus productif. 

Il y a aussi la question de la scalabilité qui peut entrer en compte dans l’équation. Parfois, certaines de vos briques fonctionnelles ont besoin d’être plus disponibles que d’autres car elles sont majoritairement sollicitées. Imaginons 2 briques, la brique pour passer des commandes et la brique de gestion des utilisateurs. La brique pour passer des commandes est beaucoup plus sollicitée et donc doit être beaucoup plus disponible. Il faut par exemple 5 instances de serveurs qui gèrent les commandes et uniquement 2 instances qui permettent la gestion des utilisateurs.

Grâce à la séparation par scopes fonctionnels de l’architecture MACH, il est facilement possible de scaler vos services selon vos besoins.

Architecture MACH et Architecture Composable, si différentes que ça ?

L’architecture composable c’est le fait d’utiliser différentes briques qui existent dans notre architecture pour en faire une app dédiée à un besoin spécifique. 

Prenons l’exemple d’un site de vente en ligne qui possède de nombreux services. Ils décident de lancer une application mobile car ils se rendent compte que beaucoup de leurs clients potentiels commandent majoritairement sur leur mobile.

Grâce à l’architecture composable, ils vont pouvoir récupérer les briques disponibles et correspondantes à leur besoin pour mettre en place leur application. C’est comme prendre les ingrédients nécessaires pour faire une recette et laisser ceux dont on a pas besoin au frigo.

“Si on part de ce principe, pour moi l’architecture MACH est une architecture composable. Puisqu'il s'agit de mettre en place des briques fonctionnelles, qui correspondent à un besoin et qui communiquent via des API. C’est exactement le même principe.“

Conclusion : réussir sa migration vers une architecture MACH performante

La première chose à faire lorsque l’on souhaite passer à une architecture MACH c’est de dessiner le diagramme d’architecture et bien définir les scopes de chacun des microservices. Je pense personnellement que c’est le plus compliqué à faire. Bien découper ses microservices.

La façon de communiquer entre eux via des API, Messages Broker ou autre, c’est plutôt standard. Ça demande généralement moins de réflexion stratégique.

Puis pour le déploiement dans le Cloud, le mieux c’est de se faire accompagner par quelqu’un qui maîtrise le sujet. Potentiellement avoir un collaborateur DevOps dans son équipe ou avoir des personnes à l'aise avec le sujet. Si vous n’avez personne qui a ces connaissances, c’est important de s'entourer des personnes qui pourraient vous aider.

La réussite de ce projet c’est d’y aller étape par étape. D’être sûr de ce que l’on veut d’un point de vue technique. Et de choisir les technologies adaptées au besoin. Puis évidemment, de s’entourer de collaborateurs compétents et en maîtrise du sujet.

Marie Minasyan
Architecte
@Eleven Labs