Nous avons préparé la traduction d'un article de Neil Ford, architecte de systèmes et cerveau idéologique de ThoughtWorks, une société de développement de logiciels qui automatise les processus de test et de déploiement de logiciels.
Neil est un expert reconnu en développement logiciel qui travaille au carrefour de la conception agile et de l'architecture des systèmes. Il est l'auteur de nombreux articles, livres, dizaines de présentations vidéo, fait des présentations lors des principales conférences de développeurs. Vous pouvez voir son travail sur
nealford.com .
Les microservices comme architecture évolutive
L'architecture de microservices conquiert rapidement le monde. En mars, la maison d'édition O'Reilly a organisé sa première conférence sur l'architecture logicielle O'Reilly. Et près de 60% des rapports étaient consacrés à certains aspects de l'utilisation des microservices. Pourquoi ce style architectural particulier est-il devenu si soudainement si populaire?
L'architecture de microservice est un nouveau style de conception architecturale qui a émergé après DevOps et intègre des pratiques de livraison logicielle continue. C'est également un exemple d'architecture évolutive qui suit le principe de changements progressifs et continus de plusieurs dimensions au niveau structurel d'une application. Cet article présente certaines des caractéristiques et principes saillants de cette famille de styles architecturaux.
Architecture évolutive
On pensait auparavant que les éléments de l'architecture "sont très difficiles à changer après sa création". Le changement progressif est le principe principal de l'architecture évolutive. Il attire l'attention générale précisément parce que les changements d'architecture ont toujours été difficiles à prévoir et très coûteux à réaliser. Si la possibilité de changements évolutifs est intégrée à l'architecture elle-même, leur mise en œuvre devient alors beaucoup plus simple et moins chère, contribuant à des changements dans le développement de logiciels et les pratiques de publication, ainsi qu'à l'augmentation du niveau de flexibilité globale des processus.
L'architecture de microservice est entièrement cohérente avec cette idée car elle a des
contextes délimités qui sont alloués logiquement selon la conception pilotée par le domaine d'Eric Evans et sont implémentés en tant que composants physiquement séparés. Cette séparation est obtenue grâce à la mise en œuvre de pratiques DevOps telles que le provisionnement, les tests et le déploiement automatisé de machines virtuelles. Étant donné que chaque service est séparé de tous les autres services (au niveau structurel), le remplacement d'un microservice par un autre est aussi simple que l'échange de cubes lego.
Caractéristiques de l'architecture évolutive
Les architectures évolutionnaires ont un certain nombre de caractéristiques communes. Toutes ces fonctionnalités seront décrites dans un prochain livre sur l'architecture évolutive. Dans cet article, nous n'en donnons que quelques-uns.
Modularité et connectivité
La possibilité de partager des composants dans des limites bien définies offre aux développeurs les avantages d'un changement continu si nécessaire. Si l'architecture n'a pas été conçue et que le système ressemble à une grosse boule de boue (
architecture Big Ball of Mud ), alors les changements évolutifs sont impossibles, car il n'y a pas de parties distinctes dans une telle structure.
[La relation entre les classes (points autour du périmètre) dans une grande liasse de terre provenant d'un projet client anonyme.]Une interconnexion incorrecte des composants entrave l'évolution du système en raison du fait que des modifications peuvent affecter de manière imprévisible d'autres parties du système. Toutes les architectures évolutives offrent un certain niveau de modularité, généralement au niveau de l'architecture technique (par exemple, l'architecture en couches).
Organisation autour d'opportunités d'affaires
Influencée par les principes de la conception orientée sujet dans les architectures modernes à succès, la modularité au niveau du domaine est de plus en plus utilisée. Une architecture basée sur les services diffère d'une architecture orientée services (SOA) traditionnelle principalement par sa stratégie d'allocation de services. L'architecture orientée services est strictement divisée par niveaux techniques, tandis que les architectures basées sur les services sont construites principalement dans des parties du domaine défini par les microservices.
Les expériences
La réalisation d'expériences est l'un des avantages importants que l'architecture évolutive apporte aux entreprises. La possibilité d'apporter facilement de petites modifications aux applications permet d'utiliser des pratiques courantes de déploiement continu telles que les tests A / B, les tests pour un groupe limité d'utilisateurs (version Canary) et d'autres. Les architectures de microservices sont souvent construites sur la base du routage des appels de service, ce qui permet d'utiliser plusieurs versions du service au sein d'un écosystème entier. Cela ouvre à son tour de grandes opportunités d'expérimentation et de modification des fonctionnalités existantes. En fin de compte, lors du développement d'applications métier, moins de temps est consacré à la discussion des plans et des backlogs, et le développement s'effectue principalement sous la forme de tests d'hypothèses rapides.
Principes d'architecture évolutive
Une image plus complète de l'architecture évolutive peut être obtenue en se familiarisant avec ses principes de base. Ces principes concernent différentes caractéristiques de l'architecture elle-même et de ses méthodes de conception. Une partie des principes concerne le choix du moment de la prise de décisions architecturales dans le processus de conception d'un système.
Fonction fitness
Il est nécessaire de distinguer l'émergence (formée à la suite du processus de conception) et l'architecture évolutive - c'est extrêmement important. À l'instar des méthodes de calcul évolutif (telles que les algorithmes génétiques), la fonction de fitness architectural définit un objectif dans la conception architecturale. Pour certains systèmes, l'exigence principale est une longue durée de disponibilité, pour d'autres, des performances ou une sécurité élevées.
[Diagramme radar utilisé pour mettre en évidence les fonctions de fitness importantes pertinentes pour ce système logiciel.]
Si vous prédéterminez la fonction de mise en forme pour un système particulier, cela vous aidera à l'avenir à prendre les bonnes décisions en temps opportun. Pour différentes solutions architecturales, vous pouvez calculer les fonctions de fitness, et si sa valeur devient meilleure, cela signifie que l'architecture se développe dans la bonne direction.
Attention aux points douloureux
De nombreuses méthodes de travail utilisées dans la fourniture continue de logiciels et le développement d'une architecture évolutive sont basées sur le principe de «l'attention aux points douloureux» formulé par la communauté de programmation eXtreme. Lorsque des moments surviennent dans le travail de conception qui peuvent devenir sources de problèmes (points douloureux), il faut y faire attention dans les plus brefs délais. Cela vous aidera à identifier les problèmes potentiels à l'avance et à les éliminer en ordre de marche. Les pratiques courantes de livraison continue, telles que le pipeline de déploiement, le provisionnement automatique des machines virtuelles et la migration de la base de données, lors de la conception d'une architecture évolutive, simplifient considérablement l'élimination des points faibles pendant la phase de changement.
Point de décision
La principale différence entre l'architecture traditionnelle et l'évolution est lorsque des décisions importantes sont prises. Ces décisions peuvent concerner la structure de l'application, la pile technologique, les outils individuels ou les modèles de communication. Dans le cas de la conception d'une architecture traditionnelle, ces décisions sont prises au stade initial, avant d'écrire le code. Dans le processus de développement d'une architecture évolutive, toute décision est prise le plus tard possible, au dernier moment, quand elle est encore acceptable. L'avantage d'une prise de décision ultérieure est que des informations supplémentaires peuvent être disponibles à ce stade. Les coûts de cette méthode incluent les coûts d'un éventuel affinement de l'architecture après qu'une décision est prise. Ces coûts peuvent être réduits en utilisant des abstractions appropriées, mais ils peuvent toujours se produire. Cependant, les coûts de prise de décisions au stade initial sont également bien réels. Prenez, par exemple, la décision de choisir un outil de messagerie. Différents outils prennent en charge différentes fonctions. Si nous choisissons un outil plus puissant que nécessaire, nous obtenons une architecture mal conçue qui nécessitera inévitablement de nouveaux développements. Cette «dette technique», résultant de la sélection du mauvais outil, sera une charge supplémentaire pour les développeurs.
Bien sûr, le principal problème avec le dernier moment possible de prise de décision est de déterminer quand elle vient. Pour ce faire, concentrez-vous sur la fonction de fitness. Tout d'abord, il est nécessaire de prendre des décisions qui peuvent avoir un impact significatif sur le choix des éléments d'architecture ou de conception, ainsi que des décisions qui affectent de manière significative la réussite globale du projet. L'impact négatif du report d'une telle décision l'emporte souvent sur les avantages possibles d'une décision ultérieure.
Conclusion
Les architectes logiciels devraient expliquer les décisions prises concernant la conception des systèmes en cours de développement, en utilisant généralement différents types de diagrammes. Les développeurs d'architecture tombent souvent dans le piège de présenter l'architecture logicielle comme l'équation qu'ils doivent résoudre. De nombreux outils commerciaux proposés par les architectes logiciels vous permettent de décrire formellement l'architecture sous forme de carrés, de lignes et de flèches. Bien que de tels diagrammes puissent être utiles, ils n'offrent qu'un affichage en deux dimensions, un instantané du monde idéal, mais nous vivons dans une réalité en quatre dimensions.
Pour remplir un tel diagramme bidimensionnel de vie, il est nécessaire de le spécifier. L'étiquette
ORM dans un diagramme à deux dimensions devient
Hibernate v4.2.17 , ce qui rend le monde en
question en trois dimensions. Lorsque vous aurez un plan pour sa mise en œuvre en production et la mise à jour six mois plus tard de la version inévitable d'
Hibernate v4.3.0.1 , vous serez prêt pour le monde à quatre dimensions. De nombreux architectes ne réalisent pas qu'une vision statique de l'architecture a une courte durée de vie. L'univers logiciel existe dans un état de flux, il est dynamique et non statique. L'architecture n'est pas une équation, mais plutôt un instantané d'un processus en cours.
Les pratiques de livraison continue de logiciels et de DevOps ont montré que les problèmes découlaient d'un manque de compréhension des efforts nécessaires pour implémenter et prendre en charge l'architecture. La mise en œuvre de l'architecture n'est que la première étape.
L'architecture reste une abstraction jusqu'à sa mise en œuvre. En d'autres termes, la viabilité de toute architecture à long terme ne peut être jugée que lorsque vous l'avez non seulement implémentée, mais également modifiée au moins une fois. Et peut-être ont-ils réussi à faire face aux surprises en cours de route.
La compréhension d'un architecte logiciel des capacités opérationnelles est essentielle au développement d'une architecture évolutive. Le développement évolutif de l'architecture affecte les caractéristiques de sa mise en œuvre et doit donc être pris en compte dans le processus d'achèvement. Les exigences du processus de livraison continue de l'architecture visent à améliorer sa visualisation et à simplifier les changements. De cette façon, la livraison continue améliore les capacités de l'architecture évolutive.
Le 19 novembre, Neil Ford arrive à Moscou avec une master class
sur la création d'une architecture logicielle évolutive .