Scénario 1 - Concevoir une mise à l’échelle mondiale et un accès sécurisé
Dans les deux unités suivantes, vous allez passer en revue deux scénarios métier. Les descriptions de l’entreprise, les objectifs du projet et les contraintes ont déjà été identifiés pour vous. Vous pouvez travailler sur cette solution vous-même, mais il peut être intéressant d’effectuer un brainstorming avec d’autres personnes si c’est possible.
Processus de développement de solutions
Dans ces scénarios et probablement dans la réalité, votre objectif est de comprendre :
- Le problème que l’entreprise doit résoudre.
- Toutes les exigences et contraintes associées à une solution.
Cet objectif se présente souvent sous la forme d’une formulation du problème. Il s’agit d’un ensemble formel de paragraphes qui définissent clairement les circonstances, la condition présente et les résultats souhaités pour une solution. À ce stade, vous voulez éviter d’explorer la façon de résoudre le problème et plutôt vous concentrer sur ce que vous voulez résoudre.
Une fois que vous (et probablement votre équipe et les parties prenantes) avez convenu d’un énoncé du problème, vous devez extraire autant de spécifications (objectifs) pour le projet que vous pouvez en trouver. Posez ensuite les contraintes de la solution.
À ce stade, il est acceptable d’avoir des contraintes irréalistes. Par la suite, vous pourrez les réviser après avoir défini un ratio coût/avantage pour chaque spécification et chaque contrainte.
En production, il y a normalement six phases pour créer une solution. Le développement de l’énoncé du problème n’est que le début.
- Découverte : L’énoncé initial du problème formulé par le client.
- Vision : Une description « idéale » de ce que serait la réussite du projet. Elle est souvent formulée sous la forme d’énoncés « Je peux... ».
- Session de conception de l’architecture : Une identification initiale des options et des choix technologiques pour une solution préliminaire.
- Preuve de concept (POC) : Une fois que les technologies et processus optimaux de la solution sont sélectionnés, une preuve de concept est définie avec un petit exemple représentatif de ce à quoi pourrait ressembler une solution. Si une solution actuellement fonctionnelle dans un exemple parallèle est disponible, elle peut être utilisée.
- Implémentation : Implémentation d’un déploiement échelonné de la solution complète sur la base des résultats des phases précédentes.
- Remise : Examen post-mortem du projet avec une discussion concernant les améliorations futures.
Tout au long de ce module, vous pouvez tirer parti de modèles de projet et des icônes les plus récentes. Vous pouvez également utiliser ces ressources dans vos charges de travail de production.
Pour les scénarios de ce module, vous allez consacrer du temps à déterminer l’état du problème (découverte). Mais l’élément principal considéré sera la session de conception de l’architecture. Si vous voulez développer une solution à l’issue du module, vous pouvez pour cela utiliser les ressources du module.
Détails du scénario
Votre client est un fournisseur de services et de distribution de contenu qui opère dans le monde entier. Il vous a demandé de concevoir un système capable de gérer des milliers d’écritures par seconde sur ce qui est essentiellement un mini-Data Warehouse opérationnel.
Le client a également besoin de pouvoir effectuer de l’analytique en temps réel sur les données, afin de déterminer les tendances et d’identifier les anomalies. Il fait actuellement cela utilisé avec des applications CLR (Common Language Runtime). Le client ne recherche pas un entrepôt de données ni à utiliser de grandes portions de la surface d’exposition SQL, mais il doit pouvoir effectuer une mise à l’échelle en fonction de là où se trouvent les utilisateurs.
Le client tente également de déterminer les méthodes d’authentification à utiliser dans son environnement hybride. La solution et l’application principales résideront dans Azure, mais elles devront également pouvoir gérer ce qui suit :
- Une application sur une machine non-Azure jointe à un domaine.
- Une application plus ancienne qui ne permettra pas le changement du pilote ou de la chaîne de connexion sur une machine non-Azure
- Plusieurs utilisateurs qui exécutent des rapports à partir des outils d’administration SQL (SQL Server Management Studio, Azure Data Studio, PowerShell) sur des machines non-Azure non jointes à un domaine.
Dans la mesure du possible, le client souhaite éliminer les mots de passe ou les secrets codés en dur dans les chaînes de connexion et les fichiers de configuration des applications. Il veut aussi éliminer l’utilisation des mots de passe dans les outils SQL ou trouver un moyen d’améliorer cette authentification.
Guide pour le scénario
- Commencez avec l’option de déploiement Azure SQL qui est la plus compatible avec la solution actuelle du client et qui est disponible maintenant.
- Comment le client va-t-il faire une mise à l’échelle sur plusieurs régions avec plusieurs requêtes effectuées en même temps, tout en isolant les charges de travail de lecture des charges de travail d’écriture ?
- Comment le client peut-il accéder aux données dans les différents déploiements ?
- Quelles méthodes d’authentification recommanderiez-vous pour les chemins d’interaction décrits dans le scénario ?
Tâches
Après avoir examiné le scénario et les conseils fournis, établissez le plus de spécifications possibles pour le projet.
Dressez la liste des technologies et des processus susceptibles d’être utilisés dans une solution. N’hésitez pas à adapter le scénario pour obtenir plus d’informations là où vous voulez clarifier les choses. Dans ce cas, vous pouvez faire des hypothèses.
Conseil
Pour les aspects liés à la sécurité, vous pouvez envisager d’utiliser le Playbook des bonnes pratiques de sécurité Azure SQL.
En utilisant une matrice de décision ou un autre processus de décision, sélectionnez les technologies et les processus qui composeront votre solution préliminaire.
Prenez des notes qui présentent les objectifs et les contraintes de votre projet, ainsi que la conception de la solution recommandée.
Une fois que vous avez une solution préliminaire à l’esprit, l’étape suivante consiste souvent à la présenter à l’équipe élargie (ou au client ou à la direction, selon le scénario). Vous devez assembler et présenter votre solution de façon à partager les objectifs et les contraintes du projet, ainsi que la manière dont votre solution répond à ces exigences.
Quand vous êtes prêt, répondez aux questions ci-dessous afin de comparer votre solution à un exemple de solution. Il peut y avoir plusieurs réponses correctes. Par conséquent, même si votre solution n’est pas listée, elle peut être viable.