Micro-apps et microservices : ce que les développeurs doivent savoir
À première vue, différencier les micro-apps, ou micro-frontends, et les microservices consiste à comparer le front-end et le back-end. Ce serait trop facile s’il fallait s’en tenir là.
La décomposition d’une application en composants fonctionnels plus petits est un moyen efficace de réduire la complexité des processus de développement et de mise à jour. Chacun de ces éléments peut être autonome et ne comporter que quelques lignes de code, sans perdre la logique métier sous-jacente de l’application.
Aujourd’hui, il existe deux approches distinctes que les équipes de développement peuvent utiliser pour réaliser ce type de décomposition. L’une d’entre elles consiste à intégrer le développement de microservices, qui vise à transformer des applications encombrantes en collections bien organisées de logiques fonctionnelles en arrière-plan. L’autre, le développement de micro-apps, permet aux équipes logicielles de décomposer l’interface utilisateur d’une application en composants fonctionnels.
Si de nombreuses équipes ont tout intérêt à adopter les deux techniques, il existe néanmoins des différences majeures entre les deux, qu’il est important de connaître avant de se lancer. Passons en revue ces différences pour mieux comprendre quand, pourquoi et comment ces approches de conception d’applications sont efficaces.
Qu’est-ce qu’une microapplication ?
Une microapplication est conçue pour accomplir une seule tâche liée à l’interface utilisateur. Plutôt que de réécrire le même élément d’une UI pour une application, les développeurs peuvent configurer une microapplication existante pour répondre à leurs besoins. Cela permet de garantir la cohérence de l’interface utilisateur et offre un moyen rapide d’étendre ainsi que de personnaliser l’UX.
Les développeurs conçoivent des composants de microapplications partageables pour les réutiliser dans plusieurs interfaces d’applications. Dans certains cas, cela peut également contribuer à minimiser le temps passé à gérer la conformité et les vérifications de sécurité. L’efficacité induite par cette méthode permet aux équipes de consacrer plus de temps à l’ajout de nouvelles fonctionnalités et à évaluer les feedbacks des utilisateurs.
Dans la solution Workspace de Citrix, les micro-apps correspondent à deux composants : les notifications et les pages. Les notifications sont des alertes automatisées liées à des modifications ou des suppressions d’enregistrements dans une base de données. Les pages sont des micro-apps correspondant à des actifs spécifiques : des formulaires, des tableaux, des contenus statiques, ou encore des fiches d’information. Le tout permet de développer des processus tels les demandes de congés, l’envoi de ticket à un service IT, traiter des tâches dans un agenda, approuver des factures, etc. Ce n’est pas l’usage le plus répandu.
Les micro-frontends, la raison d’être des micro-apps
Les micro-apps sont majoritairement des micro-frontends. Par exemple, la page web relative à un item présent sur un site d’e-commerce peut être composée de plusieurs modules pour afficher la galerie de photos, le prix, ainsi que les recommandations liées à un produit.
Si les micro-apps peuvent servir toutes sortes d’interfaces utilisateur, de nombreux cas d’usage tournent autour des réseaux sociaux et des applications de messagerie. Par exemple, Google Hangouts, WeChat et Messenger mettent en œuvre un nombre considérable de microapplications.
Qu’est-ce qu’un microservice ?
Les microservices font référence à une approche architecturale qui divise les applications complexes en collections de services légers et faiblement couplés. Plutôt que d’interagir directement, ces services communiquent principalement par le biais d’un mélange d’API, de déclencheurs d’événements et d’autres composants d’intégration. L’indépendance que favorise ce style de conception permet aux équipes de développement de créer, de modifier, de mettre à l’échelle et de déployer des services individuels et des ensembles de fonctionnalités de manière isolée, et peut également fournir des niveaux accrus d’isolation des pannes et de résilience.
Les microservices étant censés s’aligner sur une seule responsabilité ou fonction commerciale, les principes de conception associés imposent que les services individuels demeurent frugaux. À cette fin, de nombreux experts soulignent que ces services doivent conserver aussi peu d’informations d’état que possible. Si des informations d’état persistantes sont nécessaires, il est recommandé de gérer ces données via une couche d’abstraction, telle qu’un proxy latéral.
Aujourd’hui, le cas d’usage typique des microservices est le remaniement des back-ends d’e-commerce, autrefois grevés par des réseaux complexes de processus commerciaux et de logique fonctionnelle. De multiples organisations utilisent aussi les microservices pour réorganiser les applications internes liées aux finances et aux ressources humaines, ainsi que pour construire des systèmes sophistiqués de traitement des données en temps réel. En plus de cela, un nombre croissant d’équipes de développement emploient cette architecture pour propulser leurs projets IA et IoT.
Micro-applications et microservices : quelles différences ?
La principale différence entre les microservices et les microapplications réside dans leur échelle relative et leur placement au sein de la pile. Une collection de microapplications ou de micro-frontends résidera et fonctionnera dans la partie frontale d’une infrastructure plus vaste et globale basée sur une architecture de microservices. Les microservices, quant à eux, servent principalement à animer des éléments tels que les processus de communication et d’extraction de données en back-end.
Les micro-frontends viennent répondre à un problème spécifique. Souvent, les entreprises commencent par « découper » le back-end monolithique en microservices afin de gagner en efficacité et en résilience sur les modules critiques d’une application.
Cette adoption des microservices, représente généralement une restructuration complète de l’architecture logicielle et des stratégies de développement d’une organisation, en particulier pour les grandes applications legacy. Ce processus peut être complexe, long et coûteux.
La plupart du temps, les entreprises conservent leur front-end monolithique, par souci d’économie ou encore pour ne pas provoquer d’interruption de services, d’un passage d’une architecture à l’autre. Or le risque de rencontrer des problèmes de performance ou d’accès n’est pas nul quand l’application est sollicitée par un grand nombre d’utilisateurs. C’est là qu’interviennent les micro-frontends. Si l’un d’entre eux « tombent », la fonction desservie sera indisponible ou altérée, mais l’application restera en grande partie opérationnelle.
Les micro-apps, une simplicité toute relative
Avec une architecture micro-frontend, une application web ou mobile peut se composer de plusieurs microapplications qui sont déployées sur le même serveur ou sur plusieurs serveurs connexes.
Du point de vue du stockage, les microapplications et micro-frontends laissent une empreinte mémoire minimale. Ils ne gèrent généralement pas eux-mêmes les processus de stockage, mais s'appuient sur des composants distincts qui se déplacent entre le front-end et le back-end. Bien qu’il ne s’agisse pas d’une pratique recommandée, les microservices sont tout de même capables de stocker leurs propres données, telles que les informations d’état et l’historique des transactions, si nécessaire.
La mise en place d’une architecture micro-frontend n’est pas si simple que cela. Il faut d’abord choisir la bonne méthode. Selon le cabinet de conseil Octo Technology, il existe « 1 001 façons » de le faire.
Le cabinet référence tout de même quelques méthodes en exemple. Il est possible d’utiliser des Web Components, de profiter des fonctionnalités de rendus côté serveur des frameworks Next.js (React) ou Nuxt.js (Vue) ou encore de passer par le framework dédié à cette technique : Single Spa. Ce choix reste à la discrétion des équipes devOps.
D’autant que les microapplications ne fonctionneront correctement que si les équipes de développement définissent clairement les limites contextuelles et fonctionnelles entre les différents modules de l’interface utilisateur. Les frontières entre ces modules de haut niveau doivent correspondre à des éléments tels que les types d’utilisateurs, les ensembles de fonctionnalités uniques et, si possible, la structure de l’équipe de développement elle-même. Cela nécessitera une communication et une coopération entre les développeurs et les équipes de développement, ainsi qu’avec les équipes d’exploitation et de sécurité qui prennent en charge les applications associées.
Selon Octo, l’administration des équipes de développement d’une application critique, complexe ou très fortement sollicitée, serait la principale raison d’utiliser les micro-frontends. Ce serait d’ailleurs la raison pour laquelle les géants du Web seraient les premiers à adopter cette méthode.
Enfin, les microservices et les micro-frontends ont des inconvénients spécifiques. La nature décentralisée des microservices nécessite l’envoi fréquent de messages entre eux, souvent par le biais de procédures de communication étendues. Ces niveaux élevés de messagerie peuvent facilement nuire aux performances et à l’intégrité du réseau s’ils ne sont pas contrôlés, et cela signifie que les composants des microservices doivent être étroitement et soigneusement surveillés. Cela est compliqué, compte tenu de leur nature stateless, et nécessite presque toujours le soutien d’outils de gestion automatisés.
Les micro-frontends, eux, disposent de modes de communication plus directs, mais il faut faire particulièrement attention à ne pas créer des couplages, voire des dépendances entre les éléments front-end et back-end. Cela demande généralement d’employer des modules supplémentaires pour administrer les états et les connexions. Selon Octo, la sécurité est également plus difficile à maintenir avec les micro-frontends. Il faut faire particulièrement attention à la gestion de l'authentification des utilisateurs finaux. Le problème tient dans l'accessibilité des données et les services partagés entre les micro-frontends.
Dr. Annegret Junker, lead architect chez Allianz Technology affirme dans un billet de blog qu'il faut établir un flux de connexion standard de type Oauth ou OpenID Connect. Dans ce contexte, après la connexion de l'utilisateur depuis un portail et sa transmission à un SSO, l'application appelle ses micro-frontends qui communiquent tous avec le fournisseur d'identité pour certifier leur connexion. Une fois le contexte de sécurité établie, le fournisseur d'identité s'assure de la validité de la session de l'utilisateur et l'application affiche les modules correspondant aux différents micro-frontends. « La méthode de travail présentée ici implique que les différents micro-frontends ne se connaissent pas et ne se font pas confiance », explique-t-elle
Cette architecture requiert également de revoir en profondeur la chaîne de tests, afin de prendre en compte les spécificités des micro-apps. En effet, il faut pouvoir maintenir la communication entre les micro-frontends et anticiper leur évolutivité, d'après Octo. Si un micro-frontend A partage habituellement un texte à un autre micro-frontend B, mais que ce second est remanié pour recevoir des nombres, la communication est rompue, et l'application casse.
