Quatre choix d’architecture pour le développement d’applications à l’ère numérique

Nous connaissons tous l’architecture d’application à 3 niveaux. Il s’agit d’une architecture client-serveur dont la structure typique est composée d’une couche de présentation, d’une couche d’application et d’une couche de base de données.

Elle dispose d’une interface utilisateur, d’une logique d’accès métier/aux données et d’un accès aux données. De nombreuses applications d’entreprise ont été créées à l’aide d’une architecture d’application à 3 niveaux simple.

Tout simplement, le modèle d’application à 3 niveaux est obsolète. Il a été conçu pour le développement d’applications avant la prolifération du cloud public et les applications mobiles et a eu du mal à s’adapter au cloud.

Au fil du temps, une application peut devenir trop volumineuse et complexe pour effectuer des modifications fréquentes. De plus, elle nécessite la maintenance d’au moins trois couches de matériel et de logiciels, ce qui peut s’avérer inefficace pour l’entreprise. 

Le modèle d’application à 3 niveaux est également souvent appelé architecture monolithique. Aujourd’hui, nous disposons de nombreux nouveaux modèles d’architecture, et nous en examinerons quelques-uns ci-dessous, qui sont disponibles à l’ère cloud.

Dans un modèle cloud, une application complexe conçue comme un ensemble de services et de données est totalement découplée du site application. Les microservices sont un style architectural qui structure l’application comme une collection de services. Chaque service peut être écrit dans un langage de programmation différent et testé séparément. Ils peuvent être déployés de manière indépendante et sont organisés autour des capacités de l’entreprise.

Prenons l’exemple d’une application de commerce électronique développée à l’aide d’une architecture de microservices. Chaque microservice peut se concentrer sur une seule fonctionnalité métier (par exemple, panier d’achat, recherche, avis client). Chacun d’entre eux peut constituer un service distinct écrit dans différents langages de programmation, déployer dans différentes infrastructures et géré par différentes équipes.

Chaque service communique avec les autres à l’aide d’un protocole léger. Pour un développement à 3 niveaux, tout le monde connaît le cadre des exigences Model View Controller (MVC). Sidecar, Defender et Adapter font partie des frameworks qui prennent en charge les architectures de microservices.

Architecture de microservice ou architecture monolithique

Dans l’architecture monolithique, tous ces composants coexistent en un seul module géré (principalement) par une seule équipe. Tout est regroupé. Si vous devez effectuer une mise à jour, vous devez déployer l’application entière, ce qui ralentit les modifications apportées aux applications plus complexes. Pour les petites applications, l’architecture monolithique est souvent la meilleure solution.

Microservices, conteneurs et Kubernetes

L’un des meilleurs choix pour créer et exécuter des architectures d’applications de microservices est d’utiliser des conteneurs. Les conteneurs encapsulent un environnement d’exécution de virtualisation léger pour votre application et vous permettent de déplacer l’application du bureau du développeur jusqu’au déploiement en production. Vous pouvez exécuter des conteneurs sur des machines virtuelles ou des machines physiques dans la majorité des systèmes d’exploitation disponibles. Les conteneurs présentent un environnement logiciel cohérent et vous pouvez encapsuler toutes les dépendances de votre application en tant qu’unité déployable. Les conteneurs peuvent s’exécuter sur un ordinateur portable, un serveur bare metal, ou dans un cloud public.

De nombreuses entreprises utilisent Kubernetes pour gérer les conteneurs et éviter le temps d’arrêt. Kubernetes assure l’orchestration des conteneurs sur plusieurs hôtes et est utilisé pour la gestion du cycle de vie des conteneurs. Vous pouvez automatiser le déploiement, redimensionner automatiquement votre application, créer et expédier rapidement grâce à Kubernetes.

Pour en savoir plus sur Kubernetes, regardez notre vidéo « Kubernetes expliqué » :

