Combattre la complexité des microservices grâce au low-code
Les développeurs de logiciels doivent constamment lutter contre la complexité. Les microservices sont prometteurs en tant que composants d’applications « prêts à l’emploi », mais le développement low-code pourrait être une meilleure approche dans certaines situations.
Les microservices transforment les imposantes applications monolithiques en modules qui accomplissent des tâches spécifiques et facilitent le test et le déploiement des mises à jour. Cette architecture décentralise et, idéalement, simplifie le développement de logiciels.
Néanmoins, leur multiplication provoque souvent l’effet inverse.
En théorie, nous pouvons relier les microservices à l’aide d’une couche supérieure, en assemblant des applications à partir de composants. Cette promesse n’est pas nouvelle, mais elle mérite d’être examinée.
Ivar Jacobson a proposé l’idée de composants logiciels en 1967. Il voulait construire des applications à partir de blocs de code préfabriqués plutôt que de tout créer de zéro. Pourtant, quelque chose se produit chaque fois que nous nous rapprochons du rêve de Jacobson. Les composants nécessitent de nouvelles strates de complexité. En ce qui concerne les microservices, cela signifie des étapes supplémentaires pour garantir la disponibilité, la fiabilité et l’observabilité du code.
Une alternative émergente promet de s’abstraire en partie de cette difficulté : le développement low-code, assorti d’une programmation conventionnelle minimale. D’une certaine manière, les microservices et le développement low-code résolvent des problèmes similaires. Comme les microservices, les plateformes low-code représentent un moyen de créer des applications avec des composants standardisés prêts à l’emploi.
Mais elles n’offrent pas la sophistication des microservices. Ce code réutilisable peut toutefois s’avérer utile là où ces multiples packages découplés n’entraînent que maux de tête et dépenses inconsidérées.
Une fois que les développeurs et les architectes de logiciels ont compris les tenants et aboutissants des microservices, de leur conception à leur déploiement, ils peuvent déterminer comment et quand recourir au low-code.
Problèmes de code, de résilience et de disponibilité des microservices
Les microservices communiquent les uns avec les autres par le biais de protocoles Internet : c’est la force de cette architecture. Parce qu’ils parlent TCP/IP et fournissent des charges utiles de données en JSON, les composants s’exécutent – en principe – sans dépendances. Ces petits services effectuent chacun une tâche bien précise. Une société peut avoir un ensemble de services pour les informations sur les clients, un autre pour la recherche de produits, un troisième pour les commandes et un quatrième pour la livraison.
C’est justement cette répartition des fonctions d’entreprise qui génère une quantité massive de code à administrer. Lorsqu’un bug ou une erreur fait son apparition, les DevOps ont besoin d’outils d’observabilité spécialisés qui retracent toute la chaîne des événements à déboguer. Les microservices exigent un travail de collecte de logs et de surveillance. Et cette supervision demande généralement d’introduire des agents au sein des infrastructures et des applications : encore du code.
Lorsque quelque chose ne va pas, il peut être difficile de déterminer quel composant a contribué au problème sans les bons outils – ce qui peut résulter en la refactorisation de groupes de microservices. Bien que chacun d’entre eux ait un temps de fonctionnement élevé dans ce déploiement assisté, la résilience et la fiabilité au niveau du code commencent à s’effriter.
L’alternative low-code
Une plateforme low-code aide à construire et à livrer les composants d’une application.
Les développeurs, ou même les métiers capables de manipuler des strings SQL fournissent les variables, la connexion à la base de données, le formatage et le style, l’outil génère l’application, parfois via une interface utilisateur de type glisser-déposer. Il s’agit, en fait, de l’approche opposée à celle des microservices, où vous provisionnez la base de données, réalisez son abstraction dans un service et codez la logique du service.
Les plateformes de développement low-code réutilisent généralement des blocs de code. De par cette reproductibilité, le volume de code spécifique peut être drastiquement réduit. Il y a également moins de composants indépendants, qui sont étroitement couplés les uns aux autres. Chaque ligne de code devient plus facilement traçable.
Une base de données appariée à une interface CRUD (Create, Read, Update and Delete) peut aider à illustrer les capacités d’une plateforme low-code. Un programmeur dessine visuellement la table et remplit les données au moyen d’une simple feuille de calcul. Les utilisateurs accèdent aux données par l'intermédiaire du front-end CRUD, qui se trouve dans une application générée par la plateforme (runtime), et qui peut être téléchargé depuis un app store.
Avantages et limites du low-code face aux microservices…
Une plateforme low-code génère la majorité des éléments nécessaires au fonctionnement d’une application, sans qu’il y ait besoin d’écrire tout le code. La plupart des actions et des intégrations de bas niveau sont supportées par les configurations d’outils, ce qui permet aux développeurs de gagner beaucoup de temps et d’éviter les maux de tête. Toutefois, réfléchissez bien à l’endroit où vous employez le low-code dans une architecture de microservices.
Tant que l’application est simple, propre et ne nécessite pas de nombreux points d’intégration, le développement low-code peut être l’alternative aux projets plus manuels et complexes. Le low-code est un choix facile pour les applications qui n’ont pas besoin de communiquer avec de multiples bases de données ou qui ne reposent que sur une série de petites tables.
Les plateformes de conférence ou de promotions marketing, par nature éphémères, en sont de bons exemples. Les outils low-code les plus modulaires peuvent aider à bâtir un CRM et gérer les flux métiers les plus communs en s’interfaçant aux solutions des entreprises.
Cependant, une approche low-code ne remplace pas le développement de microservices à grande échelle. Dès que vous devez partager des informations entre applications en temps réel, les outils et les techniques de programmation impliqués deviennent beaucoup plus sophistiqués. L’approche low-code s’avère limitée quand elle consiste à faire interagir des éléments spécifiques qui ne disposent pas de connecteurs standards.
… Et possibles complémentarités
Pourtant, une combinaison des deux méthodes est envisageable. Il faut à ce moment-là s’assurer que les briques de codes préfabriquées peuvent s’enchâsser avec une architecture existante.
La combinaison la plus logique serait de concevoir son back-end en s’appuyant sur des microservices et le front-end, via une plateforme low-code. Si l’on ne s’abstrait que d’une partie de la complexité induite par la multiplicité des services, l’on obtient là un meilleur contrôle sur ce qui importe tout en réduisant le temps ou le nombre de personnes nécessaires à la conception d’une UI.