Architectures de backend pour les backends d'applications Web axées sur le contenu

L'architecture de backend fait référence à la structure du backend d'une application Web. L'architecture du backend détermine la manière dont les parties de l'application communiquent entre elles pour traiter les requêtes entrantes et créer des réponses. Lorsque vous créez une application Web, sélectionnez une architecture backend en fonction de vos exigences et de facteurs spécifiques, y compris le coût (en cours et à grande échelle), la complexité de votre application, les objectifs de scaling et l'expertise de votre équipe.

Pour les applications Web axées sur le contenu, telles que l'e-commerce, les journaux ou les blogs, les exigences critiques incluent la cohérence des données et les performances, en particulier si votre application se développe à l'échelle mondiale et risque d'être plus distribuée. Pour les applications Web axées sur le contenu, le stockage des données utilisé par votre application est également essentiel. Il est décrit plus en détail dans le guide sur le stockage des données. Aller au-delà des architectures d'applications classiques, héberger votre contenu et le rendre accessible est essentiel lorsque vous optimisez les performances de votre application. Consultez le guide d'hébergement pour savoir comment choisir la bonne stratégie d'hébergement et optimiser votre application.

Si vous disposez déjà d'un backend pour une application Web, tenez compte des limites de votre architecture actuelle. Par exemple, à mesure que votre application évolue à la hausse et que ses performances et sa fiabilité augmentent, déterminez si certaines parties de votre application doivent être refactorisées ou déplacées vers une architecture différente, plus adaptée à votre évolutivité accrue. Par exemple, les architectures hybrides (ou multicloud) vous permettent de transférer certaines charges de travail vers le cloud avant d'effectuer une transition complète. Il est également essentiel de prendre en compte le coût, le temps et les risques associés à une telle migration.

Architectures monolithiques

Une architecture monolithique présente une structure unifiée, où tous les composants de l'application sont étroitement intégrés dans un seul codebase. L'application entière est conçue comme une seule unité autonome. L'architecture monolithique est multicouche, dans laquelle différentes couches de l'application accomplissent des tâches spécifiques.

Couches structurelles

• L'interface utilisateur (UI), qui comprend des composants permettant de présenter les fonctionnalités de l'application, est généralement une application Web ou de bureau qui interagit avec les utilisateurs.
• C'est dans la logique de l'application que réside la fonctionnalité de base.Cette partie du codebase contient les règles, les calculs et les opérations qui définissent le fonctionnement de l'application.
• La couche d'accès aux données contient des fonctions permettant de lire et d'écrire des données, et de traduire entre les structures de données de l'application et le schéma de base de données. Cette couche est responsable de l'interaction avec la base de données ou le stockage de données de l'application.
• La base de données est l'endroit où l'application stocke ses données. Il n'existe généralement qu'une seule base de données qui stocke toutes les données de l'application, y compris les données utilisateur, les configurations et d'autres informations.
• Les composants de middleware gèrent des tâches telles que l'authentification, le routage des requêtes et la validation des données. Ces composants aident à gérer le flux de données et de requêtes.
• Certaines applications monolithiques possèdent des points d'intégration avec des API ou des services externes. Ces points permettent à l'application d'interagir avec des services tiers, des sources de données ou d'autres systèmes.

Les couches structurelles font généralement partie d'un seul codebase. Ce codebase contient l'ensemble de l'application et est généralement organisé en répertoires, en modules et en classes. Les développeurs travaillent sur différentes parties du codebase pour créer et gérer l'application. Cependant, l'ensemble de l'application est généralement déployé comme une seule unité. En cas de mise à jour ou de modification, l'ensemble de l'application est redéployé.

Difficultés potentielles

• À mesure que les applications monolithiques se développent, le codebase a tendance à devenir complexe et difficile à gérer. Cela peut entraîner de longs cycles de développement et des difficultés à comprendre l'ensemble du codebase.
• Le déploiement de modifications dans une application monolithique peut s'avérer risqué, car les modifications apportées dans une partie du code peuvent affecter par inadvertance d'autres parties de l'application. Cela peut entraîner un processus de déploiement long et sujet aux erreurs.
• Les applications monolithiques peuvent être difficiles à faire évoluer, car elles sont déployées comme une seule unité. Vous devez faire évoluer l'ensemble de l'application même si un seul composant connaît une demande accrue.
• Les applications monolithiques reposent souvent sur une seule pile technologique ou un seul langage de programmation. Votre capacité à utiliser le meilleur outil pour une tâche spécifique dans l'application peut donc être limitée.
• Même pendant les périodes de faible demande, le fonctionnement des applications monolithiques nécessite d'importantes ressources. Les coûts de maintenance augmentent également à mesure que l'application vieillisse, car il devient plus difficile de mettre à jour et de corriger l'application sans entraîner de régressions.
• Les équipes de développement travaillant sur des applications monolithiques sont souvent organisées autour de l'application entière, ce qui conduit à des équipes plus importantes et à une coordination plus complexe entre les membres.

Utilisation suggérée