Red Hat OpenShift est l’une des principales plateformes de conteneurs d’entreprise de cloud hybride les plus populaires. De nombreux fournisseurs de cloud public proposent le CaaS (conteneurs en tant que service). Parmi les autres moteurs Kubernetes disponibles, citons IBM Cloud Kubernetes Service, Kubernetes open source, AWS (EKS, ECS et Fargate), Google GKS et Azure AKS.

En général, chaque microservice est développé par une petite équipe différente, et celle-ci choisit son langage de programmation et son calendrier de déploiement. Un maillage de services comme Istio est utilisé par les entreprises pour régir la communication entre les microservices et la gestion. Dans un maillage de services, les requêtes sont acheminées via des proxys (tels que Sidecar) entre les microservices.

L’architecture cloud natif est spécifiquement conçue pour les applications qui doivent être déployées dans le cloud, et les microservices sont une partie essentielle.

Le cloud natif est une approche de la création et de l’exécution d’applications qui exploite les avantages du modèle de livraison de cloud computing. Le cloud natif est un terme utilisé pour décrire les environnements basés sur des conteneurs, et il s’agit de savoir comment les applications sont créées et déployées, et non où.

Les technologies cloud natif nous permettent d’exécuter des applications dans des clouds publics, privés et cloud hybride. Le développement du cloud natif est essentiel pour commercialiser rapidement des applications. Il aide les personnes, les processus et les technologies à créer, déployer et gérer des applications prêtes pour le cloud.

Le modèle d’architecture cloud natif utilise le DevOps, l’intégration continue (CI), la livraison continue (CD), les microservices et les conteneurs. La plupart des entreprises utilisent la  méthodologie des douze facteurs pour concevoir des applications cloud natives robustes et évolutives.

Dans le cloud, les applications doivent pouvoir s’exécuter simultanément sur plusieurs nœuds, partager un état de configuration/de session, avoir un mécanisme de journalisation centralisé et pouvoir être déployées à l’aide de DevOps et d’un processus CI/CD. De nombreux fournisseurs de cloud donnent des directives pour le développement cloud natif : Amazon Web Services (AWS) a son cadre des exigences bien construit, Google a différents guides sur la création d’applications cloud natives et Microsoft Azure a son guide des modèles cloud.

En général, les applications du cloud natif sont sans état. Les services communiquent entre eux à l’aide de protocoles ou de messages basés sur REST. La passerelle API, le registre des conteneurs, le middleware orienté messages (MOM : Publier/s’abonner ou Demande/Réponse), le maillage de services et les orchestrations peuvent faire partie de l’architecture de cloud natif.

L’architecture orientée événements (EDA) repose sur des systèmes découplés qui s’exécutent en réponse aux événements. Une architecture orientée événements utilise des événements pour déclencher des services découplés et communiquer entre eux. L’EDA est là depuis longtemps, mais il est maintenant plus pertinent dans le cloud.

Alors, qu’y a-t-il de nouveau ? Une utilisation appropriée permet d’augmenter considérablement l’agilité, de réduire les coûts et d’améliorer l’efficacité opérationnelle. L’EDA sans serveur distribué peut exécuter du code connu sous le nom de fonctions qui évoluent automatiquement en réponse à une API REST ou à un déclencheur d’événement.

Pour le modèle sans serveur, aucune gestion de serveur n’est nécessaire. Le modèle sans serveur est également rapidement évolutif (ce qui permet des mises à jour et un déploiement rapides) et il est sans état.

Voici quelques-uns des services cloud sans serveur actuellement disponibles auprès de différents fournisseurs :

Types de services sans serveur

• Fonctions en tant que service (FaaS) : téléchargez des éléments de fonctionnalité sur le cloud et laissez ces éléments être exécutés indépendamment.
• Backend-as-a-Service (BaaS) : utilisez les services d’un tiers, tels que la gestion des applications, la gestion des bases de données et le stockage dans le cloud.
• Mobile-Backend-as-a-Service (MBaaS) : fonctions pour les applications mobiles.

Comment faire en sorte que les applications monolithiques fonctionnent bien dans un environnement cloud ? L’architecture basée sur le cloud est mieux adaptée pour créer une application Web moderne (sites Web statiques/dynamiques), déployer une application Web, se connecter à une base de données et analyser le comportement des utilisateurs.

