Considérations relatives à la conception d’applications hybrides

Microsoft Azure est le seul cloud hybride cohérent. Il vous permet de réutiliser vos investissements de développement et permet aux applications qui peuvent s’étendre sur Azure global, les clouds Azure souverains et Azure Stack, qui est une extension d’Azure dans votre centre de données. Les applications qui s’étendent sur les clouds sont également appelées applications hybrides .

Le Guide d’architecture des applications Azure décrit une approche structurée pour la conception d’applications évolutives, résilientes et hautement disponibles. Les considérations décrites dans le Guide d’architecture des applications Azure s’appliquent également aux applications conçues pour un cloud unique et pour les applications qui s’étendent sur les clouds.

Cet article augmente les piliers de la qualité des logiciels abordés dans le guide d’architectureapplication Azure , se concentrer spécifiquement sur la conception d’applications hybrides. En outre, nous ajoutons un placement pilier, car les applications hybrides ne sont pas exclusives à un cloud ou à un centre de données local.

Les scénarios hybrides varient considérablement avec les ressources disponibles pour le développement, et couvrent des considérations telles que la géographie, la sécurité, l’accès à Internet et d’autres considérations. Bien que ce guide ne puisse pas énumérer vos considérations spécifiques, il peut fournir des instructions clés et des meilleures pratiques à suivre. La conception, la configuration, le déploiement et la maintenance d’une architecture d’application hybride impliquent de nombreuses considérations de conception qui peuvent ne pas être connues par nature.

Ce document vise à agréger les questions possibles qui peuvent survenir lors de l’implémentation d’applications hybrides et fournit des considérations (ces piliers) et des meilleures pratiques pour les utiliser. En répondant à ces questions pendant la phase de conception, vous éviterez les problèmes qu’ils pourraient provoquer en production.

Il s’agit essentiellement de questions à prendre en compte avant de créer une application hybride. Pour commencer, vous devez effectuer les opérations suivantes :

  • Identifiez et évaluez les composants de l’application.
  • Évaluez les composants d’application par rapport aux piliers.

Évaluer les composants de l’application

Chaque composant d’une application a son propre rôle spécifique dans l’application plus grande et doit être examiné avec toutes les considérations de conception. Les exigences et fonctionnalités de chaque composant doivent être mappées à ces considérations pour vous aider à déterminer l’architecture de l’application.

Décomposez votre application en ses composants en étudiant l’architecture de votre application et en déterminant ce dont elle se compose. Les composants peuvent également inclure d’autres applications avec lesquelles votre application interagit. Lorsque vous identifiez les composants, évaluez vos opérations hybrides prévues en fonction de leurs caractéristiques en posant ces questions :

  • Quel est l’objectif du composant ?
  • Quelles sont les interdépendances entre les composants ?

Par exemple, une application peut avoir un serveur frontal et un serveur principal définis comme deux composants. Dans un scénario hybride, le serveur frontal se trouve dans un cloud et le back-end se trouve dans l’autre. L’application fournit des canaux de communication entre le serveur frontal et l’utilisateur, ainsi qu’entre le serveur frontal et le serveur principal.

Un composant d’application est défini par de nombreux formulaires et scénarios. La tâche la plus importante consiste à les identifier et à leur emplacement cloud ou local.

Les composants d’application courants à inclure dans votre inventaire sont répertoriés dans le tableau 1.

Tableau 1. Composants d’application courants

