Vous êtes sur la page 1sur 4

Les nouvelles

architectures logicielles 1ère partie


L’informatique repose sur des architectures applications et donc sur vous, les
matérielles et logicielles. Je ne vous apprends rien. développeurs. Ces changements sont parfois
Certaines existent depuis quasiment les origines masqués, car vous n’êtes pas toujours au
de l’informatique « moderne », dans les années contact direct.
1970, d’autres sont bien plus récentes. On parle
beaucoup du Cloud Computing, mais le Cloud Programmez ! vous propose un dossier en
n’est finalement qu’une évolution d’architectures plusieurs parties pour explorer quelques
utilisée depuis de nombreuses années. architectures. Nous aborderons, en vrac : le
Cloud Computing, les architectures dites
Les architectures évoluent tout naturellement lambda, les microservices, les conteneurs.
avec les évolutions techniques, les nouveaux
langages, les nouvelles technologies. Ces Dans cette 1ere partie : nous parlerons de
évolutions ont un impact direct sur les microservices et Java. La rédaction.

Les architectures microservices


L’architecture Microservices a fait couler beaucoup d’encre dernièrement : il est le temps de faire le point.
Jérôme Plusieurs raisons expliquent cela. Au début Un autre effet pervers de l’architecture
Doucet, d’un projet, quand celui-ci est encore de petite monolithique est de rendre une application
taille, elle reste très simple à comprendre dépendante à certaines technologies,
et favorisant la maintenabilité et la testabilité. Le obligatoirement compatibles entre elles. Choisir
Romain déploiement, facile et rapide à mettre en place, Java limitera les évolutions futures aux
Niveau,
permet de se concentrer sur les fonctionnalités technologies compatible avec la JVM, C# aux
Consultants plutôt que sur l’infrastructure. Il permet technologies Microsoft, etc. Si un framework
Xebia également de faire de l'intégration continue à utilisé par l’application devient obsolète, la
peu de frais. Cependant, au cours de l'évolution migration vers un nouveau peut nécessiter la
L'idée derrière ce terme est d’isoler chaque d’un projet, cette architecture montre réécriture complète de l’application avec les
fonctionnalité dans un composant qui lui est fréquemment ses limites. risques que cela comporte.
propre. Les différents services découlant de ce
découpage communiquent au travers du Maintenabilité du code Déploiement en continu
réseau plutôt que par des appels de fonctions Si en début de projet, la simplicité du modèle Une application monolithique semble simple à
dans un processus. Une application monolithique favorise grandement la déployer. Puisque toute l’application est
microservices représente alors un système compréhension du code, ceci devient de moins destinée à s'exécuter sur un même serveur,
constitué d’un certain nombre de petites unités en moins vrai au fur et à mesure que le volume celle-ci est très souvent contenue dans une
indépendantes qui collaborent entre elles, de code augmente, et ce, même avec une archive déployée sur celui-ci. Une usine
ayant chacune un cycle de vie et une organisation rigoureuse de ce dernier. Un logicielle pourra rapidement et facilement être
responsabilité propre. nouveau venu mettra davantage de temps à configurée avec les taches de déploiement
Cette architecture répond à des problèmes être pleinement opérationnel. adéquates. Cependant, déployer toute
récurrents que posent les architectures Parce qu’il n’y a pas de frontières fortes entre l’application, quelles que soient les
monolithiques traditionnelles. les modules d’une application monolithique, modifications réellement effectuées, pose
elles auront tendance à s’effacer, affaiblissant divers problèmes. Premièrement, le temps de
LES CONCEPTS la modularité, complexifiant les relations de déploiement s’allonge, tendant à limiter leur
Les Architectures monoli- dépendance. Le code devient de moins en nombre. En effet, la taille de l’application
thiques et leurs problèmes moins lisible et testable, la productivité et la augmentant, le container prend plus de temps
L’architecture monolithique est l’une des plus qualité baisse et enfin la dette technique pour effectuer les démarrages applicatifs.
répandues dans les projets informatiques. s’accumule. En conséquence, le déploiement continu

46 Programmez! a Décembre 2015


