MACH est-il l'avenir de l'architecture IT ? Découvrez pourquoi microservices, API-first, SaaS cloud-native et headless sont des principes d'architecture IT à adopter sans tarder.
Tour d'horizon du mouvement MACH, de ses principaux atouts et de son impact à venir sur les CTO
Les attentes en matière d'ingénierie logicielle se sont profondément transformées au cours de la dernière décennie, sous l'effet du mouvement DevOps et de l'essor des technologies cloud, dont les fournisseurs sont désormais omniprésents. Le passage massif au télétravail a rendu encore plus essentiel l'allègement des dépendances entre ingénieurs, principale cause de retard dans les projets logiciels depuis toujours.
Selon une nouvelle étude, les responsables tech voient dans MACH (microservices, API-first, SaaS cloud-native et headless) l'avenir de l'architecture, et 80 % d'entre eux prévoient d'augmenter leurs investissements dans ce domaine au cours de l'année à venir et au-delà. Passons en revue les avantages des principes d'architecture IT que sont les microservices, l'API-first, le SaaS cloud-native et le headless :
Microservices
L'architecture microservices part du principe que plusieurs petits composants logiciels peuvent générer la même valeur qu'un seul gros logiciel monolithique. Mais le véritable atout du passage aux microservices, c'est le découplage du travail d'ingénierie. Désormais, chaque ingénieur peut se concentrer sur son propre composant logiciel au lieu de consacrer un temps considérable à coordonner un grand projet logiciel.
DoiT International est une entreprise 100 % distante : découper nos projets logiciels d'envergure en composants plus petits, attribuables à des équipes avec un minimum de coordination, présente donc des bénéfices évidents. Ce n'est pas une mince affaire, mais avec l'exigence de livrer de la valeur logicielle plus vite que jamais, il n'y a pas d'autre voie.
API-first
L'architecture logicielle API-first est quasiment incontournable dès lors que l'on adopte les microservices. Là encore, elle permet à de petites — voire toutes petites — équipes d'ingénieurs de créer des composants logiciels qui s'assemblent pour former un ensemble plus vaste, en permettant à leurs pairs de consommer le travail dans un modèle découplé. Pour les non-initiés, on peut l'expliquer par une analogie avec un tuyau : un moteur de voiture comporte une ouverture par où le carburant doit passer, et peu importe le type de réservoir, du moment que le diamètre du tuyau qui les relie correspond à chacun. Voilà une façon simple d'expliquer les API : le réservoir est fabriqué par une usine, le moteur par une autre, et la seule coordination requise consiste à documenter le diamètre du tuyau.
Software-as-a-Service cloud-native
Le Software-as-a-Service (SaaS) cloud-native est un autre pilier déterminant de ce nouveau monde de l'ingénierie logicielle 100 % distante. Le passage à l'ingénierie à distance a contraint les entreprises à repenser les data centers en cage fermée, accessibles uniquement depuis le bureau, pour permettre aux ingénieurs de travailler depuis n'importe où. Une fois ce cap franchi, de plus en plus d'entreprises ayant besoin de produire du logiciel ont compris qu'elles n'avaient plus à entretenir leurs propres data centers et pouvaient s'appuyer sur un fournisseur cloud pour gérer l'infrastructure physique à leur place.
De la même manière, une usine n'a pas besoin de produire sa propre électricité et peut généralement l'acheter à une compagnie du secteur. Cette accélération de la migration vers le cloud a permis aux fournisseurs cloud d'embaucher davantage et de créer plus de services en très peu de temps. Et comme de plus en plus de technologies IT existent désormais en version -as-a-service dans le cloud, les ingénieurs peuvent les expérimenter bien plus rapidement et à moindre coût qu'auparavant.
Avant, un ingénieur souhaitant tester une nouvelle base de données devait demander à une personne d'acheter le matériel, à une autre de l'installer dans le data center, puis à une troisième de mettre en place le système d'exploitation et la base de données sur ce matériel. Ce n'est qu'après avoir reçu les instructions d'accès qu'il pouvait enfin tester cette nouvelle base. Aujourd'hui, tout cela se fait d'un simple clic. Le cloud a évolué : de la simple fourniture d'infrastructure, il est devenu capable de livrer n'importe quelle technologie en un clic, offrant une flexibilité toujours plus grande pour choisir les meilleurs outils adaptés aux besoins d'ingénierie.
Headless
Le headless se marie parfaitement avec les microservices et l'API-first. De nombreuses offres logicielles modernes sont multi-têtes grâce à des backends API-first. Tandis que la logique métier la plus complexe s'exécute dans le cloud, les données qu'elle consomme ou génère sont disponibles via des API. Cela permet à d'autres équipes d'ingénieurs découplées de créer des expériences pour le web, le mobile ou le desktop indépendamment les unes des autres, avec une coordination minimale entre les équipes frontend et backend.
L'abondance d'offres SaaS cloud-native, ou technologies-as-a-service, permet de compléter ces expériences frontend par des technologies prêtes à l'emploi gérées par les fournisseurs cloud.
L'avenir de MACH
DoiT est une entreprise cloud-first et 100 % distante. Toute notre infrastructure est dans le cloud, et notre seule infrastructure physique se résume aux ordinateurs portables dont se servent nos ingénieurs pour exploiter les technologies cloud et créer les petits composants logiciels qui s'intègrent au grand produit de l'entreprise.
Il y a quelques années, lorsque notre produit était bien plus modeste, il s'appuyait fortement sur les technologies SaaS des fournisseurs cloud, ce qui nous a permis d'apporter une valeur considérable à nos clients avec une toute petite équipe d'ingénieurs et en très peu de temps. À mesure que l'entreprise et son équipe d'ingénierie se sont développées, il est devenu logique de créer des services additionnels sous forme de petits microservices qui s'intègrent au produit global, plutôt que de tout coupler dans un énorme magma monolithique.
À mesure que nous concevons des expériences toujours plus précieuses pour nos clients, il est pertinent de miser pleinement sur MACH et de rappeler en permanence à nos ingénieurs pourquoi cette approche est si importante pour nous en tant qu'entreprise. Il y aura toujours quelqu'un pour suggérer de revenir d'un ou deux pas en arrière, en adoptant une énième technologie que nous devrons maintenir nous-mêmes, ou en créant un énième service au couplage fort entre le front et le back, sans API. Ces choix ne peuvent que nous ralentir : nous préférons donc garder nos releases petites, fréquentes et porteuses de valeur, sans nous laisser embourber par des idées et concepts étrangers à MACH.
Notre entreprise n'est pas membre de la MACH Alliance pour le moment, mais nous saluons cette initiative. Populariser ces concepts et les faire adopter plus largement dans l'industrie ne peut qu'aboutir à une bien meilleure expérience logicielle pour tous.