Dans une précédent article, nous avons conclu que la loi de Conway prévaudra et que les microservices sont essentiels dans un monde d'Enterprise DevOps. Cela signifie que toute personne qui prend DevOps au sérieux doit apprendre à définir les microservices, à les gérer, à maximiser les avantages et à minimiser les problèmes. Il est important de savoir comment concevoir des microservices idéaux pour différentes technologies et différents cas d'utilisation. Ce blog donne un aperçu de la manière dont les microservices soutiendront l'entreprise de manière optimale.

Qu'est-ce qu'une architecture de microservices ?

James Lewis et Martin Fowler nous donnent la meilleure définition des architectures de microservices :

Le style d'architecture Microservice fournit une approche permettant de créer des applications plus grandes sous la forme d'une suite de services plus petits (= composants informatiques ou applications), où chaque service :

• Est construit autour d'une capacité commerciale
• Exécute son propre processus
• Communique via un mécanisme léger et
• Peut être déployé indépendamment par un dispositif de déploiement automatisé

En fin de compte, les microservices devraient favoriser la flexibilité des entreprises. Cela est possible si les nouvelles demandes de fonctionnalités ont la probabilité maximale d'avoir un impact sur un seul microservice, ce qui permet à une équipe DevOps de résoudre rapidement le problème, de refaire rapidement des tests avec l'automatisation et de redéployer le microservice.

Que sont les microservices fonctionnels ?

Étant donné que la plupart des demandes de fonctionnalités proviennent des utilisateurs finaux, la plupart des microservices seront orientés vers les fonctionnalités. Les demandes de fonctionnalités impliquent généralement des modifications de l'interface utilisateur graphique, de la logique, du flux de travail et des données. Par conséquent, la conception de microservices qui ont toutes ces parties dans le même déployable minimisera l'impact du changement.

La conception impliquera bien plus que des considérations techniques. Nous avons vu que le processus métier est généralement la meilleure base pour diviser une portée fonctionnelle en bons microservices. Cela signifie que vous devez impliquer les propriétaires d'entreprise et les architectes de processus pour définir l'architecture.

Avons-nous encore besoin de microservices techniques ?

Quelques microservices seront plus orientés vers la technique et pourront être appelés via des interfaces de requête-réponse claires et stables. Lorsqu'une fonctionnalité doit être la même pour de nombreuses applications et qu'elle ne change pas très souvent, elle peut être divisée en un microservice distinct plus « technique ».

D'autres microservices peuvent être orientés vers l'intégration pour orchestrer d'autres services, ou être responsables de la connectivité à un autre grand système et/ou à un tiers externe. Un ESB central est souvent remplacé par des microservices spécialisés distribués qui peuvent contenir leurs propres données métier si cela rend le service plus efficace.

Les entreprises doivent être ouvertes d'esprit quant à ce que peut et doit faire un microservice. La meilleure architecture de microservice pour un secteur d'activité n'est pas toujours idéale pour un autre. Cela correspond à DevOps où nous déléguons principalement les décisions de conception au niveau de l'équipe.

Il est important de ne pas trop réutiliser ou de penser qu'il s'agit de la version 2.0 de SOA. Nous développerons davantage ce sujet important dans un blog séparé à venir.

Comment la taille d’un composant affecte-t-elle l’agilité de l’entreprise ?

Pour les microservices, la plupart des gens disent qu'une équipe DevOps composée d'une à dix personnes devrait posséder, créer, exploiter et gérer environ un à cinq microservices. La taille est relativement flexible pour la conception de microservices.

Pour les périmètres de petite ou de relativement grande envergure, il n’est pas nécessaire de diviser les choses en éléments plus petits que ceux demandés par l’entreprise. Par exemple, les équipes et l’architecture peuvent être alignées sur les fonctions métier qu’elles prennent en charge, ce qui permet d’obtenir une autonomie maximale pour évoluer facilement et générer de la valeur.

Cependant, lorsque la portée du « système » est très large, il sera toujours préférable de diviser les fonctionnalités en microservices distincts. Les dépendances internes et externes augmentent lorsque des années de correctifs et de raccourcis critiques créent des dépendances indésirables. Il est difficile de modifier le système, les tests de régression importants pour chaque version et les déploiements sont coûteux et risqués.

