Créez différents services principaux destinés à être utilisés par des applications ou interfaces frontales spécifiques. Ce modèle se révèle utile lorsque vous souhaitez personnaliser un même service principal pour plusieurs interfaces. Ce modèle a d’abord été décrit par Sam Newman.
Contexte et problème
À l’origine, une application peut être destinée à une interface utilisateur web de bureau. Un service principal est généralement développé en parallèle et fournit les fonctionnalités requises par cette interface utilisateur. À mesure que la base d’utilisateurs de l’application augmente, une application mobile est développée et doit interagir avec le même service principal. Le service principal devient un service principal à usage général, répondant aussi bien aux exigences des interfaces de bureau qu’à celles des interfaces mobiles.
Toutefois, les fonctionnalités d’un appareil mobile diffèrent sensiblement de celles d’un navigateur de bureau en termes de taille d’écran, de performances et de limitations d’affichage. Par conséquent, les impératifs d’un service principal d’application mobile sont distincts de ceux d’une interface utilisateur web de bureau.
Le service principal doit donc satisfaire à des exigences contradictoires. Le service principal nécessite des modifications régulières et significatives pour desservir à la fois l’interface utilisateur web de bureau et l’application mobile. Étant donné que des équipes d’interface distinctes travaillent souvent sur chaque frontal, le service principal devient un goulot d’étranglement dans le processus de développement. Les exigences de mise à jour conflictuelles et l’obligation de maintenir le service opérationnel pour les deux frontaux peuvent nécessiter un travail considérable sur une seule ressource déployable.
L’activité de développement étant axée sur le service principal, il est possible qu’une équipe distincte soit créée pour gérer et mettre à jour le service principal. Les équipes de développement d’interface se retrouvent alors déconnectées de l’équipe de service principal, contraignant ainsi cette dernière à trouver un équilibre entre les exigences contradictoires des différentes équipes d’interface utilisateur. Lorsqu’une équipe d’interface requiert l’apport de modifications au service principal, ces modifications doivent être validées auprès des autres équipes d’interface avant de pouvoir être intégrées au service principal.
Solution
Créez un service principal par interface utilisateur. Ajustez le comportement et les performances de chaque back-end afin qu’ils répondent au mieux aux besoins de l’environnement front-end, sans vous soucier d’affecter d’autres expériences front-ends.
Étant donné que chaque service principal est propre à une interface, il peut être optimisé pour cette dernière. Par conséquent, il sera moins volumineux, moins complexe et probablement plus rapide qu’un service principal générique qui tente de répondre aux exigences de toutes les interfaces. Chaque équipe d’interface a la possibilité de contrôler son propre service principal et ne dépend pas d’une équipe de développement de service principal centralisée. L’équipe d’interface dispose ainsi d’une réelle flexibilité en matière de sélection de langue, de cadence de mise en production, de hiérarchisation des charges de travail et d’intégration de fonctionnalités à son service principal.
Pour plus d’informations, consultez Pattern: Backends For Frontends (Modèle : Services principaux destinés aux frontaux).
Problèmes et considérations
- Considérez le nombre de services principaux à déployer.
- Si différentes interfaces (telles que des clients mobiles) doivent exécuter les mêmes requêtes, déterminez s’il est nécessaire d’implémenter un service principal pour chaque interface, ou si un seul service principal suffit.
- L’implémentation de ce modèle implique le plus souvent une duplication de code entre les services.
- Les services principaux axés sur un frontal doivent uniquement contenir la logique et le comportement propres au client. La logique métier générale et les autres fonctionnalités globales doivent être gérées à un autre emplacement de votre application.
- Pensez à la façon dont ce modèle peut se refléter dans les responsabilités d’une équipe de développement.
- Prenez en compte le temps que prendra l’implémentation de ce modèle. La tâche de création d’autres services principaux occasionnera-t-elle une dette technique, pendant que vous continuerez à prendre en charge le service principal générique existant ?
Quand utiliser ce modèle
Utilisez ce modèle dans les situations suivantes :
- Un service principal partagé ou à usage général doit être entretenu avec des coûts de développement substantiels.
- Vous devez optimiser le service principal pour les exigences d’interfaces clientes spécifiques.
- Des personnalisations sont appliquées à un service principal à usage général pour prendre en charge plusieurs interfaces.
- Un langage de programmation est mieux adapté au serveur principal d’une interface utilisateur spécifique, mais pas à toutes les interfaces utilisateur.
Ce modèle peut ne pas convenir :
- Les interfaces envoient des requêtes identiques ou similaires au service principal.
- Une seule interface est utilisée pour interagir avec le service principal.
Conception de la charge de travail
Un architecte doit évaluer la façon dont le modèle back-ends pour front-ends peut être utilisé dans la conception de leurs charges de travail pour se conformer aux objectifs et principes abordés dans les piliers d’Azure Well-Architected Framework. Par exemple :
| Pilier | Comment ce modèle soutient les objectifs des piliers. |
|---|---|
| Les décisions relatives à la fiabilité contribuent à rendre votre charge de travail résiliente aux dysfonctionnements et à s’assurer qu’elle retrouve un état de fonctionnement optimal après une défaillance. | Le fait de disposer de services séparés exclusifs à une interface de front-end spécifique permet d’éviter les dysfonctionnements, de sorte que la disponibilité d’un client n’affecte pas la disponibilité de l’accès d’un autre client. En outre, en traitant différents clients différemment, il est possible de hiérarchiser les efforts de fiabilité en fonction des modèles d’accès clients prévus. - RE :02 Flux critiques - RE :07 Auto-conservation |
| Les décisions relatives à la conception de la sécurité permettent de garantir la confidentialité, l’intégrité et la disponibilité des données et des systèmes de votre charge de travail. | En raison de la séparation des services introduite dans ce modèle, la sécurité et l’autorisation dans la couche de service qui prend en charge un client peuvent être adaptées à la fonctionnalité requise par ce dernier, ce qui peut réduire la surface d’une API et le mouvement latéral entre différents back-ends susceptibles d’exposer des capacités différentes. - SE :04 Segmentation - SE :08 Ressources de renforcement |
| L’efficacité des performances permet à votre charge de travail de répondre efficacement aux demandes grâce à des optimisations de la mise à l’échelle, des données, du code. | La séparation du backend permet une optimisation qui ne serait pas possible avec une couche de services partagés. Lorsque vous traitez chaque client différemment, vous pouvez optimiser les performances en fonction des contraintes et des fonctionnalités propres à chaque client. - PE :02 Planification de la capacité - PE :09 Flux critiques |
Comme pour toute autre décision de conception, il convient de prendre en compte les compromis par rapport aux objectifs des autres piliers qui pourraient être introduits avec ce modèle.
Étapes suivantes
Ressources associées
- Gateway Aggregation pattern (Modèle d’agrégation de passerelle)
- Modèle de déchargement de passerelle
- Modèle de routage de passerelle