Tendances d’Architecture et influences actuelles
La manière de concevoir des systèmes applicatifs est dépendante des innovations techniques ainsi que des outils disponibles aux équipes qui en ont la charge. Les architectes doivent s’adapter et régulièrement mettre à jour leurs compétences pour trouver des solutions à des contraintes sans cesse différentes.
En cette période d’intense Digitalisation les applications dont l’architecture est fortement distribuée ne sont plus l’exception mais la règle. On l’observe à de nombreux niveaux, qu’il s’agisse de la composition de multiples services SaaS, d’hébergement multi-clouds, ou encore d’edge computing (Mobile ou IoT), il ne s’agit pas d’un phénomène éphémère.
Pour prendre en compte cette tendance, je vous propose une liste de 7 facteurs de complexité et de risques qu’il est indispensable d’étudier lors de la transformation de systèmes existants, ou de la conception de nouvelles applications. La gestion de ces risques nécessite d’adapter les pratiques communes d’architecture, donnant ainsi une nouvelle teinte au profil de l’architecte idéal.
Examinons les effets de la tendance à l’extrême modularisation actuelle — qu’illustre la popularité grandissant des architectures de type microservices — ses effets sur la complexité des applications, et voyons-en quoi cela nécessite de revoir la manière de concevoir des architectures.
Bienfaits et travers de la modularisation
La courte histoire de l’informatique d’entreprise n’a eu de cesse de voir découplées, séparées, isolées, les fonctionnalités des programmes informatiques, en éléments de granularité de plus en plus fine et de plus en plus indépendants. Cette segmentation s’est faite :
- Au niveau des applications, d’abord dans la conception en segmentant le code source en fichiers, bibliothèques, classes, fonctions, procédures…
- Au niveau de l’exécution : applications mono-processus, multi-processus, multi-threadés, répartis dans plusieurs middlewares… mais également au niveau du socle d’exécution physique : mainframe, serveur unique, puis répartie sur plusieurs serveurs, jusqu’à rendre la distinction virtuel/physique difficile avec les VMs, et les containers.
La modularisation a créé les conditions nécessaires à une naturelle division du travail dont les résultats sont :
- La possible parallélisation des activités à mener au sein des projets, pour réduire la durée de mise à disposition de nouveaux services
- La spécialisation des équipes, pour réaliser chacune des tâches de la meilleure façon possible
Grace à elle nous sommes capable de produire des applications en mesure de répondre à des exigences métier de plus en plus importantes, avec :
- Des fonctionnalités extrêmement riches et des traitements sophistiqués
- Une accumulation d’exigences non-fonctionnelles, dont au premier rang :
— La fiabilité : principalement la résilience matérielle et logicielle,
— L’évolutivité : vis-à-vis, d’une part de l’ajout de nouvelles fonctionnalités, et d’autre part pour répondre aux variations de charge en délivrant les performances attendues,
— Et la maintenabilité : en gardant sous contrôle la complexité du système, et pour prendre en compte les besoins relatifs aux opérations
Bien que ce mouvement soit motivé par une volonté de simplification, on constate plutôt un effet de segmentation de la complexité. Pris individuellement chaque module apparait comme simple, toutefois le système constitué par l’ensemble des modules, lorsqu’il est considéré dans son ensemble s’avère, sans surprise, être éminemment complexe.
Par exemple :
- La probabilité d’un disfonctionnement (forte latence, panne, …) impactant l’ensemble du système augmente proportionnellement au nombre de composants et à la fiabilité de leurs connexions (liens réseau),
- La détection ainsi que la résolution des problèmes nécessitent un outillage adapté pour gérer et rendre accessible la compréhension d’un volume d’information extrêmement important,
- Les effets dominos, ou la représentation de toutes les dépendances, parfois non explicites (ex : dans le cas d’une bascule liée à une défaillance), compliquent la compréhension du système. Les éventuels impacts de certaines décisions d’architecture ne peuvent être anticipés, imposant le recours à des tests, dont certains à réaliser en production.
Le rôle de l’architecte étant de garantir la cohérence d’ensemble du système, c’est à lui que reviennent in fine les décisions nécessaires à la conception de l’architecture la plus adaptée à un contexte donné. Cet exercice nécessitant de la méthode, il est essentiel de le baliser.
7 points pour baliser le chemin de l’architecte
Nous avons dressé une liste de 7 facteurs, sources de complexité et de risques, à considérer dans le cadre de la transformation de systèmes existants ou de la conception de nouvelles applications. L’examen de chacun de ces 7 points doit permettre aux architectes de concevoir un système distribué adapté à la situation propre à leur projet, en tirant partie des opportunités offertes par les solutions techniques à leur disposition, mais également en ayant conscience des contraintes qui leur sont associées.
Et bien que chacun des points de la liste suivante nécessite une attention particulière, il est indispensable de ne pas chercher à résoudre des problèmes qui ont peu de chance de survenir dans la phase actuelle de la vie de l’application, ou du SI dans lequel elle s’insère.
Exemple : on ne cherchera pas à atteindre des temps de réponse équivalents pour tous ses utilisateurs et ce quel que soit leur localisation géographique (via le recours à un CDN par exemple), si les plans de développement du service ne visent qu’une seule zone géographique, ou même un seul pays.
Ces 7 facteurs se regroupent autour des 3 axes d’exigences non-fonctionnelles majeurs cités précédemment : fiabilité, évolutivité et maintenabilité.
Fiabilité
La fiabilité d’un système c’est sa capacité à fonctionner correctement même lorsque les choses ne se passent pas comme prévu. Les sources d’erreurs sont nombreuses et variées : matérielles, logicielles, ou encore humaines …
Facteurs ayant un impact sur la fiabilité :
Ultra-distribution
La tendance à une distribution de plus en plus importante et systématique des traitements est véritablement installée. Les tâches les plus simples nécessitent l’appel à un grand nombre de composants, souvent répartis géographiquement, même lorsque l’utilisateur a le sentiment de n’utiliser qu’une seule application. Les services en dehors du SI, fournis par des partenaires, ou les plateformes d’exécution dans le cloud (PaaS ou IaaS) ne sont plus l’exception mais la norme. La fiabilité ne repose donc plus uniquement sur des infrastructures sous-jacentes que l’on maitrise, mais doit être considérée au niveau applicatif.
Service permanent (Always On)
Le 24/7, l’instantanéité et la gratuité des services des GAFAM ont progressivement définit une norme officieuse, à laquelle toute application est implicitement comparée. Les utilisateurs s’attendent à des services toujours accessibles, et plus particulièrement encore lorsqu’ils sont clients. D’autre part, l’exposition de services à des partenaires s’accompagne d’un engagement encore plus fort. Ces accords, qu’ils soient contractuels, ou tacites, engagent l’entreprise, provoquant en cas de défaut des impacts négatifs, qu’ils soient financiers (pénalités, perte de CA), ou sur l’image de marque (crédibilité, dynamisme, confiance).
La probabilité d’incident ou d’erreur augmentant proportionnellement au niveau de répartition d’une application, la fiabilité d’un système distribué est donc difficile à garantir. Lors de la conception il est nécessaire de considérer la mise en place de contremesures pour répondre à certains évènements (latence, incident, panne) : la réplication de composants, ou des solutions de fonctionnement dégradé (en anglais « Graceful degradation ») par exemple via des systèmes de cache, ou de files, sont des solutions communes.
Évolutivité
L’évolutivité est d’abord considérée au niveau fonctionnel, par conception un système évolutif doit permettre de facilement ajouter, modifier, ou supprimer des fonctionnalités. On peut parler également de flexibilité. Mais l’autre facette de l’évolutivité et directement liée à la fiabilité. Bien qu’un système puisse être fiable dans certaines conditions de charge, dans d’autres il pourra ne pas donner satisfaction. En anglais on utilise le terme « scalability » pour décrire la capacité d’un système à s’adapter à une augmentation de sa charge.
Facteurs ayant un impact sur l’évolutivité :
Hyper-dépendance
Là où précédemment les dépendances externes prenaient la forme d’une bibliothèque, ou d’un progiciel, et étaient donc statiques par nature, maintenant ce sont les systèmes externes qui forcent le changement. Les fonctionnalités des applications fournies en mode SaaS évoluent au rythme fixé par leur fournisseur, les nouvelles API et fonctionnalités des plateformes PaaS peuvent voir le jour à des cadences extrêmement dynamiques, ou au contraire sombrer dans l’abandon du jour au lendemain. Ces changements externes vont généralement plus vite que l’évolution de son SI, ou tout du moins ne sont pas nécessairement alignés avec les projets de transformation prévus. Il est donc indispensable de mettre en place des solutions de couplage lâche pour conserver la maitrise de ses applications indépendamment des transformations extérieures.
Multimodalité
Les besoins des métiers évoluent à des vitesses différentes, et les SI ou applications qui les soutiennent également. Certaines parties du SI doivent répondre à des exigences particulières en matière d’évolutivité pour s’adapter aux changements de leur environnement : la concurrence, des avancées liées à la recherche (ex : IoT, Deep Learning), ou encore des contraintes réglementaires (ex : Règlement Général sur la Protection des Données (GDPR), la Lutte Contre le Blanchiment des capitaux et le Financement du Terrorisme (LCB-FT)) peuvent nécessiter une adaptation très rapide. Au contraire, d’autres pans sont très stables, et leurs évolutions extrêmement prévisibles et limitées. Là encore, la conception des systèmes doit intégrer ces différences de rythme et permettre des transformations rapides localisées, sans nécessiter de lourdes évolutions globales généralement coûteuses et risquées car elles sont peu fréquentes.
Élasticité
La consommation de ressources IT devient de plus en plus similaire à notre consommation de certaines ressources de base : électricité, eau courante… C’est-à-dire que nous nous raccordons à des infrastructures déjà existantes et que la production nous semble s’adapter aux variations de notre consommation. Ce mode d’accès permet de répondre de manière efficace à des variations de consommation soudaines, cycliques, saisonnières, ou d’éviter des coûts importants dans l’attente d’un hypothétique succès. Toutefois tirer parti de l’élasticité offerte par les fournisseurs de cloud nécessite un effort de conception particulier pour favoriser la distribution des traitements (en anglais on parle d’« horizontal scalability » ou « scale out »). Ensuite, la conception d’une architecture vise à répondre à certaines contraintes, et en dehors de ces hypothèses fixées il est nécessaire de rechercher de nouvelles solutions. Ainsi les architectures des applications grand public massivement utilisées aujourd’hui sont toutes passées par plusieurs architectures intermédiaires, chacune répondant à des hypothèses d’usage propre à un temps de leur croissance. Il n’existe malheureusement pas de recette miracle utilisable en toutes circonstances.
La conception d’applications flexibles nécessite la mise en pratique de normes de conception spécifiques et pointues, soit pour limiter les adhérences avec son écosystème, ou encore pour tirer parti des avantages des plateformes d’exécution modernes. La frénésie de certains secteurs, ou les croissances ultra-rapides de quelques services, peuvent soumettre à forte pression les systèmes mal conçus, et venir à bout des moins efficaces.
Maintenabilité
La maintenabilité c’est l’aptitude d’un système à être maintenu en état de bon fonctionnement. Les caractéristiques d’une application facilement maintenable sont variées et incluent, pour en citer quelques-unes, la facilité pour les équipes à comprendre son fonctionnement, les moyens pour détecter et investiguer les causes des erreurs, ou encore la simplicité de réalisation des opérations de maintenance (remplacement matériel, montée de version, patch : de préférence sans impact sur la fiabilité de l’application).
Facteurs ayant un impact sur la maintenabilité :
Hyper diversité technique
Les SI de monoculture sont révolus, et bien que l’on ait cherché pendant longtemps à limiter au maximum le nombre de composants techniques différents dans les SI d’entreprise, on assiste plutôt à une hyper diversification des solutions à dispositions (principalement grâce à l’open source), et ce pour toutes les activités : socles d’exécutions back-end ou front-end, stockage des données, collecte, analyse, intégration, exposition interne ou externe de services, … La gestion de cette diversité ne peut plus s’envisager uniquement à travers des mécanismes de limitation, de type catalogue, sous peine de se priver de solutions très efficaces. La compréhension des propriétés propres à chaque catégorie de solutions est nécessaire pour identifier les opportunités et les contraintes techniques, et pour proposer des principes d’architectures fixant les directives d’implémentation.
Nano composition
Les systèmes sont de plus en plus constitués de composants dont la taille (fonctionnalités, complexité technique, empreinte disque, consommation mémoire, consommation CPU) n’a de cesse de se réduire. Cette miniaturisation et cette composition d’éléments ultra-standardisés, facilement et rapidement remplaçables, contribuent à apporter la flexibilité nécessaire à l’évolutivité des systèmes. Toutefois, cela rend difficile de se représenter les applications dans leur intégralité, de déterminer les conséquences de certaines actions, d’évaluer les impacts, de prévoir les comportements aux limites, ou encore d’investiguer les causes de certains problèmes. À partir d’un certain seuil, appréhender la complexité d’ensemble nécessite à la fois de nouvelles méthodes, et de nouveaux outils.
La vie d’une application se considère généralement selon deux temps : le projet, et la production. Lors du projet, les équipes sont bien souvent uniquement concentrées sur l’implémentation de nouvelles fonctionnalités, alors que la phase projet est souvent très concise dans la vie d’une application. De fait, la majorité des modifications seront apportées en production. Il est donc indispensable de concevoir des systèmes simples et facilement maintenables pour qu’ils puissent évoluer par la suite sans dégrader la fiabilité.
L’avenir de l’architecture est dans la conception applicative
Il n’est plus possible aujourd’hui de concevoir une application en se basant uniquement sur les capacités des infrastructures mises à disposition des projets. Les composants étant généralement disséminés, souvent entre plusieurs plateformes et gérés par différents fournisseurs, la réflexion doit impérativement être transverse pour être pertinente.
Les orientations déterminantes de l’architecture ne peuvent se faire qu’au niveau applicatif pour répondre de manière adaptée aux exigences métiers actuelles de fiabilité, d’évolutivité et de maintenabilité. Ultra-distribution, service permanent, hyper-dépendance, multimodalité, élasticité, hyper diversité technique, et nano composition, ces 7 facteurs dessinent les contours du nouveau cadre standard de conception d’architecture.
Billet réalisé pour Wavestone — Illustrations : Charlotte BOENS