composant aide sur les applications hybrides
Connexions clientes Votre application (sur n’importe quel appareil) peut accéder aux utilisateurs de différentes façons, à partir d’un point d’entrée unique, notamment les méthodes suivantes :
- Modèle client-serveur qui exige que l’utilisateur dispose d’un client installé pour fonctionner avec l’application. Application basée sur un serveur accessible à partir d’un navigateur.
- Les connexions clientes peuvent inclure des notifications lorsque la connexion est interrompue ou des alertes lorsque les frais d’itinérance peuvent s’appliquer.
Authentification L’authentification peut être requise pour un utilisateur se connectant à l’application ou à partir d’un composant se connectant à un autre.
Apis Vous pouvez fournir aux développeurs un accès programmatique à votre application avec des ensembles d’API et des bibliothèques de classes et fournir une interface de connexion basée sur des normes Internet. Vous pouvez également utiliser des API pour décomposer une application en unités logiques d’exploitation indépendantes.
Services Vous pouvez utiliser des services succincts pour fournir les fonctionnalités d’une application. Un service peut être le moteur sur lequel l’application s’exécute.
Files Vous pouvez utiliser des files d’attente pour organiser l’état des cycles de vie et des états des composants de votre application. Ces files d’attente peuvent fournir des fonctionnalités de messagerie, de notifications et de mise en mémoire tampon aux parties abonnées.
Stockage de données Une application peut être sans état ou avec état. Les applications avec état ont besoin d’un stockage de données qui peut être rempli par de nombreux formats et volumes.
Mise en cache des données Un composant de mise en cache des données dans votre conception peut traiter de manière stratégique les problèmes de latence et jouer un rôle dans le déclenchement d’un bursting cloud.
Ingestion des données Les données peuvent être envoyées à une application de plusieurs façons, allant des valeurs soumises par l’utilisateur dans un formulaire web à un flux de données en volume élevé en continu.
Traitement des données Vos tâches de traitement des données (telles que les rapports, l’analytique, les exportations de lots et la transformation de données) peuvent être traitées à la source ou déchargées sur un composant distinct à l’aide d’une copie des données.

Évaluer les composants d’application pour les piliers

Pour chaque composant, évaluez ses caractéristiques pour chaque pilier. Lorsque vous évaluez chaque composant avec tous les piliers, les questions que vous n’avez peut-être pas prises en compte peuvent devenir connues de vous qui affectent la conception de l’application hybride. Agir sur ces considérations peut ajouter de la valeur dans l’optimisation de votre application. Le tableau 2 fournit une description de chaque pilier en ce qui concerne les applications hybrides.

Tableau 2. Piliers

pilier Description
Placement Positionnement stratégique des composants dans les applications hybrides.
Scalabilité Capacité d’un système à gérer une charge accrue.
Disponibilité Proportion de temps pendant laquelle une application hybride fonctionne et fonctionne.
Résilience Capacité d’une application hybride à récupérer.
Gérabilité Processus d’opérations qui maintiennent un système en cours d’exécution en production.
Sécurité Protection des applications hybrides et des données contre les menaces.

Placement

Une application hybride a intrinsèquement une considération de placement, comme pour le centre de données.

Le positionnement est la tâche importante de positionnement des composants afin qu’ils puissent mieux traiter une application hybride. Par définition, les applications hybrides s’étendent sur des emplacements, tels que des emplacements locaux vers le cloud et entre différents clouds. Vous pouvez placer des composants de l’application sur des clouds de deux façons :

  • applications hybrides verticales
    Les composants d’application sont répartis entre les emplacements. Chaque composant individuel peut avoir plusieurs instances situées uniquement à un seul emplacement.

  • applications hybrides horizontales
    Les composants d’application sont répartis entre les emplacements. Chaque composant individuel peut avoir plusieurs instances couvrant plusieurs emplacements.

    Certains composants peuvent être conscients de leur emplacement, tandis que d’autres n’ont aucune connaissance de leur emplacement et de leur emplacement. Cette vertuosité peut être obtenue avec une couche d’abstraction. Cette couche, avec une infrastructure d’application moderne comme les microservices, peut définir la façon dont l’application est mise en service par le placement des composants d’application fonctionnant sur des nœuds sur des clouds.

Liste de contrôle de placement

Vérifiez les emplacements requis. Assurez-vous que l’application ou l’un de ses composants sont nécessaires pour fonctionner ou exiger une certification pour un cloud spécifique. Cela peut inclure des exigences de souveraineté de votre entreprise ou dictées par la loi. Déterminez également si des opérations locales sont requises pour un emplacement ou des paramètres régionaux particuliers.

Vérifiez les dépendances de connectivité. Les emplacements requis et d’autres facteurs peuvent dicter les dépendances de connectivité entre vos composants. Lorsque vous placez les composants, déterminez la connectivité et la sécurité optimales pour la communication entre eux. Les choix incluent VPN,ExpressRoute, et connexions hybrides.

Évaluer les fonctionnalités de la plateforme. Pour chaque composant d’application, vérifiez si le fournisseur de ressources requis pour le composant d’application est disponible sur le cloud et si la bande passante peut prendre en charge les exigences attendues en matière de débit et de latence.

Planifier la portabilité. Utilisez des infrastructures d’application modernes, telles que des conteneurs ou des microservices, pour planifier le déplacement des opérations et empêcher les dépendances de service.