devient plus complexe, ce qui engendre une dont le code est séparé. De la même façon, la LA MISE EN OEUVRE
augmentation des risques associés à chaque présence d’une anomalie sur une fonctionnalité
déploiement et une perte de productivité. ne bloque pas l’évolution ou le déploiement Quels outils ?
d’une autre. Il est possible, grâce à ces Cloud
Scalabilité caractéristiques, d’envisager de prototyper, Les architectures microservices ont besoin
Lorsque la charge d’une application augmente, déployer et tester une nouvelle fonctionnalité d’une infrastructure souple et robuste à la fois.
la scalabilité de l’application devient un point sans remettre en cause l’ensemble des Un nouveau serveur doit pouvoir être
critique. Une application monolithique n’ayant services. Dans cette architecture, l’échelle de la provisionné en quelques minutes pour
qu’une capacité assez limitée (car celle-ci ne se modification est donc, non pas un ensemble de permettre à un service de monter en charge
fait que dans une dimension), on ne peut avoir fonctionnalités assemblées dans une rapidement. Il doit également pouvoir être
que des copies de l’application entière. Or les “application”, mais la fonctionnalité, portée par décommissionné facilement si celui-ci n’est
différents composants de l’application n’ont le service. plus utile. Le Cloud représente le candidat
vraisemblablement pas les mêmes besoins en privilégié pour répondre à ces besoins. Des
ressource. Certains vont faire un usage intensif Services et communication solutions de Cloud public comme AWS
du processeur, d’autres de la mémoire, Pour que le système fonctionne correctement, il d’Amazon ou Azure de Microsoft permettent de
d’autres des entrées / sorties. Scaler une est donc nécessaire que les services réaliser ces opérations pour un coût moindre
application monolithique peut entraîner une communiquent entre eux. Le vecteur de cette par rapport à une infrastructure privée. Ils
augmentation de la consommation des communication a pour unique rôle d’assurer proposent de nombreux services allant du
ressources conséquentes de manière inutile. une transmission fiable des messages. Le provisionning de CDN aux solutions d’API
système suit la règle suivante : “Smart end management. Du coté des Clouds privés,
Les principes de point, dumb pipe”. L’intelligence du système OpenStack se place comme la solution
l’architecture microservices est contenue dans les services, pas dans le permettant de construire son propre Cloud. La
Une nouvelle échelle vecteur. Les deux modes de communication les solution est sponsorisée par des sociétés
Ce qui est le plus visible de prime abord est le plus courants sont celles de type REST et bus. comme Google ou encore Red Hat.
changement d'échelle qui s'opère avec les Lorsqu’un service dépend de messages fournis
microservices. L’application devient un par d’autres services en amont, la Conteneurs
système d’informations, dont le microservice communication est généralement asynchrone et Issue de travaux anciens sur le système
constitue l'unité élémentaire. Ces unités sont une architecture microservices va tendre vers d’exploitation Unix (les C-groups), la
strictement indépendantes les unes des autres. une architecture réactive, à base d’évènements conteneurisation arrive aujourd’hui à maturité,
Elles ont chacune leur propre base de code de déclenchés et écoutés par les services. le projet Docker en est l'exemple le plus
donnée et pile technologique. Chaque service significatif. Cette technique consiste à isoler
peut ainsi utiliser les technologies les plus Tolérance et monitoring l’utilisation des ressources de type processeur,
adaptées à son besoin. Il devient aussi possible Une des grandes forces des architectures mémoire et disque par application sur une
d’allouer les ressources souhaitées à chaque microservices est sa robustesse et sa tolérance même machine. L’utilisation de ces
type de service. Il est également envisageable aux pannes. En effet, plutôt que de se protéger à technologies dans une architecture
de choisir un nombre d’instances différent par tout prix de ce qui pourrait poser problème dans microservices offre un avantage indéniable.
service, améliorant grandement l'efficacité de la le système, l’approche adoptée par les Chaque service correspond à une image, livrée
scalabilité. Un service devant supporter une microservices est l’adaptation. Un service est sur un «catalogue» d’entreprise. Celle-ci peut
forte charge possède plus d’instances conçu dans l’optique que le reste du système être construite et mise à disposition
d'exécutions qu’un service faiblement sollicité. puisse être disponible, qu’une donnée nécessaire directement par l’usine logicielle. Ainsi, il n’est
Selon le même principe, les données d’un puisse être absente ou au contraire qu’un plus nécessaire de s’adapter à des principes
service peuvent être mises à jour, migrées, message puisse contenir des données de déploiement propre à chaque écosystème
traitées sans risquer d’impacter les autres superflues. Le service est alors capable de logiciel (JEE, Play, Vert.x, Node.js, Python, etc.).
fonctionnalités du système. Dans une fonctionner à la fois en mode nominal et en mode Le déploiement est uniformisé et simplifié : il
architecture microservices, chaque service est dégradé. De plus, ses interfaces, suffisamment s’agit de déployer un conteneur par
différent évoluant selon son propre rythme. souples, supporteront les écarts. microservices. La conteneurisation facilite
Malgré cette tolérance, le système doit être également les tests d’intégration, qu’ils soient
Évolutivité et automatisation surveillé en permanence. Les pannes peuvent réalisés sur le poste du développeur ou sur un
Lorsqu’une fonctionnalité précise du SI doit compromettre le fonctionnement du système serveur dédié. En effet, il est beaucoup plus
être modifiée, l’évolution en question ne porte global. Ainsi, il devient nécessaire d’être capable facile de recréer de toutes pièces des
que sur le code d’un service en particulier. Les de détecter rapidement une panne pour pouvoir environnements à base de conteneurs que de
autres services ne seront pas impactés. Ainsi, intervenir. Il est également important de surveiller créer une infrastructure physique supportant un
la modification du code ou des données d’un le système et les services d’un point de vue monolithe et ses dépendances, à l’image de la
service provoque uniquement la mise à jour et fonctionnel. Son bon fonctionnement passe par la production. La boucle de feedback, ainsi
le redéploiement de celui-ci car il s’exécute surveillance d’indicateurs métiers : transactions accélérée, est portée directement par l’usine
dans un processus isolé. Il n’y a aucune validées, en erreur, quantité de commandes, logicielle et ne nécessite plus de déploiement
obligation d’embarquer des mises à jour envois de messages en erreur, nombre sur un environnement identique à la production
d’autres fonctionnalités développées en d’inscriptions, etc. Tous ces indicateurs métiers décorrélé du cycle de développement.
parallèle, celles-ci impactant d’autres services sont les premiers révélateurs d’un problème. On touche ici à une problématique à la limite