Les architectures monolithiques conviennent lorsqu'une application a des exigences faibles et que l'équipe de développement est petite. À mesure que la complexité et l'échelle d'une application augmentent, ou lorsque différentes parties de l'application nécessitent des technologies ou des stratégies de déploiement différentes, les architectures monolithiques peuvent devenir moins flexibles et plus difficiles à gérer.

Vous pouvez créer et gérer des machines virtuelles pouvant exécuter des applications monolithiques sur Compute Engine. Vous bénéficiez d'un contrôle total sur les systèmes d'exploitation, les logiciels et la gestion de ces machines virtuelles permettant d'exécuter votre application monolithique.

Avec un service Platform as a Service, tel qu'App Engine, vous pouvez créer votre application et l'exécuter sur une infrastructure entièrement gérée qui évolue automatiquement en fonction des requêtes.

Si votre application monolithique est conteneurisée, vous pouvez l'exécuter à l'aide de Google Kubernetes Engine (GKE) ou de Cloud Run. Des services tels que Cloud SQL ou Cloud Spanner permettent de stocker des données d'applications monolithiques. Envisagez une combinaison de services et de systèmes en fonction des exigences spécifiques de votre application.

Architectures sans serveur

Grâce à une architecture sans serveur, vous pouvez créer et exécuter des applications sans gérer de serveurs physiques ou virtuels. Le fournisseur de services cloud gère automatiquement l'infrastructure, le scaling et l'allocation des ressources afin que les développeurs puissent se concentrer sur l'écriture du code pour leurs applications. Les architectures sans serveur peuvent simplifier le développement, réduire les coûts opérationnels et optimiser les coûts en éliminant le besoin de gérer des serveurs. Elles sont adaptées aux microservices, au traitement des données en temps réel, aux applications Web avec des charges de travail variables et au traitement d'événements.

Architectures sans serveur basées sur des événements

Les architectures sans serveur basées sur des événements sont un type spécifique d'architecture informatique sans serveur qui repose sur des événements ou des déclencheurs pour lancer l'exécution de fonctions ou de microservices. Les composants système communiquent via des événements, et les fonctions sont appelées en réponse à ces événements. Ils reposent souvent sur une communication asynchrone, car les fonctions sont déclenchées par des événements, puis les traitent indépendamment et peuvent produire des événements qui déclenchent ensuite des actions ultérieures. Ce type d'architecture sans serveur est une bonne option pour créer des systèmes évolutifs, réactifs et faiblement couplés.

Google Cloud Functions et Cloud Functions for Firebase vous permettent de créer et de déployer des fonctions basées sur des événements dans un environnement sans serveur entièrement géré. Elle vous permet d'exécuter du code en réponse à divers événements et déclencheurs, y compris des requêtes HTTP, des messages Cloud Pub/Sub, des modifications apportées à Google Cloud Storage et des mises à jour de Firebase Realtime Database, sans avoir à gérer l'infrastructure. Les fonctionnalités clés incluent la compatibilité avec plusieurs langages, l'évolutivité, la facturation précise, les intégrations tierces, la journalisation et la surveillance robustes, ainsi que l'intégration à d'autres services Google et Firebase.

Les architectures sans serveur peuvent s'avérer rentables dans de nombreux cas d'utilisation, en particulier pour les applications soumises à des charges de travail variables, à des besoins de développement rapides et à un trafic imprévisible. La fiabilité dépend du fournisseur cloud, et des contrats de niveau de service sont mis en place pour garantir des objectifs de performances et de fiabilité spécifiques. Vous devez évaluer votre cas d'utilisation et vos exigences spécifiques pour déterminer si l'architecture sans serveur est votre meilleure option.

Conteneurisation

La conteneurisation permet de empaqueter les applications et leurs dépendances dans des conteneurs portables légers. Elles fournissent un environnement d'application cohérent qui permet le développement et le déploiement sur différents systèmes et plates-formes. Certaines plates-formes sans serveur permettent d'exécuter des charges de travail conteneurisées. L'exécution de conteneurs dans un environnement sans serveur peut être utile lorsque vous avez des charges de travail complexes ou avec état qui ne peuvent pas être exprimées en tant que fonctions de base. Elle offre de la flexibilité en termes de compatibilité des langages et d'environnements d'exécution.

Cloud Run est une plate-forme informatique sans serveur qui permet aux développeurs de déployer et d'exécuter des applications conteneurisées dans un environnement entièrement géré. Il offre un moyen simple de créer, de déployer et de faire évoluer des applications sans gérer l'infrastructure sous-jacente. Elle convient à un large éventail d'applications Web et de microservices, en particulier celles dont les charges de travail sont variables, et pour lesquelles la conteneurisation offre des avantages en termes de packaging et de cohérence des applications.

Architectures de microservices

Les applications sont divisées en petites parties faiblement couplées et implémentent des fonctionnalités distinctes. Ces services peuvent communiquer via des messages asynchrones, des canaux basés sur des événements, ou directement en exposant une interface. Chaque service est développé, testé et mis à l'échelle indépendamment dans son conteneur, qui est souvent géré via un service d'orchestration, tel que Kubernetes, ou déployé à l'aide d'une plate-forme gérée comme Cloud Run.

