Le gourou des microservices avertit les développeurs que l'architecture à la mode devrait …

Un logiciel monolithique mais modulaire à l'ancienne est «très sous-estimé»

Sam Newman, parlant à QCon London

QCon Londres Sam Newman, auteur de Building Microservices and Monolith to Microservices, a déclaré aux participants à la conférence des développeurs QCon à Londres que "les microservices ne devraient pas être le choix par défaut".

Les microservices sont devenus aujourd'hui l'équivalent de "personne n'a jamais été licencié pour avoir acheté IBM", un slogan courant dans les années 80, a déclaré Newman. "Avec la moitié de tous les clients avec qui j'ai travaillé, je leur ai dit que les microservices n'étaient pas pour vous."

Au cas où vous douteriez de lui, une autre session à QCon a décrit comment Segment, une société d'analyse de données basée à San Francisco, est passée "aux microservices et vice versa".

"Après des années à continuer d'ajouter à notre architecture de microservices, nous nous sommes retrouvés dans un endroit où la vitesse de notre développeur diminuait rapidement et nous trébuchions constamment sur notre architecture de microservices et sa complexité", a déclaré le résumé. "Le passage à un monolithe a été la solution qui a fonctionné pour nous."

L'implication n'est pas que les microservices ne sont pas bons, mais que les développeurs les ont adoptés trop facilement, convaincus par les avantages. L'idée des microservices est que la décomposition d'une application en petits services indépendants permet de la mettre à jour plus rapidement et en toute sécurité, et de la faire évoluer plus efficacement, tandis que les applications qui sont compilées en un seul grand exécutable – des monolithes – nécessitent des déploiements tout ou rien qui sont plus difficiles à coordonner.

Expliquant les avantages des microservices, Newman a déclaré: "Il existe de nombreuses raisons pour lesquelles nous pourrions choisir une architecture de microservices, mais celle sur laquelle je reviens toujours est cette propriété de déployabilité indépendante."

à lire :  50 meilleures idées et opportunités pour les petites entreprises aux États-Unis pour 2020

Si vous souhaitez apporter des modifications à une partie d'une application, telle que la partie qui couvre l'expédition, "Je devrais pouvoir déployer ce service d'expédition dans un environnement de production sans avoir à modifier le reste du système. Cela aide à expédier logiciel plus rapidement et il aide nos équipes à travailler de manière plus autonome. "

Quel est donc le problème? Le problème principal semble être qu'il est difficile de bien faire les microservices. Newman a décrit ce qu'il a appelé "le pire des monolithes, le monolithe distribué". Cela décrit un système qui a été décomposé en plusieurs processus, "mais pour une raison quelconque, nous devons déployer l'ensemble du système ensemble dans le cadre d'une version de verrouillage. Souvent, cela peut se produire parce que nous avons mal nos barrières de service. Nous sommes étaler la logique métier sur toutes ces différentes couches. Nous devons coordonner entre plusieurs équipes pour faire quoi que ce soit. "

Un signe de problème, a déclaré Newman, est que "si vous avez un responsable de la coordination des versions à temps plein, il est probable que vous ayez un monolithe distribué". Newman voit une grande valeur dans la livraison continue, où le logiciel est automatiquement construit et testé et donc déjà prêt pour la sortie.

Le monolithe distribué présente la complexité de déploiement d'une architecture de microservices, mais sans ses avantages. Les services n'ont pas la «déployabilité indépendante» essentielle au succès.

Ce fut une session populaire à QCon. Pourquoi? Un indice est venu lorsque Newman a demandé aux participants s'ils avaient une application ou un système "trop ​​gros, que vous essayez de faire plus petit". Des mains se sont levées dans toute la pièce.

à lire :  Combien coûte la location d'une salle de banquet?

Modularité

Newman a fait valoir que même les applications déployées en tant que processus unique, ou monolithes, peuvent être modulaires dans leur conception, avec différentes équipes travaillant sur chaque module. Ce n'est pas nouveau – c'est une idée "du début des années 1970 autour d'une programmation structurée", a-t-il dit. Cela donne "un degré de travail indépendant" et est "une option très sous-estimée". Un problème potentiel avec les applications modulaires est que "les gens ont tendance à ne pas bien définir les limites des modules ou à avoir une discipline sur la façon dont les limites des modules sont formées" – le résultat étant "ils descendent dans une boule de boue". Surmonter cela, cependant, et de nombreuses organisations "seraient mieux loties" avec un monolithe modulaire qu'avec une architecture de microservices.

Il convient également de noter que si vous avez une application modulaire bien conçue, la décomposer en microservices est relativement facile. Vous pourrez réutiliser une grande partie du code car le concept de sections isolées de code traitant de différentes fonctionnalités est déjà en place. Les «unités de décomposition», a déclaré Newman, sont les «concepts de domaine, tels que la facturation, les notifications et la gestion des commandes».

"Le monolithe est devenu un remplacement pour le terme que nous avions l'habitude d'utiliser, qui était hérité. C'est un problème parce que certaines personnes commencent à voir n'importe quel monolithe comme quelque chose à enlever. C'est profondément inapproprié. Le monolithe n'est pas l'ennemi. Ce n'est pas le problème que vous avez. "

Étant donné que les microservices ne sont pas la bonne solution dans tous les cas, quels sont les indices qu'une application monolithique existante pourrait en fait être un bon candidat pour la décomposition en microservices? "Vous avez essayé toutes les choses faciles", a déclaré Newman à The Register. "Avez-vous fait une analyse de la chaîne de valeur? Avez-vous regardé où se trouvent les goulots d'étranglement? Avez-vous essayé la modularisation? Les microservices devraient être un dernier recours."

Même l'évolutivité n'est peut-être pas une raison suffisante pour adopter des microservices. "Mes clients disent que mon application n'est pas évolutive. Je demande, avez-vous essayé d'exécuter 10 copies de votre monolithe? Et ils ne l'ont pas fait. Faites d'abord toutes les choses faciles." ®

Sponsorisé:
                    Exploiter la valeur des données

Le gourou des microservices avertit les développeurs que l'architecture à la mode devrait …
4.9 (98%) 32 votes
 

Julien