Une architecture d'application, qu'est-ce que c'est ?

Une architecture d'application décrit les modèles et les techniques utilisés pour concevoir et créer une application. L'architecture fournit une feuille de route ainsi que les meilleures pratiques à suivre pour créer une application bien structurée.

Pour construire une application, vous pouvez vous aider de modèles de conception logicielle. Un modèle décrit une solution reproductible à un problème.

Il est possible de lier plusieurs modèles pour créer des architectures d'applications plus génériques. Au lieu de créer vous-même l'architecture de bout en bout, vous pouvez utiliser des modèles de conception existants et ainsi vous assurer que tous les éléments fonctionneront comme prévu.

Une architecture d'application comprend les services front-end et back-end.Le développement front-end concerne l'expérience utilisateur de l'application, tandis que le développement back-end permet de fournir l'accès aux données, aux services et à d'autres systèmes dont dépend l'application.

L'architecture est le point de départ ou la feuille de route pour créer une application. Vous devrez cependant effectuer les choix de mise en œuvre que l'architecture n'inclut pas. Par exemple, le choix du langage de programmation est la première étape pour écrire une application.

Il existe de nombreux langages de programmation pour le développement logiciel. Certains langages sont utilisés pour créer certains types d'applications, par exemple Swift pour les applications mobiles ou JavaScript pour le développement front-end. 

JavaScript, associé aux langages HTML et CSS, figure actuellement parmi les langages de programmation les plus utilisés pour le développement d'applications web. 

D'autres langages de programmation sont aussi largement utilisés : Ruby, Python, Swift, TypeScript, Java, PHP et SQL. Le choix du langage dépend du type d'application à créer, des ressources de développement disponibles ainsi que d'autres facteurs. 

Auparavant, les applications étaient rédigées sous la forme d'une seule unité de code, où tous les composants partageaient les mêmes ressources et le même espace mémoire. C'est ce que l'on appelle une architecture de type monolithique.

Actuellement, les architectures d'applications sont généralement faiblement couplées. Elles reposent sur des microservices et des interfaces de programmation d'application (API) qui connectent les services. Ces architectures peuvent ainsi servir de base pour les applications cloud-native. 

Le développement cloud-native est une manière d'accélérer la création des nouvelles applications, d'optimiser les applications existantes, d'harmoniser le développement et d'automatiser la gestion pour l'ensemble des clouds privés, publics et hybrides.

Avant de décider quelle architecture d'application utiliser pour votre nouvelle application, ou avant d'évaluer votre architecture actuelle, commencez par déterminer vos objectifs stratégiques.

Vous pourrez alors concevoir une architecture qui répondra à vos objectifs, au lieu de commencer par choisir une architecture et ensuite adapter votre application à cette structure. 

Tenez compte de la fréquence à laquelle vous souhaitez publier des mises à jour pour répondre aux besoins de l'entreprise ou du client, ainsi que des fonctionnalités requises pour atteindre les objectifs métier ou simplifier le développement. 

La distribution rapide de nouveaux services ou fonctionnalités est aujourd'hui l'un des meilleurs moyens pour une entreprise de se démarquer de la concurrence. De plus, en accélérant le développement, l'entreprise peut publier de nouvelles fonctionnalités plus régulièrement et déployer des mises à jour dès qu'une vulnérabilité est découverte.

Il existe de nombreux types d'architectures d'applications différents, au sein desquelles les relations entre les services sont plus ou moins couplées : les architectures monolithiques et multiniveaux (étroitement couplées), les architectures de microservices (découplées) et les architectures orientées événements ou services (faiblement couplées).

Une architecture en couches ou multiniveau est une architecture classique, souvent utilisée pour créer des applications d'entreprise ou sur site. Elle est fréquemment associée aux applications d'anciennes générations.

Une architecture en couches est constituée de plusieurs couches ou niveaux (souvent trois, parfois plus) qui forment l'application. Chaque couche a des responsabilités distinctes. 

Les couches permettent de gérer les dépendances et d'exécuter des fonctions logiques. Elles sont disposées horizontalement, de sorte qu'elles ne peuvent faire appel qu'aux couches inférieures. 

Ainsi, chaque couche peut faire appel soit à la couche directement au-dessous d'elle, soit à n'importe quelle autre couche inférieure. 

L'architecture monolithique est également associée aux systèmes d'anciennes générations. Il s'agit d'une unique pile d'application qui rassemble toutes les fonctionnalités au sein d'une seule application. Elle est étroitement couplée, tant au niveau des interactions entre les services qu'au niveau des processus de développement et de déploiement. 

La mise à jour ou la mise à l'échelle d'un seul composant d'une application monolithique peut avoir des effets sur toute l'application, ainsi que sur son infrastructure sous-jacente. 

Après chaque changement apporté au code de l'application, il faut publier à nouveau l'application tout entière. De ce fait, les mises à jour et les nouvelles versions ne peuvent être publiées qu'une à deux fois par an et elles n'incluent souvent que de la maintenance générale, à défaut de nouvelles fonctions. 

