Méthodologie de conception pour les charges de travail stratégiques sur Azure
La création d’une application stratégique sur n’importe quelle plateforme cloud nécessite une expertise technique et des investissements d’ingénierie importants, en particulier dans la mesure où il existe une complexité importante associée à :
- Comprendre la plateforme cloud,
- Choisir les services et la composition appropriés,
- Application de la configuration de service correcte,
- Opérationnalisation des services utilisés, et
- S’aligner en permanence sur les meilleures pratiques et les feuilles de route de service les plus récentes.
Cette méthodologie de conception vise à fournir un chemin de conception facile à suivre pour vous aider à naviguer dans cette complexité et à éclairer les décisions de conception nécessaires pour produire une architecture cible optimale.
1 — Conception pour les besoins métier
Toutes les charges de travail stratégiques n’ont pas les mêmes exigences. Attendez-vous à ce que les considérations d’examen et les recommandations en matière de conception fournies par cette méthodologie de conception donnent des décisions et des compromis différents pour différents scénarios d’application.
Sélectionner un niveau de fiabilité
La fiabilité est un concept relatif et, pour que toute charge de travail soit suffisamment fiable, elle doit refléter les exigences métier qui l’entourent. Par exemple, une charge de travail stratégique avec un objectif de niveau de service (SLO) de disponibilité de 99,999 % nécessite un niveau de fiabilité beaucoup plus élevé qu’une autre charge de travail moins critique avec un SLO de 99,9 %.
Cette méthodologie de conception applique le concept de niveaux de fiabilité exprimés en tant que SLO de disponibilité pour informer les caractéristiques de fiabilité requises. Le tableau ci-dessous capture les budgets d’erreur autorisés associés aux niveaux de fiabilité courants.
| Niveau de fiabilité (SLO de disponibilité) | Temps d’arrêt autorisé (semaine) | Temps d’arrêt autorisé (mois) | Temps d’arrêt autorisé (année) |
|---|---|---|---|
| 99,9 % | 10 minutes, 4 secondes | 43 minutes, 49 secondes | 8 heures, 45 minutes, 56 secondes |
| 99,95 % | 5 minutes, 2 secondes | 21 minutes, 54 secondes | 4 heures, 22 minutes, 58 secondes |
| 99,99 % | 1 minute | 4 minutes 22 secondes | 52 minutes, 35 secondes |
| 99, 999 % | 6 secondes | 26 secondes | 5 minutes, 15 secondes |
| 99.9999% | <1 seconde | 2 secondes | 31 secondes |
Important
Le SLO de disponibilité est considéré par cette méthodologie de conception comme étant plus qu’un simple temps de fonctionnement, mais plutôt comme un niveau de service d’application cohérent par rapport à un état d’application sain connu.
Dans un premier exercice, il est conseillé aux lecteurs de sélectionner un niveau de fiabilité cible en déterminant la durée de temps d’arrêt acceptable ? La poursuite d’un niveau de fiabilité particulier aura finalement une incidence significative sur le chemin de conception et les décisions de conception englobantes, ce qui aboutira à une architecture cible différente.
Cette image montre comment les différents niveaux de fiabilité et les exigences métier sous-jacentes influencent l’architecture cible d’une implémentation de référence conceptuelle, en particulier en ce qui concerne le nombre de déploiements régionaux et les technologies globales utilisées.
L’objectif de temps de récupération (RTO) et l’objectif de point de récupération (RPO) sont d’autres aspects critiques lors de la détermination de la fiabilité requise. Par instance, si vous vous efforcez d’obtenir un RTO d’application de moins d’une minute, les stratégies de récupération basées sur la sauvegarde ou une stratégie de déploiement actif/passif risquent d’être insuffisantes.
2 — Évaluer les zones de conception à l’aide des principes de conception
Au cœur de cette méthodologie se trouve un parcours de conception critique comprenant :
- Principes fondamentaux de conception
- Domaine de conception fondamental avec des décisions de conception fortement liées et dépendantes.
L’impact des décisions prises dans chaque domaine de conception se répercutera sur d’autres domaines de conception et décisions de conception. Passer en revue les considérations et les recommandations fournies pour mieux comprendre les conséquences des décisions prises, qui peuvent produire des compromis dans les domaines connexes de conception.
Par exemple, pour définir une architecture cible, il est essentiel de déterminer la meilleure façon de surveiller l’intégrité de l’application entre les composants clés. Nous vous recommandons vivement de passer en revue la zone de conception de la modélisation de l’intégrité, en utilisant les recommandations décrites pour vous aider à prendre des décisions.
3 — Déployer votre première application stratégique
Reportez-vous à ces architectures de référence qui décrivent les décisions de conception basées sur cette méthodologie.
Architecture de base d’une application accessible sur Internet
Architecture de base d’une application accessible sur Internet avec des contrôles réseau
Conseil
L’architecture est soutenue par l’implémentation de Mission-Critical Online qui illustre les recommandations de conception.
Artefacts de niveau production Chaque artefact technique est prêt à être utilisé dans des environnements de production avec tous les aspects opérationnels de bout en bout pris en compte.
Ancré dans des expériences réelles Toutes les décisions techniques sont guidées par les expériences des clients Azure et les leçons tirées du déploiement de ces solutions.
Alignement de la feuille de route Azure Les architectures de référence stratégiques ont leur propre feuille de route alignée sur les feuilles de route des produits Azure.
4 — Intégrer votre charge de travail dans les zones d’atterrissage Azure
Les abonnements à la zone d’atterrissage Azure fournissent une infrastructure partagée pour les déploiements d’entreprise qui nécessitent une gouvernance centralisée.
Il est essentiel d’évaluer le cas d’usage de connectivité requis par votre application stratégique. Les zones d’atterrissage Azure prennent en charge deux archétypes main séparés en différentes étendues de groupe d’administration : Online ou Corp., comme illustré dans cette image.
Abonnement en ligne
Une charge de travail stratégique fonctionne comme une solution indépendante, sans aucune connectivité réseau d’entreprise directe au reste de l’architecture de la zone d’atterrissage Azure. L’application sera davantage protégée par le biais de la gouvernance pilotée par les stratégies et s’intégrera automatiquement à la journalisation de plateforme centralisée via la stratégie.
L’architecture de base et l’implémentation stratégique en ligne s’alignent sur l’approche en ligne.
Abonnement corp.
Lorsqu’elle est déployée dans un abonnement Corp., une charge de travail stratégique dépend de la zone d’atterrissage Azure pour fournir des ressources de connectivité. Cette approche permet l’intégration à d’autres applications et services partagés. Vous devez concevoir autour de certaines ressources fondamentales, qui existeront à l’avance dans le cadre de la plateforme de service partagé. Par exemple, le tampon de déploiement régional ne doit plus englober un Réseau virtuel éphémère ou une zone Azure DNS privé, car ceux-ci existent dans l’abonnement Corp.
Pour commencer à utiliser ce cas d’usage, nous vous recommandons d’utiliser l’architecture de base dans une architecture de référence de zone d’atterrissage Azure .
Conseil
L’architecture précédente est soutenue par une implémentation connectée critique .
5 — Déployer un environnement d’application bac à sable
Parallèlement aux activités de conception, il est vivement recommandé d’établir un environnement d’application bac à sable à l’aide des implémentations de référence Mission-Critical.
Cela offre des occasions pratiques de valider les décisions de conception en répliquant l’architecture cible, ce qui permet d’évaluer rapidement l’incertitude de conception. S’ils sont appliqués correctement avec la couverture des exigences représentatives, la plupart des problèmes susceptibles d’entraver les progrès peuvent être découverts et résolus par la suite.
6 — Évoluer en permanence avec les feuilles de route Azure
Les architectures d’applications établies à l’aide de cette méthodologie de conception doivent continuer à évoluer en harmonie avec les feuilles de route de la plateforme Azure pour prendre en charge la durabilité optimisée.
Étape suivante
Passez en revue les principes de conception pour les scénarios d’application stratégiques.