Déterminez les exigences de souveraineté des données. Les applications hybrides sont conçues pour adapter l’isolation des données, par exemple sur un centre de données local. Passez en revue le placement de vos ressources pour optimiser le succès pour répondre à cette exigence.

Planifiez la latence. Les opérations interclouds peuvent introduire une distance physique entre les composants de l’application. Déterminez les exigences pour prendre en charge toute latence.

Contrôler les flux de trafic. Gérez les pics d’utilisation et les communications appropriées et sécurisées pour les données d’informations d’identification personnelles lorsqu’elles sont accessibles par le serveur frontal dans un cloud public.

Scalabilité

L’extensibilité est la capacité d’un système à gérer une charge accrue sur une application, qui peut varier au fil du temps, car d’autres facteurs et forces affectent la taille de l’audience, en plus de la taille et de l’étendue de l’application.

Pour la discussion principale de ce pilier, consultez scalabilité dans les cinq piliers de l’excellence de l’architecture.

Une approche de mise à l’échelle horizontale pour les applications hybrides permet d’ajouter davantage d’instances pour répondre à la demande, puis de les désactiver pendant des périodes plus silencieuses.

Dans les scénarios hybrides, le scale-out des composants individuels nécessite une considération supplémentaire lorsque les composants sont répartis entre les clouds. La mise à l’échelle d’une partie de l’application peut nécessiter la mise à l’échelle d’une autre. Par exemple, si le nombre de connexions clientes augmente, mais que les services web de l’application ne sont pas correctement mis à l’échelle, la charge sur la base de données peut saturer l’application.

Certains composants d’application peuvent effectuer un scale-out linéaire, tandis que d’autres ont des dépendances de mise à l’échelle et peuvent être limités à quelle mesure ils sont en mesure de mettre à l’échelle. Par exemple, un tunnel VPN fournissant une connectivité hybride pour les emplacements des composants d’application a une limite à la bande passante et à la latence vers laquelle il peut être mis à l’échelle. Comment les composants de l’application sont-ils mis à l’échelle pour s’assurer que ces exigences sont remplies ?

Liste de contrôle de scalabilité

Déterminer les seuils de mise à l’échelle. Pour gérer les différentes dépendances de votre application, déterminez l’étendue dans laquelle les composants d’application dans différents clouds peuvent être mis à l’échelle indépendamment les uns des autres, tout en répondant aux exigences d’exécution de l’application. Les applications hybrides doivent souvent mettre à l’échelle des zones particulières de l’application pour gérer une fonctionnalité qui interagit et affecte le reste de l’application. Par exemple, le dépassement d’un certain nombre d’instances frontales peut nécessiter la mise à l’échelle du serveur principal.

Définissez des planifications de mise à l’échelle. La plupart des applications ont des périodes occupées. Vous devez donc agréger leurs heures de pointe dans des planifications pour coordonner la mise à l’échelle optimale.

Utilisez un système de surveillance centralisé. Les fonctionnalités de supervision de plateforme peuvent fournir une mise à l’échelle automatique, mais les applications hybrides ont besoin d’un système de surveillance centralisé qui agrège l’intégrité et la charge du système. Un système de surveillance centralisé peut lancer la mise à l’échelle d’une ressource dans un emplacement et une mise à l’échelle en fonction de la ressource dans un autre emplacement. En outre, un système de supervision central peut suivre les clouds qui scalent automatiquement les ressources et les clouds qui ne le font pas.

Tirez parti des fonctionnalités de mise à l’échelle automatique (comme disponible). Si les fonctionnalités de mise à l’échelle automatique font partie de votre architecture, vous implémentez la mise à l’échelle automatique en définissant des seuils qui définissent lorsqu’un composant d’application doit être mis à l’échelle vers le haut, l’out, le bas ou le bas. Un exemple de mise à l’échelle automatique est une connexion cliente qui est mise à l’échelle automatique dans un cloud pour gérer une capacité accrue, mais entraîne la mise à l’échelle d’autres dépendances de l’application, réparties dans différents clouds, à mettre également à l’échelle. Les fonctionnalités de mise à l’échelle automatique de ces composants dépendants doivent être vérifiées.

Si la mise à l’échelle automatique n’est pas disponible, envisagez d’implémenter des scripts et d’autres ressources pour prendre en charge la mise à l’échelle manuelle, déclenchée par des seuils dans le système de surveillance centralisé.