Figure 2 : Dans une architecture monolithique, les groupes d'utilisateurs se battent pour attirer l'attention et les développeurs se marchent sur les pieds.

La taille idéale d'un microservice est liée au nombre de développeurs. Cela signifie que les plateformes HPA ont un avantage sur l'open source car elles peuvent se diviser ultérieurement, avoir des microservices plus grands ou avoir des équipes plus petites.

Qu'est-ce que le pas un microservice ?

Après avoir promu une vision flexible des microservices, il est logique de comparer avec ce qui est pas un microservice:

• Les monolithes ne sont pas des microservices car ils sont trop volumineux. Ils nécessitent des équipes de développement de plus de 10 personnes et (généralement) comportent de nombreux processus fonctionnellement distincts dans le même déployable. Cela nécessite davantage de tests de régression et des cycles de publication plus longs. Les dépendances augmentent avec la taille et au fil du temps, et elles ne sont pas explicites via des appels de service comme c'est le cas avec les architectures de microservices.
• Les architectures SOA en couches où les données métier se trouvent sous l'ESB ne sont pas non plus des microservices. Elles ne contiennent pas les données et fonctionnalités requises pour une fonction métier dans le même déployable. Au lieu de cela, presque toutes les fonctionnalités métier s'étendent sur plusieurs « couches » techniquement ciblées d'unités déployables partagées. Selon NGINX : «L'architecture SOA repose sur le concept d'un style d'architecture de partage autant que possible, tandis que les microservices reposent sur le concept d'un style d'architecture de partage aussi peu que possible. Les microservices doivent être autonomes et remplir une fonction commerciale. Ils doivent donc disposer d'une interface graphique, d'une logique, d'un flux de travail et d'une base de données pour stocker des éléments lorsqu'ils en ont besoin.

Figure 4 : Les microservices favorisent une meilleure flexibilité et une meilleure coopération entre l’entreprise et le service informatique que les autres modèles.

Notre point de vue : Caractéristiques communes des microservices

Les microservices remplissent une fonction métier et communiquent entre eux dans le cadre du processus métier habituel, ce qui les rend plus faciles à comprendre pour les personnes non techniques. C'est une bonne chose pour DevOps et les décisions d'équipe. Selon nous, les bons microservices doivent avoir les caractéristiques communes suivantes :

1. Orienté processus

Les microservices fonctionnels implémentent généralement une phase du processus métier ou une fonction métier complète. Le nom « service » est trompeur. Le microservice peut être un service appelable, mais il peut également s'agir d'une application axée sur les fonctionnalités de l'utilisateur final.

2. Autonome et flexible

Les microservices doivent être développés et déployés séparément et contenir leurs propres données. Ils doivent évoluer dans le temps et être faciles à modifier et à redéployer.

3. Automatisation et contrôle

Les microservices doivent disposer d’une bonne automatisation des tests et du déploiement, d’une bonne gestion des erreurs, d’une surveillance et d’alertes, et doivent permettre le retour d’informations des utilisateurs.

4. Taille idéale

Le terme « micro » est également quelque peu trompeur : les microservices ne doivent être ni trop petits ni trop grands. Le service peut être relativement important et compter jusqu’à 10 développeurs. Il est plus petit qu’un monolithe, mais il n’est pas nécessaire qu’il soit plus petit qu’une application normale. Si vous utilisez une plateforme à haute productivité comme Mendix, un microservice peut presque être un système central d’une entreprise de taille moyenne.

Que signifieront les microservices pour vous ?

Les microservices, s'ils sont correctement exécutés, favorisent l'alignement entre l'entreprise et l'informatique et améliorent la flexibilité des processus opérationnels. Avec les paradigmes précédents, il était très difficile de modifier les processus métier, de sorte que la numérisation a été très difficile pour la plupart des acteurs en place. L'architecture DevOps et microservices résout ce problème en localisant les décisions et le développement : l'équipe DevOps travaille directement avec l'entreprise et est autonome pour prendre des décisions. Les microservices sont développés séparément, avec des dépendances minimales, et ils sont déployés séparément en tant qu'unités autonomes.

Mendix propose des ateliers et des formations sur site sur les microservices. Nous avons aidé un grand nombre de clients avec de nouveaux programmes et initiatives, en leur fournissant un soutien dans la prise de décision et en élaborant la solution la plus optimale pour chaque problème commercial. Contacte-nos para mais informações.