Une architecture d’application traditionnelle basée sur le cloud implique des équilibreurs de charge, des serveurs Web, des serveurs d’applications et des bases de données. Elle peut bénéficier des fonctionnalités du cloud telles que l’élasticité des ressources, la mise en réseau définie par logiciel, le provisionnement automatique, la haute disponibilité et l’évolutivité.

Ce type d’architecture est idéal pour les entreprises qui n’ont pas à se soucier de la maintenance d’un serveur. Les fonctions sans serveur prennent en charge différents langages de programmation, tels que PHP, Java, .NET, Node.js, Python, Ruby, Docker et Go.

API Gateway est un service important qui permet aux développeurs de créer et de publier facilement des API sécurisées. Les API serviront de porte d’entrée aux applications pour accéder aux données et à la logique commerciale. Elles s’occupent également des autorisations et du contrôle des accès. Les développeurs utilisent API Gateway pour appeler différentes fonctions sans serveur pour différents appels API.

La décision que vous prenez lors du choix d’un modèle d’architecture peut influencer la réussite ou l’échec de votre projet. Vous devez faire votre choix en fonction de votre application et des exigences non fonctionnelles. Par exemple, vous ne choisissez pas le transport par avion quand vous souhaitez parcourir quelques kilomètres.

Avant de choisir une architecture pour votre projet d’application, tenez compte des éléments suivants :

• S’agit-il d’un système monolithique ou d’un système de microservices ? (Pour des projets plus modestes avec une application simple, le monolithique peut être un bon choix).
• Votre équipe est-elle prête à utiliser des microservices ?
• Votre équipe dispose-t-elle d’un processus DevOps et CI/CD basé sur le cloud ?
• Quel est votre modèle d’hébergement ? Privé, public, hybride ?
• Quel est l’impact de l’architecture de l’application sur votre projet ?
• Une combinaison de plusieurs modèles d’architecture vous convient-elle ?
• Vos applications ont-elles besoin de persistance et de sessions ?

L’architecture des applications Web ne cesse d’évoluer pour répondre aux exigences commerciales numériques et à l’évolution de l’environnement de l’infrastructure informatique. Des technologies telles que l’intelligence artificielle, l’analytique, l’automatisation, la robotique avancée, l’edge computing, la blockchain, l’Internet des objets (IdO) et les API redéfinissent ce qui est possible dans de nombreux secteurs. La complexité croissante de l’infrastructure, des applications et de la taille des données nécessite de nouvelles approches architecturales. La plupart des entreprises adoptent une approche multicloud en faisant appel à un ou plusieurs fournisseurs de cloud. Les entreprises utilisent les services cloud en utilisant des modèles privés, publics ou hybrides avec des modèles SaaS, PaaS ou IaaS.

Auparavant, le déploiement d’applications était un processus difficile et ne pouvait pas être effectué pendant les heures ouvrables normales. Cependant, différentes méthodes de déploiement (comme le déploiement bleu-vert et le déploiement canari), ainsi que les pratiques DevOps et CI/CD (intégration continue et livraison continue), permettent désormais le déploiement à tout moment sans aucune panne d’application.

Les architectures monolithiques restent valables pour de nombreuses applications, mais la bonne architecture doit être utilisée pour votre cas d’utilisation numérique afin de gagner en agilité et de réduire les délais de mise sur le marché. Pour une application simple, envisagez de choisir une approche monolithique traditionnelle. Les modèles cloud natif ou microservices conviennent parfaitement à l’évolution des applications complexes. Il est logique d’utiliser une architecture de microservices lorsqu’on a plusieurs équipes expérimentées qui utilisent plusieurs langues et déploiements. Une comparaison entre les modèles d’application traditionnels à 3/N niveaux et les modèles d’architecture basés sur le cloud est présentée ci-dessous à titre de référence.

Pour commencer à créer, inscrivez-vous à un IBMid et créez votre compte IBM Cloud.