BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Articles Les Microservices Sont Le Nouveau Saint Graal De l'Evolutivité Pour La Scalabilité

Les Microservices Sont Le Nouveau Saint Graal De l'Evolutivité Pour La Scalabilité

Favoris

Points Clés

  • Le compromis des microservices
  • Les générations de solutions miracles dans le monde de Java
  • Le monolithe encore utile dans certaines situations.
  • Il n'y a pas de solution miracle en IT

Le Saint Graal est un trésor qui sert de motif important à la littérature arthurienne, en plus de grands films comme Indiana Jones. Dans certaines versions de la légende, un calice sacré est responsable de la guérison de toutes les maladies et problèmes. Le Saint Graal est également devenu synonyme d'un objet ou d'une relique sacrée dans certaines régions ou de la solution de tous les problèmes. Dans le domaine informatique, nous avons également ce Saint Graal qui recherche les performances et l'évolutivité d'une application avec une solution unique que nous appelons la solution miracle. Cette solution miracle a changé les techniques depuis des générations et l'actuelle est celle des microservices. Avons-nous enfin trouvé le Saint Graal de l'informatique avec des microservices ? Dans cet article, nous parlerons un peu du grand problème du Saint Graal avec les microservices.

Le rêve de performance et d'évolutivité a toujours été un désir fort chez les architectes informatiques. Et beaucoup d'entre eux commencent à utiliser des microservices pour des raisons de performances. Et comme nous le savons en informatique depuis 1960 : l'optimisation prématurée est la racine de tout mal.

Les générations du Saint Graal (ceux qui n’ont pas d’idée)

Évidemment, je n'ai pas des décennies de pratique, cependant, pendant cette période, j'ai pu voir certaines générations du Saint Graal ou j'ai simplement un problème de performance et voici la solution typique "aucun indice" comme solution miracle. Ce que j'appelle «sans idée», fondamentalement, est basé sur la solution qui sort de la manche d'un architecte comme la solution à tous les problèmes possibles. Tout au long de mon parcours, j'ai pu voir que ces solutions de type Saint Graal ont évolué dans le temps, cependant, leur concept de base n'est pas, une solution rapide, sans beaucoup d'analyse de l'architecture actuelle :

  • Augmenter la mémoire de la JVM : le problème de l'application sera certainement résolu en augmentant ses ressources;

  • Mettre du cache pour la base de données : le problème est dans la base de données, nous devons donc mettre un cache;

  • Changer la base de données relationnelle en NoSQL : la base de données doit être évolutive, je vais bientôt mettre une solution avec NoSQL comme Cassandra;

  • Passer aux microservices : je dois rendre mon application évolutive, donc je dois diviser l'application.

 

Les problèmes des microservices

Il y a plusieurs problèmes que les conférences ou ateliers n'abordent pas, l'architecture logicielle du monde réel :

  • Complexité matérielle : puisque la nouvelle architecture va utiliser de nouvelles machines il est important de souligner qu'en plus de la création, il est important de maintenir ces services, c'est-à-dire que les bases de données ont besoin de plus d'opérations de sauvegarde;

  • Sécurité : la sécurité est importante et garantir l'accès entre les machines est trivial. Par exemple, il est important de s'assurer que les serveurs du secteur financier accèdent aux bases de données du secteur financier et que les autres machines ne le font pas;

  • Chaque application a besoin de tests et avec des microservices cela ne diminuera pas, au contraire, ces tests doivent augmenter car il est nécessaire de tester l'intégration, sans oublier, qui doit vérifier quand de tels services ne sont pas disponibles, par exemple avec Circuit Break;

  • Une application ayant des difficultés à se connecter deviendra encore plus difficile avec les microservices, il est important d'avoir encore plus d'infrastructure et de machines pour centraliser les journaux et avoir un identifiant de trace ouvert pour suivre le journal parmi les services disponibles dans l'application.

 

Les erreurs les plus courantes avec les microservices