Déterminez la charge attendue par emplacement. Les applications hybrides qui gèrent les demandes clientes peuvent principalement s’appuyer sur un emplacement unique. Lorsque la charge des requêtes clientes dépasse un seuil, des ressources supplémentaires peuvent être ajoutées à un autre emplacement pour distribuer la charge des requêtes entrantes. Assurez-vous que les connexions clientes peuvent gérer les charges accrues et déterminer également les procédures automatisées pour les connexions clientes afin de gérer la charge.

Disponibilité

La disponibilité est le temps pendant lequel un système fonctionne et fonctionne. La disponibilité est mesurée sous la forme d’un pourcentage de temps d’activité. Les erreurs d’application, les problèmes d’infrastructure et la charge système peuvent toutes réduire la disponibilité.

Pour la discussion principale de ce pilier, consultez disponibilité dans les cinq piliers de l’excellence de l’architecture.

Liste de contrôle de disponibilité

Fournir une redondance pour la connectivité. Les applications hybrides nécessitent une connectivité entre les clouds sur lesquels l’application est répartie. Vous avez un choix de technologies pour la connectivité hybride. Par conséquent, en plus de votre choix technologique principal, utilisez une autre technologie pour fournir une redondance avec les fonctionnalités de basculement automatisé si la technologie principale échoue.

Classifiez les domaines d’erreur. Les applications tolérantes aux pannes nécessitent plusieurs domaines d’erreur. Les domaines d’erreur permettent d’isoler le point de défaillance, par exemple si un disque dur unique échoue localement, si un commutateur de haut de rack tombe en panne ou si le centre de données complet n’est pas disponible. Dans une application hybride, un emplacement peut être classé comme un domaine d’erreur. Avec des exigences de disponibilité accrues, plus vous devez évaluer la façon dont un domaine d’erreur unique doit être classé.

Classifiez les domaines de mise à niveau. Les domaines de mise à niveau sont utilisés pour s’assurer que les instances des composants d’application sont disponibles, tandis que d’autres instances du même composant sont en cours de service avec des mises à jour ou des mises à niveau de fonctionnalités. Comme pour les domaines d’erreur, les domaines de mise à niveau peuvent être classés par leur positionnement entre les emplacements. Vous devez déterminer si un composant d’application peut prendre en charge la mise à niveau dans un emplacement avant sa mise à niveau dans un autre emplacement ou si d’autres configurations de domaine sont requises. Un emplacement unique peut avoir plusieurs domaines de mise à niveau.

Suivez les instances et la disponibilité. Les composants d’application hautement disponibles peuvent être disponibles via l’équilibrage de charge et la réplication synchrone des données. Vous devez déterminer le nombre d’instances pouvant être hors connexion avant l’interruption du service.

Implémentez l’auto-guérison. En cas d’interruption de la disponibilité de l’application, une détection par un système de surveillance peut initier des activités de réparation automatique à l’application, telles que le drainage de l’instance ayant échoué et son redéploiement. Cela nécessite probablement une solution de supervision centralisée, intégrée à un pipeline d’intégration continue hybride et de livraison continue (CI/CD). L’application est intégrée à un système de surveillance pour identifier les problèmes susceptibles de nécessiter un redéploiement d’un composant d’application. Le système de surveillance peut également déclencher un déploiement CI/CD hybride pour redéployer le composant d’application et potentiellement tout autre composant dépendant dans le même emplacement ou dans d’autres emplacements.

Maintenir des contrats de niveau de service (SLA). La disponibilité est essentielle pour tous les contrats pour maintenir la connectivité aux services et applications que vous avez avec vos clients. Chaque emplacement sur lequel votre application hybride s’appuie peut avoir son propre contrat SLA. Ces différents contrats SLA peuvent affecter le contrat SLA global de votre application hybride.

Résilience

La résilience est la capacité d’une application et d’un système hybrides à récupérer des défaillances et à continuer à fonctionner. L’objectif de résilience est de renvoyer l’application à un état entièrement opérationnel après une défaillance. Les stratégies de résilience incluent des solutions telles que la sauvegarde, la réplication et la récupération d’urgence.

Pour la discussion principale de ce pilier, consultez résilience dans les cinq piliers de l’excellence de l’architecture.