Programmez! a Décembre 2015 47


services en un seul "macroservice" afin de faciliter
des mondes Dev et Ops. Le choix de cette utilisé dans une architecture microservices. Sa la communication entre celui-ci et le reste du SI.
technologie, impactant toutes les couches du légèreté, sa rapidité d'exécution couplée à la Ceci va regrouper la complexité des services en
SI, doit se faire de manière concertée. rapidité du développement lié au langage un seul qui va de facto, devenir plus difficilement
Javascript en font un très bon candidat pour maintenable. Un autre écueil est la tentation du
Supervision des microservices. Le modèle i/o non bloquant “nanoservice”. Transformer chaque méthode
Les bases de données de type Time Series de node.js lui permet de tenir particulièrement d’une application monolithique en microservice
permettent de stocker, avec une grande bien la charge. générera une quantité importante de services. La
fiabilité, des métriques à intervalles réguliers. communication de ses services n’en sera que
Les équipes opérationnelles ont l’habitude de Quelle organisation ? plus complexe pour un apport limité en termes de
travailler avec ce type de bases qui permettent La mise en place d’une architecture souplesse. Il est donc important de trouver un
de récolter les informations minimales utiles à microservices dans des équipes implique une juste milieu entre des services imposants et des
la détection des pannes. Il s’agit en général des certaine réorganisation. Une architecture services trop petits. Une règle communément
métriques bien connues comme le CPU, la microservices induit des micro-équipes, en admise est: une personne qui découvre un
mémoire, l’espace disque, les entrées / sorties, interaction constante, connaissant parfaitement service doit pouvoir en comprendre le code et le
etc. Les développeurs y portent un intérêt le métier et la technique des quelques services fonctionnel en une journée.
croissant, en particulier pour stocker des à leur charge. Les services correspondent à
métriques applicatives, techniques voire une fonctionnalité issue d’un besoin métier Manque d’automatisation
métiers. Graphite, très populaire ces dernières autour duquel s’organise une équipe (Feature La philosophie des microservices est de
années, a atteint ses limites en termes de team) qui a la maîtrise du produit. pouvoir ajouter rapidement et simplement des
scalabilité. On lui préférera donc des projets De la multiplicité des services découle le services à un système. Si le temps de
plus récents, embarquant nativement la notion besoin d’automatisation des déploiements. Il déploiement ou le redémarrage d’un service
de clustering tels que InfluxDb, entièrement n’est plus envisageable lorsque les services se nécessite une intervention humaine coûteuse
compatible avec Graphite, talonné de près par comptent en dizaines de les déployer en temps, alors le système se confrontera à un
OpenTSDB. Le stockage des données est manuellement. En conséquence, les équipes problème. Pour l’éviter et permettre un système
important, l’exploitation et la visualisation le doivent accueillir de nouveaux processus évolutif et résilient, il faut automatiser au
sont tout autant. Aucune des bases de d’automatisation dans lesquels l’outil occupe maximum les déploiements d’applications mais
données nommées ci-dessus ne propose de une place importante. Le mouvement DevOps également l’ajout de nouveaux serveurs. Pour
système d’alerte. En revanche, elles s'intègrent est la continuité logique de la mise en place cela, le Cloud permet de bénéficier de
très facilement avec des outils classiques d’une architecture microservices, permettant capacités machines quasiment illimitées et des
d’exploitation, comme Nagios, Shinken, Icinga réactivité et souplesse en production. outils, comme Docker, facilitent
ou Sensu. Les outils de dashboarding basés Enfin, du point de vue des évolutions, il est l’automatisation des déploiements et la
sur Graphite sont nombreux et leurs évolutions important de garder un contrôle et une vision réplication des services.
récentes permettent de s'intégrer facilement d’ensemble, grâce, par exemple, à une
avec InfluxDb. Le projet le plus populaire est cartographie de son SI. Celle-ci permet de ne Système de supervision défaillant
Grafana. pas développer des fonctionnalités identiques La multiplicité des services entraîne une
et de connaître le spectre technologique dont complexification de la supervision du système.
Framework est composé son SI. Ainsi, on veille à appliquer Que la communication entre services se passe
Les services des architectures microservices les correctifs de sécurité sur l’ensemble de son par bus de messages ou par APIs, cette
sont par définition légers en code et en parc technologique et ne pas s’exposer aux supervision doit être automatisée au maximum.
fonctionnalités. Il doit donc en être de même attaques dirigées vers des versions En effet, le nombre de services croît
pour les frameworks utilisés au sein de ces vulnérables. régulièrement au fur et à mesure de la vie du
services. Par exemple, Vert.x apporte plusieurs système. Il devient vite impossible pour un
briques nécessaires dans la communication LES LIMITES humain de suivre tous les services
entre services comme un bus de messages ou De nouveaux problèmes ? manuellement. Pour pallier ce problème,
un serveur de websocket. Léger, son coté Les microservices proposent des solutions à chaque service doit fournir ses propres
polyglotte permet de choisir le bon langage des problématiques connues et héritées métriques au système de monitoring. Elles
pour le bon service tout en ayant la même d’architectures orientées services déjà en doivent être techniques mais également
base, ce qui est un plus en termes de place. Néanmoins, toute nouvelle solution business afin de pouvoir mesurer en temps réel
cohérence pour le système. Spring Boot apporte des problèmes qu’il est possible l’apport métier d’un service. Des règles
permet quant à lui de développer rapidement d'identifier afin de s’en prémunir. d’alertes automatiques doivent être mises en
des services grâce à ses différents profils place afin de savoir lorsqu’un service
d’application prêts à l’emploi. L’objectif de Taille des services commence à ne plus fonctionner correctement.
Spring Boot est de pouvoir déployer facilement Le plus grand principe des microservices L’idéal est de disposer d’un système autonome
des applications standalone embarquant elles- concerne la taille de ces services. Celle-ci n’est capable de relancer un serveur défaillant de
mêmes le serveur choisi (tomcat ou jetty), le pas régie par des règles précises du fait de manière automatique, toujours sans
tout fournissant par défaut des métriques l’absence (souhaitable) de norme ou de intervention humaine.
permettant un suivi de l’application en spécification. Plusieurs pièges sont toutefois à Un autre problème lié à cette multitude de
production. Enfin, sans en être un framework, éviter. Il est fréquent lors du développement de services est l’exploitation des fichiers de logs.
node.js représente un exemple type d’outil services de vouloir regrouper plusieurs “petits” Pour un service unique déployé sur plusieurs

48 Programmez! a Décembre 2015

Vous aimerez peut-être aussi