Il est très courant d'avoir une liste d'erreurs la plus courante de tous les logiciels, surtout en cas de changement de paradigme. Par exemple, lors d'une migration vers des bases de données NoSQL, l'erreur a certainement été de penser à des relations dans des bases de données qui ne prennent pas en charge ces relations comme Cassandra. La liste suivante présente les erreurs les plus courantes que nous trouvons dans les microservices:

  • Découpage du domaine : le DDD a apporté la notion de domaine, et lorsque l'on adopte les microservices, il est très classique de faire des erreurs dans le découpage du business en domaines. Sur le point des performances, la façon la plus efficace de communiquer entre les domaines est de passer par la mémoire. Il vaut mieux éviter de réinventer la roue : on peut simplement écrire les bonnes requêtes avec les bonnes jointures plutôt que d'imaginer des orchestrations de micro-services;

  • Ne pas automatiser : l'une des meilleures pratiques existantes en matière de microservices est certainement CI / CD. Ces techniques sont vraiment importantes, d'autant plus qu'il y a beaucoup de machines à gérer;

  • Diversité des langages : cette décision est certainement la plus intrigante pour moi. Jusqu'à présent, je ne connais pas un seul projet dont le but est d'afficher quelque chose sur la console, cependant, il est très courant d'entendre la décision d'un programmeur basée sur le nombre de lignes dans un "Hello World". Il est important d'être très prudent avec ce type de décision;

  • Votre application n'est pas assez grande pour devenir un microservice : toutes les grandes applications n'auront pas besoin d'être un microservice et il est très important de l'admettre;

  • L'un des grands arguments pour choisir des microservices est la possibilité de choisir de mettre à l'échelle un composant individuellement. Cependant, voici la question : est-il vraiment judicieux de mettre à l'échelle un composant individuellement ?;

  • Les microservices ont besoin d'informations et, comme toute base de données distribuée, ils sont confrontés à la théorie CAP. En effectuant plusieurs mises à jour sur chaque service, il est nécessaire d'ajouter une nouvelle couche et complexité dans l'application, comme la norme SAGA, et cette couche, compte tenu de sa complexité, a généralement un impact encore plus important sur la cohérence des données de tous les services impliqués;

  • Démarrer le projet maintenant que les microservices ont tendance à être une grosse erreur, elle réside dans le fait que la définition des domaines n'est pas stable, et que des erreurs dans les frontières entre domaines vont générer des dépendances et des couplages importants entre les services, qui pourraient être gérés en utilisant des jointures dans le cas relationnel ou des sous-documents dans le cas de bases NoSQL telles que  MongoDB.

Autre point très important, utilisez les microservices uniquement parce que les grandes entreprises utilisent ce type d'architecture. Dans le monde de l'architecture logicielle, une décision ne doit pas être prise uniquement par la popularité de la solution. Comme Edson Yanaga le dit dans son livre : « Certes, nous lisons toujours beaucoup de choses sur les architectures de microservices mises en œuvre par des sociétés comme Netflix ou Amazon. Alors, laissez-moi vous poser une question : combien d'entreprises dans le monde peuvent être Netflix et Amazon? ».

Les microservices, comme n'importe quelle décision d'architecture, vient avec ses avantages et ses inconvénients. Comme le dit Martin Fowler : : 

« Les microservices introduisent des problèmes de cohérence de données en fin de transaction, du fait de leur intention louable de gérer les données de façon décentralisée. Dans le cas d'une application monolithique, vous pouvez mettre à jour une quantité importante de données dans une transaction unique. Les microservices mettent à jour de nombreuses ressources, et utiliser des transactions distribuées est une solution que l'on n'apprécie pas (pour de bonnes raisons). Les développeurs doivent à présent se méfier des problèmes de cohérence de données, et trouver des solutions pour détecter quand les choses se désynchronisent d'exécuter quoi que ce soit que le code regrettera. » - Martin Fowler

La poursuite du Saint-Graal en informatique est toujours l'un des plus grands mythes du monde de l'informatique. Les microservices comme toute décision architecturale ont des avantages et des inconvénients comme toute autre solution. Les microservices n'étaient pas les premiers et ne seront pas la dernière solution miracle de performance que j'appelle affectueusement «solution que rien ne justifie». 

En tant qu'ingénieurs et architectes, nous devons analyser attentivement ces décisions. Il convient de rappeler que malgré la grande glamourisation des microservices dans les conférences, les articles et certains livres, leurs explications se limitent souvent à la création et non à la maintenance et aux compromis. Puisque la conception, d'une façon générale, est la partie la plus naturelle dans une application, il est essentiel lorsque l'on choisit une architecture, d'en pondérer les avantages et les inconvénients, et de se méfier quand on ne vous décrit que les avantages. Après tout il y a plus de contentement dans la recherche du Saint Graal.

 

Evaluer cet article

Pertinence
Style

Contenu Éducatif

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

BT