Liste de contrôle de résilience

Découvrez les dépendances de récupération d’urgence. La récupération d’urgence dans un cloud peut nécessiter des modifications apportées aux composants d’application dans un autre cloud. Si un ou plusieurs composants d’un cloud sont basculés vers un autre emplacement, dans le même cloud ou vers un autre cloud, les composants dépendants doivent être informés de ces modifications. Cela inclut également les dépendances de connectivité. La résilience nécessite un plan de récupération d’application entièrement testé pour chaque cloud.

Établissez un flux de récupération. Une conception efficace du flux de récupération a évalué les composants d’application pour leur capacité à prendre en charge les mémoires tampons, les nouvelles tentatives, le transfert de données ayant échoué et, si nécessaire, revenir à un autre service ou flux de travail. Vous devez déterminer quel mécanisme de sauvegarde utiliser, la procédure de restauration implique et la fréquence à laquelle elle est testée. Vous devez également déterminer la fréquence des sauvegardes incrémentielles et complètes.

Testez les récupérations partielles. Une récupération partielle pour une partie de l’application peut fournir une réassurance aux utilisateurs qui ne sont pas disponibles. Cette partie du plan doit s’assurer qu’une restauration partielle n’a pas d’effets secondaires, tels qu’un service de sauvegarde et de restauration qui interagit avec l’application pour l’arrêter correctement avant la sauvegarde.

Déterminez les initiateurs de récupération d’urgence et attribuez la responsabilité. Un plan de récupération doit décrire qui, et quels rôles, peuvent lancer des actions de sauvegarde et de récupération en plus de ce qui peut être sauvegardé et restauré.

Comparez les seuils de réparation automatique avec la récupération d’urgence. Déterminez les fonctionnalités d’auto-guérison d’une application pour l’initiation automatique de récupération et le temps nécessaire à l’auto-guérison d’une application pour être considéré comme un échec ou une réussite. Déterminez les seuils pour chaque cloud.

Vérifiez la disponibilité des fonctionnalités de résilience. Déterminez la disponibilité des fonctionnalités et des fonctionnalités de résilience pour chaque emplacement. Si un emplacement ne fournit pas les fonctionnalités requises, envisagez d’intégrer cet emplacement dans un service centralisé qui fournit les fonctionnalités de résilience.

Déterminez les temps d’arrêt. Déterminez le temps d’arrêt attendu en raison de la maintenance de l’application dans son ensemble et en tant que composants d’application.

Documentez les procédures de résolution des problèmes. Définissez des procédures de résolution des problèmes pour le redéploiement des ressources et des composants d’application.

Gérabilité

Les considérations relatives à la façon dont vous gérez vos applications hybrides sont essentielles dans la conception de votre architecture. Une application hybride bien gérée fournit une infrastructure en tant que code qui permet l’intégration de code d’application cohérent dans un pipeline de développement commun. En implémentant des tests cohérents à l’échelle du système et individuels des modifications apportées à l’infrastructure, vous pouvez garantir un déploiement intégré si les modifications réussissent les tests, ce qui leur permet d’être fusionnées dans le code source.

Pour la discussion principale de ce pilier, consultez DevOps dans les cinq piliers de l’excellence de l’architecture.

Liste de contrôle de la facilité de gestion

Implémenter la surveillance. Utilisez un système de surveillance centralisé des composants d’application répartis entre les clouds pour fournir une vue agrégée de leur intégrité et de leurs performances. Ce système inclut la surveillance des composants de l’application et des fonctionnalités de plateforme associées.

Déterminez les parties de l’application qui nécessitent une surveillance.

Coordonner les stratégies. Chaque emplacement qu’une application hybride s’étend peut avoir sa propre stratégie qui couvre les types de ressources autorisés, les conventions d’affectation de noms, les balises et d’autres critères.

Définissez et utilisez des rôles. En tant qu’administrateur de base de données, vous devez déterminer les autorisations requises pour différents personnages (comme un propriétaire d’application, un administrateur de base de données et un utilisateur final) qui doivent accéder aux ressources de l’application. Ces autorisations doivent être configurées sur les ressources et à l’intérieur de l’application. Un système de contrôle d’accès en fonction du rôle (RBAC) vous permet de définir ces autorisations sur les ressources de l’application. Ces droits d’accès sont difficiles lorsque toutes les ressources sont déployées dans un seul cloud, mais nécessitent encore plus d’attention lorsque les ressources sont réparties entre les clouds. Les autorisations sur les ressources définies dans un cloud ne s’appliquent pas aux ressources définies dans un autre cloud.