Au contraire, les architectures modernes essaient de décomposer les services en fonctionnalités ou en capacités métier, pour fournir davantage d'agilité.

Les microservices désignent à la fois une architecture et une approche de développement logiciel, qui consiste à décomposer les applications en éléments les plus simples, indépendants les uns des autres. Chacun de ces composants ou processus est un microservice.

Les microservices sont distribués et faiblement couplés, ils n'ont donc pas d'incidence les uns sur les autres. Ces caractéristiques offrent des avantages au niveau de l'évolutivité dynamique et de la tolérance aux pannes : il est possible de mettre à l'échelle des services individuels sans nécessiter une infrastructure lourde, et d'effectuer leur basculement sans affecter les autres services.

Avec une architecture de microservices, l'objectif est de fournir rapidement des logiciels de qualité. Il est possible de développer plusieurs microservices simultanément. De plus, puisque les services sont déployés indépendamment, vous n'avez pas à recréer ou redéployer toute l'application après chaque modification. 

Plusieurs développeurs peuvent ainsi travailler sur leurs services individuels en même temps, sans qu'il y ait besoin de mettre à jour toute l'application. Cela permet de réduire la durée du développement et de publier de nouvelles fonctions plus souvent.

Avec les API et les pratiques DevOps, les microservices conteneurisés constituent la base des applications cloud-native.

Dans un système orienté événements, la structure centrale de la solution repose sur la capture, la communication, le traitement et la persistance des événements. C'est ce qui différencie ce type de système du modèle traditionnel orienté requêtes.

Un événement désigne tout phénomène ou changement d'état significatif au niveau du matériel ou d'un logiciel système. Les événements peuvent être causés par des actions internes ou externes.

Une architecture orientée événements est faiblement couplée. Elle est donc adaptée aux architectures d'applications modernes distribuées.

Ce type d'architecture implique des producteurs et des consommateurs d'événements. Un producteur d'événements détecte ou reconnaît un événement et le représente sous forme de message. Il ignore quels seront les consommateurs et les conséquences de chaque événement.

Lorsqu'un événement a été détecté, il est transmis du producteur d'événements au consommateur via des canaux d'événement, où une plateforme de traitement les prend en charge de façon asynchrone.

Une architecture orientée événements peut être basée sur un modèle de publication/abonnement ou sur un modèle de flux d'événements.

Le modèle de publication/abonnement repose sur l'abonnement à un flux d'événements. Lorsqu'il est utilisé, chaque fois qu'un événement se produit ou est publié, il est envoyé aux abonnés qui doivent en être informés.

Dans le modèle de flux d'événements, les consommateurs d'événements ne s'abonnent pas à un flux spécifique. Ils peuvent accéder à n'importe quelle partie du flux et le rejoindre à tout moment.

Les événements sont capturés régulièrement à partir de sources d'événements telles que des périphériques IoT, des applications et des réseaux. Les producteurs et les consommateurs d'événements peuvent ainsi partager en temps réel les informations d'état et de réponse.

L'architecture orientée services (SOA) est un modèle de conception largement utilisé, similaire au modèle d'architecture de microservices. 

L'architecture orientée services structure les applications en services individuels et réutilisables qui communiquent via un ESB. 

Au sein de cette architecture, chacun des services individuels (organisés autour d'un processus métier spécifique) suit un protocole de communication (tel que SOAP, ActiveMQ ou Apache Thrift) pour « s'exposer » via la plateforme d'un ESB. L'entreprise ou le client se sert d'une application front-end pour utiliser cette suite de services, intégrés au moyen d'un ESB.

Les solutions Red Hat vous permettent d'améliorer l'agilité métier en décomposant vos applications monolithiques en microservices. Vous pouvez alors les gérer, les orchestrer et traiter les données qu'ils génèrent pour aider vos équipes à fournir plus rapidement des solutions de qualité à vos clients.  

Vous pouvez ainsi développer des applications métier tournées vers l'avenir, c'est-à-dire des applications cloud-nativeagiles et évolutives, qui sont intégrées dès le début à vos autres activités.

Dans cette série de webinars, plusieurs experts partagent leur point de vue sur la manière de créer, d'exécuter, de déployer et de moderniser vos applications avec une plateforme de données d'entreprise sur Red Hat® OpenShift®.

Il n'est pas nécessaire de remanier totalement vos systèmes pour en tirer des avantages significatifs. En effet, grâce à l'Open Source, aux normes ouvertes et à nos nombreuses années d'expérience, nous sommes en mesure de vous aider à identifier la solution basée sur des microservices qui répondra le mieux aux besoins de votre entreprise.

Avec notre gamme de solutions Open Source qui comprend Red Hat® Enterprise Linux®, Red Hat OpenShift et Red Hat Application Services, nous pensons être le partenaire idéal des entreprises qui doivent se transformer pour préserver leur compétitivité sur les marchés en constante évolution, dominés par les logiciels.