Architecture Logicielle

Introduction 

L’architecture logicielle décrit d’une manière symbolique et schématique les différents éléments d’un ou plusieurs systèmes informatiques, leurs interrelations et leurs interactions.

Les architectures évoluent avec le temps et les technologiques qui sortent. Par le passé beaucoup d’applications étaient développées de façon monolithique, c’est à dire qu’une application embarquait énormément de fonctionnalités.

Contraintes à respecter

Lorsque l’on définit une architecture, et plus globalement lorsque l’on développe des fonctionnalités, les points clés suivants sont toujours à garder en tête :

• Echange et stockage de données 
  • Les données qui transitent sur votre application sont une source importante de temps de réponse côté utilisateur
  • Il faut faire attention à ces échanges de données mais également au stockage de celles-ci, qui peut rapidement devenir volumineux
• Temps d’exécution 
  • Le temps de traitement des fonctionnalités que vous écrivez a également un impact fort sur l’expérience utilisateur
  • Pensez à optimiser le temps de traitement au moins de manière à ne pas bloquer l’interface utilisateur
• Bande passante et sécurité réseau
  • En lien avec les données qui transitent sur votre réseau, faite également attention au coût que cela peut avoir sur votre infrastructure ainsi à l’exposition de celles-ci.
  • Les données doivent toujours être servies de manière sécurisée
• Ressources physiques
  • votre application, qu’elle soit hébergée dans le cloud ou non, utilise des ressources physiques qui ont une capacité définie.

Architecte logiciel 

Prenons ici l’exemple d’un architecte logiciel basé sur la technologie PHP

Phase de démarrage 

Durant cette phase, l’architecte aura pour objectif de :

• Définir les bonnes pratiques à utiliser sur le projet : le respect des PSR, bonnes pratiques Symfony, designs patterns à utiliser
• Définir les design patterns adaptés pour les différents besoins de l’application
• Définir les procédures et outils pour l’industrialisation du projet ( tests unitaires, fonctionnels ainsi que la livraison de l’application)
• S’assurer que chaque développeur a une bonne compréhension technique du projet et respecte les bonnes pratiques

Phase de développement

• L’architecte devra s’assurer que la technologie et éventuellement le framework utilisé soient utilisés correctement par les équipes. L’application doit être pleinement fonctionnelle et opérationnelle.
• Le rendu à l’utilisateur final doit être correct, ce qui implique un bon déroulé côté serveur mais également que les interactions avec les outils tiers comme les bases de données ne posent pas de problème.

Phase d’évolution 

• Une fois le projet en production, il devra anticiper les nouvelles fonctionnalités de l’application. es technos évoluant avec le temps, son rôle est également de prévoir les migrations vers de nouvelles versions de la technologique, du framework et outils présents sur le projet

Architecte solution

L’architecte solution lui, doit répondre à des problématiques plus variées sur les projets : il n’est pas forcément expert sur une technologie en particulier mais doit avoir une bonne visibilité sur l’ensemble des technologies disponibles

Phase de démarrage

• Il a la tâche complexe de faire le choix des technologies les plus adaptées pour à la fois répondre le mieux au besoin, mais aussi faire attention à avoir les ressources humaines nécessaires pour utiliser ces technologies.
• Il peut bien évidement s’appuyer sur l’aide d’un architecte logiciel afin d’obtenir des réponses plus précises sur une technologie

Phase de développement

• Il doit s’assurer que les équipes techniques ne rencontrent pas de problèmes sur l’utilisation des différentes briques logicielles retenues.
• Il va auditer la plateforme en cours de développement afin de détecter d’éventuelles failles de sécurité, soucis de performances, problèmes de flux de données entre les briques

Architecte d’entrerpise

Le rôle d’un architecte d’entreprise est plutôt de garder une visibilité sur l’ensemble des projets développés dans la société afin de garantir une cohérence des choix technologiques

Il est responsable de la cartographie globale du système d’information de la société. Cela lui permet de s’assurer qu’une première application puisse par exemple interagir avec une seconde application déjà existante, plutôt que de re-développer une solution identique

Quelques design patterns application

Observer 

• Avantages 
  • Il permet de développer des applications dont le code applicatif réagit à des événements, ce qui permet de mieux découper son code en services métier, le but étant d’éviter de mélanger différents traitements métiers.
  • Code orienté service : chaque portion de code métier est découpée dans un service dédié
  • Code plus facile à tester : il suffit en effet de tester chaque portion de service unitairement
  • Moins de couplage de code entre les services
  • Résilience à la panne : si un service A contient un bug, un service B pourra tout de même être exécuté correctement
• Inconvénients
  • Dans un certains contextes sans complexité métier, l’utilisation de ce pattern peut complexifier la compréhension du code
  • Ce pattern ne fait transiter qu’un seul objet : il faut coupler les données si vous avez plusieurs objets à faire transiter