Utilisez des pipelines CI/CD. Un pipeline d’intégration continue et de développement continu (CI/CD) peut fournir un processus cohérent pour la création et le déploiement d’applications qui s’étendent sur les clouds, et fournir une assurance qualité pour leur infrastructure et leur application. Ce pipeline permet à l’infrastructure et à l’application d’être testée sur un cloud et déployée sur un autre cloud. Le pipeline vous permet même de déployer certains composants de votre application hybride sur un cloud et d’autres composants vers un autre cloud, formant essentiellement la base du déploiement d’applications hybrides. Un système CI/CD est essentiel pour gérer les composants d’application de dépendances entre eux pendant l’installation, comme l’application web nécessitant une chaîne de connexion à la base de données.

Gérez le cycle de vie. Étant donné que les ressources d’une application hybride peuvent s’étendre sur des emplacements, la fonctionnalité de gestion du cycle de vie de chaque emplacement doit être agrégée en une seule unité de gestion du cycle de vie. Réfléchissez à la façon dont ils sont créés, mis à jour et supprimés.

Examinez les stratégies de résolution des problèmes. La résolution des problèmes d’une application hybride implique plus de composants d’application que la même application qui s’exécute dans un seul cloud. Outre la connectivité entre les clouds, l’application s’exécute sur deux plateformes au lieu d’une. Une tâche importante dans la résolution des problèmes d’applications hybrides consiste à examiner l’intégrité agrégée et la surveillance des performances des composants d’application.

Sécurité

La sécurité est l’un des principaux éléments à prendre en compte pour n’importe quelle application cloud et devient encore plus critique pour les applications cloud hybrides.

Pour la discussion principale de ce pilier, consultez sécurité dans les cinq piliers de l’excellence de l’architecture.

Liste de contrôle de sécurité

Supposez une violation. Si une partie de l’application est compromise, assurez-vous qu’il existe des solutions en place pour réduire la propagation de la violation, non seulement au sein du même emplacement, mais également entre les emplacements.

Surveillez l’accès réseau autorisé. Déterminez les stratégies d’accès réseau pour l’application, telles que l’accès uniquement à l’application à partir d’un sous-réseau spécifique et autorisez uniquement les ports et protocoles minimaux entre les composants requis pour que l’application fonctionne correctement.

Utilisez une authentification robuste. Un schéma d’authentification robuste est essentiel pour la sécurité de votre application. Envisagez d’utiliser un fournisseur d’identité fédéré qui fournit des fonctionnalités d’authentification unique et utilise un ou plusieurs des schémas suivants : authentification par nom d’utilisateur et mot de passe, clés publiques et privées, authentification à deux facteurs ou multifacteur et groupes de sécurité approuvés. Déterminez les ressources appropriées pour stocker des données sensibles et d’autres secrets pour l’authentification d’application en plus des types de certificats et de leurs exigences.

Utilisez le chiffrement. Identifiez les zones de l’application qui utilisent le chiffrement, par exemple pour le stockage de données ou la communication cliente et l’accès.

Utilisez des canaux sécurisés. Un canal sécurisé entre les clouds est essentiel pour fournir des vérifications de sécurité et d’authentification, une protection en temps réel, une mise en quarantaine et d’autres services dans les clouds.

Définissez et utilisez des rôles. Implémentez des rôles pour les configurations de ressources et l’accès à une identité unique entre les clouds. Déterminez les exigences en matière de contrôle d’accès en fonction du rôle (RBAC) pour l’application et ses ressources de plateforme.

Auditez votre système. La surveillance du système peut journaliser et agréger des données à partir des composants de l’application et des opérations de plateforme cloud associées.

Résumé

Cet article fournit une liste de contrôle des éléments importants à prendre en compte lors de la création et de la conception de vos applications hybrides. L’examen de ces piliers avant de déployer votre application vous empêche de passer en revue ces questions dans les pannes de production et de vous obliger à revoir votre conception.

Il peut sembler une tâche fastidieuse au préalable, mais vous obtenez facilement votre retour sur investissement si vous concevez votre application en fonction de ces piliers.

Étapes suivantes

Pour plus d’informations, consultez les ressources suivantes :