Les fondamentaux de l’architecture MACH

Qu’est-ce qu’une stratégie d’architecture MACH ?

Une architecture MACH est une approche de la conception logicielle qui met l’accent sur quatre principes essentiels – et probablement évidents – du développement logiciel moderne. Il faut distinguer légèrement sa définition de celle poussée par l’Alliance MACH. Si ce consortium (qui rassemble un bon nombre d’éditeurs) l’a popularisée, il pousse le concept un cran plus loin.

Les quatre fondations d’une architecture MACH sont les suivantes :

• Microservices. Une approche de conception architecturale qui favorise la partition des applications en de multiples services et composants que les programmeurs peuvent développer, déployer, gérer et mettre à jour de manière indépendante et isolée.
• API-first. Une méthode qui place les API au centre du développement logiciel et impose que les considérations liées aux interfaces de programmation (y compris les contrôles d’accès, les intégrations, les conventions de dénomination, etc.) soient abordées le plus tôt possible dans le cycle de développement. Selon l’alliance MACH, toutes les fonctionnalités d’une application sont également accessibles à travers ces interfaces.
• Cloud-native. Une stratégie d’hébergement qui met l’accent sur l’utilisation de plateformes et d’outils basés sur le cloud pour construire et déployer des applications dans des environnements distribués plutôt que sur des sites d’hébergement locaux.
• Headless. Ici, il s’agit de découpler le front-end d'une application de son back-end, ce qui permet aux équipes logicielles d'apporter des modifications aux composants frontaux tels que l'interface utilisateur sans affecter le back-end. Pour l’alliance MACH, cela veut aussi dire que l’application doit être agnostique des pipelines CI/CD, des outils et des langages de programmation.

Les avantages et les inconvénients de l’approche MACH

Voici quelques-uns des avantages d’une stratégie MACH :

• Flexibilité. Les applications MACH incluent, en principe, de multiples parties individuelles qui peuvent fonctionner et être modifiées de manière isolée. Par exemple, la nature faiblement couplée des microservices et le déploiement « cloud-native » peuvent apporter beaucoup de flexibilité à une architecture.
• Évolutivité. Le couplage lâche encouragé par cette méthode contribue également à soutenir l’évolutivité élevée des applications. Les composants individuels peuvent être mis à jour indépendamment, ce qui permet une croissance plus prévisible au fil du temps, une capacité accrue à gérer les charges de travail inattendues et la possibilité de conserver les ressources en période d’accalmie numérique.
• Fiabilité. Le déploiement cloud-natif et distribué permet également d’améliorer la résilience des applications. Si une partie de l’environnement hébergeant une application tombe en panne, tout ou partie de cette application peut rester disponible.

D’un autre côté, la poursuite d’une stratégie d’architecture MACH pose par ailleurs certains défis clés pour les architectes et les développeurs.

Cette approche implique notamment une complexité accrue concernant les exigences de déploiement et la gestion de la pile d’hébergement. De fait, les applications MACH ont tendance à contenir plus de pièces mobiles qu’une application monolithique traditionnelle, et sont presque assurément déployées dans un environnement cloud dynamique. La maîtrise des applications MACH nécessitera probablement l’ajout d’outils de gestion complémentaires, tels que des orchestrateurs de conteneurs sophistiqués et des passerelles API.

L’adoption de l’architecture MACH dépend de la réponse à une question essentielle. « L’amélioration de la flexibilité, de l’évolutivité et de la fiabilité des applications l’emporte-t-elle sur la complexité de gestion supplémentaire à laquelle vous devrez faire face ? » Bien que la réponse soit « oui » pour la plupart des équipes logicielles d’entreprise, les petites entreprises peuvent se demander s’il est préférable d’héberger les applications localement ou de conserver des services moins morcelés.

Comment bien débuter avec une architecture MACH

La meilleure façon de commencer avec MACH est d’évaluer les capacités de son architecture logicielle et de déterminer dans quelle mesure elles s’alignent sur cette approche. Étant donné que ce concept n’est en fait qu’une liste abrégée de pratiques de développement de logiciels modernes déjà très répandues, de nombreuses équipes logicielles utilisent déjà une architecture MACH sans même s’en rendre compte.

À tout le moins, la plupart des équipes logicielles utilisent probablement déjà un ou plusieurs éléments de la méthodologie MACH. Dans ce cas, cette évaluation aidera à révéler lequel des quatre composants une organisation pourrait négliger. Par exemple, si une organisation déploie actuellement des applications découplées en microservices sur des serveurs individuels, le déploiement de ces applications dans des conteneurs Kubernetes (potentiellement hébergés sur le cloud) serait un moyen de s’aligner davantage sur une stratégie MACH.

Une équipe logicielle qui utilise déjà des microservices et un hébergement « cloud-native », mais qui ne place pas encore les API au centre de ses processus et de ses plans de conception applicative peut bénéficier du déploiement de cette architecture. L’adoption d’une stratégie de développement API-first – c’est-à-dire une stratégie qui accorde la priorité à la détermination du comportement des API et à la prise en compte des exigences métier spécifiques avant le développement d’un projet – permettrait à cette équipe de faire un pas de plus vers l’adoption effective de MACH.

Toutefois, pour les équipes qui débutent réellement, comme celles qui utilisent encore un monolithe localisé, il est souvent plus judicieux de commencer par une conception d’une application headless. C’est généralement l’élément MACH le plus simple à mettre en œuvre et qui ouvrira éventuellement la porte à un partitionnement plus poussé des composants de l’application, par le biais d’une transition vers des microservices. Avec la moitié des éléments MACH essentiels en place, les équipes logicielles peuvent se donner le temps de poursuivre le déploiement d’une approche API-first, puis cloud-native.