Les déploiements de microservices tirent également parti du paradigme des applications sans serveur en ne s'appuyant pas sur un serveur centralisé.

Diviser une application en services autonomes peut simplifier un système complexe. Des limites et des objectifs bien définis peuvent accélérer le développement et améliorer la maintenance. Chaque microservice peut être développé indépendamment à l'aide des frameworks ou des outils les plus efficaces. La communication entre les services est souvent gérée à l'aide d'événements, d'une communication publication/abonnement, de pipelines de messages ou d'appels de procédure à distance tels que gRPC.

Pour l'orchestration des tâches au sein d'une architecture de microservices, envisagez d'utiliser un framework compatible avec les plates-formes ciblées, une profondeur suffisante pour les tâches et les types de workflows que vous orchestrez, ainsi que la gestion des erreurs et la télémétrie pour déboguer les problèmes. Parmi les options populaires figurent le responsable ou les offres d'un fournisseur de services cloud tel que Google Workflows.

Les applications basées sur des microservices peuvent être complexes à développer et à gérer en raison de leur nature distribuée et de la nécessité de communiquer au sein des services. Par conséquent, la gestion des déploiements, la surveillance et la journalisation sont plus complexes que les autres options d'architecture. Étant donné que la fiabilité dépend de l'architecture des services individuels, la nature distribuée peut offrir une résilience supplémentaire, en particulier si la surveillance et la télémétrie sont déployées et activées si nécessaire.

Comparaison de différentes architectures pour les backends d'applications Web axées sur le contenu

Le tableau suivant compare les architectures aux exigences clés pour le backend d'une application Web axée sur le contenu.

	Architectures monolithiques	Architectures sans serveur et basées sur des événements	Architectures de microservices sans serveur
Complexité et maintenance	Implémentation facile pour les petits projets autonomes, mais complexité croissante à grande échelle. Nécessite une maintenance et une coordination manuelles.	Le scaling est parfaitement pris en charge et intégré à la plate-forme. Le dépannage et le débogage peuvent s'avérer difficiles. Pas besoin de gérer l'infrastructure.	Des services autonomes qui sont testés et déployés indépendamment, ce qui facilite la maintenance de chaque unité. Nécessite une communication minutieuse entre les services. Nécessite des outils de gestion et d'orchestration pour une gestion à plus grande échelle.
Évolutivité et performances	Efficace à petite échelle, difficile à faire évoluer au-delà d'une taille spécifique. Besoins spécifiques en termes d'infrastructure, limitant les options de scaling dynamique Scaling manuel (ou utilisation de services manuels) dans l'architecture, par exemple via l'équilibrage de charge.	Évolutivité intégrée via l'utilisation d'une plate-forme gérée Évolue dans les deux sens :	Chaque service est adapté à un besoin spécifique, et peut être mis à l'échelle et optimisé indépendamment.
Résilience et stratégies de remplacement	Le déploiement est complexe et peut entraîner des temps d'arrêt ("tout ou rien").	inhérents au fournisseur de services cloud. Chaque fonction indépendante peut être relancée indépendamment.	Chaque service est autonome, ce qui rend le système global plus résilient grâce à des tests et un développement indépendants.
Expérience en développement	Développement rapide à petite échelle grâce à un couplage fort de l'architecture (par exemple, via des requêtes efficaces). Les compilations sont longues, et les collaborations et tests sont difficiles à mesure que la complexité grandit.	Vous n'avez aucune infrastructure à maintenir ni à gérer, ce qui accélère le développement. Les tests et le débogage d'une application en ligne dépendent des services du fournisseur de services cloud.	Les services sont autonomes et peuvent être développés indépendamment les uns des autres. De nombreux services doivent être coordonnés et gérés.
Coût	Un développement complexe peut entraîner une augmentation des coûts. Nécessite des investissements importants en matériel ou en infrastructure, en particulier à grande échelle. Les réductions des coûts associées à l'augmentation ou à la baisse du projet sont difficiles à réaliser.	Aucun coût de matériel dédié. Scaling à la hausse ou à la baisse pour optimiser l'utilisation des ressources et les coûts (jusqu'à zéro)	Aucun coût de matériel dédié. Scaling à la hausse ou à la baisse pour optimiser l'utilisation des ressources et les coûts dans les limites les coûts supplémentaires liés à la surveillance et à la gestion d'un vaste ensemble de services indépendants ;

En savoir plus sur les architectures backend pour les applications Web de contenu

Voici quelques ressources pour en savoir plus sur les architectures des applications Web basées sur le contenu, y compris sur la migration de votre application vers une autre architecture:

• Apprenez-en plus sur les architectures backend d'applications Web faiblement couplées, y compris les applications Web monolithiques et sans serveur à plusieurs niveaux.

• Migrer une application monolithique vers une architecture de microservices.

• Cas d'utilisation typiques de Cloud Functions sans serveur