Architecture Hexagonale 

• Le pattern d’architecture hexagonale structure grandement le code de votre application en centralisant le code métier et en développant des couches d’abstraction
• Vous devez écrire des couches  d’abstraction pour les éléments suivants :
  • communiquer avec BDD (couche de persistance)
  • rendre différents vues tel que le rendu web et mobile (couche de présentation)
  • accepter plusieurs types d’accès en exposant des web services Rest, GraphQL ou SAOP
• Avantages 
  • Permet de garder le code métier complètement agnostique des différentes couches
  • Permet de se concentrer sur le code métier lorsqu’une fonctionnalité doit être développée, sans se soucier du reste
  • Il suffit d’ajouter un adapter, en se basant sur les interfaces métiers pour pouvoir intégrer un nouveau service
• Inconvénients 
  • You Are not Gonna Need It : la mise en place de ce pattern d’architecture nécessite d’avoir le besoin de mettre en place plusieurs couches d’abstraction, à différents niveaux, afin que son choix soit perçu comme bénéfique

Micro-Services

Auparavant, beaucoup d’applications étaient développées en mode dit « monolithique », cela signifie que tous les besoins étaient centralisés dans une même application et sous une même technologie.

Avec l’arrivée des hébergements cloud et de la conteneurisation, il est maintenant plus facile de découper ces applications en plusieurs applications (services) indépendantes : on parle alors de micro-service

Concrètement, un micro-service répond à un besoin métier particulier, par exemple : s’occuper de toute la gestion de a facturation 

Avantages

• Un besoin métier correspond à un projet : le code à l’intérieur de chaque projet est donc concentré à répondre à un seul besoin métier
• Possibilité de déployer fréquemment un service sans impacter les autres
• Possibilité de déployer des serveurs additionnels pour un seul service uniquement (scalabilité)
• Possibilité d’utiliser une technologie différente pour chaque service

Inconvénients

• Nécessite de passer plus de temps sur les tâches d’industrialisation et de déploiement car elles varient d’un service à un autre.
• Il faut prévoir gérer les erreurs de communication entre les services avec la mise en place de systèmes comme un circuit breaker, du fallback
• Il faut tenir compte des soucis de dégradations de performances réseau : mettre en place d’un système d’élection, de synchronisation de données.

Orienté événements

Comme c’est souvent le cas pour les micro-services, les services doivent être capables de communiquer entre eux, ou en tout cas de réagir aux événements des autres.

Si l’on imagine un micro-service de prise de commande en ligne, lorsqu’il reçoit une nouvelle commande, un micro-service de gestion de facturation doit prendre la main pour générer une facture

Avec un pattern orienté événements, le service de prise de commande va ici publier un événement dans un bus applicatif (kafka ou RabbitMQ) et le service de facturation pourra ensuite souscrire à ce type d’événement et réagir en fonction

• Avantages
  • Ce pattern permet de clarifier les échanges : le bus applicatif centralise en effet tous les flux d’événements qui peuvent avoir lieu
  • Chaque service peut souscrire librement aux notifications qui l’intéressent
  • Scalabilité accrue : il est possible d’augmenter les ressources de consommation d’un événement en particulier en cas de fort trafic, plutôt que d’altérer toute l’application.
• Inconvénients 
  • Il faut faire attention aux pertes potentielles d’événements / messages / changements d’état. Nécessite la mise en place de « retry » et de palier le pluf fortement possible aux erreurs réseau

FAAS – ServerLess

Après avoir vu quelques patterns qui permettent de découper son code applicatif en service métier, la tendance est aujourd’hui au « Function as a Service » (FAAS), aussi appelé « Serverless ». 

L’idée est de déclencher des fonctions (portions de code) exécutant chacune une action particulière : ajout de données en base de données, récupération de données.

Ces fonctions peuvent être déclenchées par des appels API mais aussi par des événements sur votre plateforme. Par exemple lors de l’envoi d’un fichier sur votre serveur de stockage

• Avantages
  • Ne requiert pas d’administration système : ceci est totalement géré par votre plateforme
  • Coûts d’infrastructure réduits car les ressources sont utilisées uniquement lors des déclenchements de fonctions
  • Réduit la complexité de votre application en divisant le code en fonctions métier
• Inconvénients 
  • Un petit temps de démarrage à froid est nécessaire lorsque la fonction n’a pas été exécutée depuis un petit moment
  • Vous dépendez de votre plateforme : les fonctions de déclenchement sont spécifiées sur la plateforme sur laquelle vous développez

 

Les concepts cités dans cet article doivent être connus par chaque développeur. Il est toujours important de garder à l’esprit la performance et la sécurité de l’application (temps d’exécution/réponses, données transférées…)

 

Référence : Livre Blanc rédigé et édité par Eleven Labs