Créer pour les besoins de l’entreprise
Chaque décision de conception doit être justifiée par un besoin de l’entreprise. Ce principe de conception peut vous sembler évident, mais vous devez impérativement le garder à l’esprit lorsque vous concevez des applications Azure.
Votre application doit-elle prendre en charge des millions d’utilisateurs, ou quelques milliers ? Existe-t-il de grandes rafales de trafic ou une charge de travail stable ? Quel niveau de panne d’application est acceptable ? En fin de compte, les exigences métiers déterminent ces considérations de conception.
Les recommandations suivantes vous aident à concevoir et à générer des solutions pour répondre aux besoins de l’entreprise :
Définissez des objectifs stratégiques, tels que l’objectif de délai de récupération (RTO), l’objectif de point de récupération (RPO) et l’interruption acceptable maximale (MTO). Ces valeurs doivent refléter les décisions prises concernant l’architecture.
Par exemple, supposons que votre entreprise nécessite un RTO et un RPO très bas. Vous pouvez choisir d'utiliser une architecture redondante pour répondre à ces exigences. Si votre entreprise peut tolérer un RTO et un RPO plus élevés, l'ajout de redondance peut entraîner des coûts supplémentaires sans aucun avantage commercial.
Tenez compte des risques de défaillance que vous devez atténuer. Suivez les conseils de conception pour l'autoréparation pour concevoir votre solution afin qu'elle soit résistante à de nombreux types de modes de défaillance courants. Déterminez si vous devez prendre en compte des situations moins probables, comme une zone géographique subissant une catastrophe naturelle majeure susceptible d'affecter toutes les zones de disponibilité de la région. L'atténuation de ces risques peu courants est généralement plus coûteuse et implique des compromis importants, alors ayez une compréhension claire de la tolérance au risque de l'entreprise.
Documentez les Contrats de niveau de service (SLA) et les objectifs de niveau de service (SLO), y compris les métriques de disponibilité et de performances. Par exemple, une solution proposée peut fournir une disponibilité de 99,95 %. La conformité du SLO au SLA est une décision métier.
Modélisez des applications pour votre domaine métier. Analysez les exigences métiers et utilisez ces exigences pour modéliser la solution. Envisagez d'adopter une approche de conception pilotée par le domaine pour créer des modèles de domaine qui reflètent vos processus d'entreprise et cas d'usage.
Définissez des exigences fonctionnelles et non fonctionnelles. Les exigences fonctionnelles déterminent si une application effectue sa tâche. Les exigences non fonctionnelles déterminent la bonne exécution de l’application. Veillez à comprendre les exigences non fonctionnelles telles que la scalabilité, la disponibilité et la latence. Ces exigences influencent les décisions de conception et les choix de technologie.
Décomposer les charges de travail en fonctionnalités distinctes. Une charge de travail est un ensemble de ressources d’application, de données et d’infrastructures de support qui fonctionnent ensemble pour atteindre des résultats commerciaux définis. Une charge de travail se compose de composants ainsi que de procédures de développement et d’exploitation. Les charges de travail peuvent souvent être décomposées en fonctionnalités distinctes qui s’alignent sur les flux d’utilisateurs, de données ou de systèmes, et ces flux peuvent être attribués à une valeur et avoir des exigences non fonctionnelles.
Différents flux d’utilisateurs, de données ou de systèmes ont souvent des exigences différentes en matière de disponibilité, de scalabilité, de cohérence des données et de récupération d’urgence. Les systèmes bien conçus permettent d’optimiser votre conception pour chaque flux. Pour y parvenir, vous devez décomposer les charges de travail en composants ajustables. Une stratégie typique consiste à classer les composants en fonction de leur valeur. Par exemple, les composants de niveau 1 sont cruciaux et doivent être optimisés sans se soucier des coûts. Les composants de niveau 2 sont importants mais peuvent être temporairement réduits avec des conséquences minimales. Les composants de niveau 3 sont facultatifs ; ils doivent rester rentables et faciles à gérer. Établir une compréhension commune de la valeur des flux aide tous ceux qui conçoivent et font évoluer une charge de travail à maintenir un équilibre entre le coût et les autres exigences non fonctionnelles.
Planifiez dans une perspective de croissance. Une solution peut prendre en charge les besoins actuels de nombre d’utilisateurs, de volume de transactions et de stockage de données, mais elle doit également gérer la croissance sans modifications architecturales majeures. Tenez également compte du fait que votre modèle d’entreprise et vos exigences métiers peuvent évoluer avec le temps. Il est difficile de faire évoluer une solution pour de nouveaux scénarios et cas d’usage si le modèle de service et les modèles de données d’une application sont trop rigides.
Aligner le modèle commercial et le coût. La longévité d’un système est influencée par la manière dont ses coûts s’alignent sur le modèle commercial. En tant qu’architecte, vous devez prendre en compte les facteurs de valeur et utiliser cette compréhension pour guider vos décisions. Vous devez identifier la dimension dans laquelle votre solution apportera de la valeur (comme la rentabilité), puis vous assurer que l’architecture suit ce flux de valeur. De cette façon, votre architecture peut maximiser la valeur par rapport à l’investissement, en produisant un retour sur investissement (ROI) aligné sur les attentes commerciales.
Gérez les coûts. Dans une application locale traditionnelle, vous payez d'avance le matériel en tant que dépense d'investissement. Dans une application cloud, vous payez pour les ressources que vous consommez. Assurez-vous que vous comprenez le modèle de tarification de vos services. Les coûts totaux peuvent inclure l’utilisation de la bande passante réseau, le stockage, les adresses IP et la consommation des services.
Prenez également en compte les coûts d’exploitation. Dans le cloud, vous n’avez pas à gérer le matériel ni l’infrastructure, mais vous devez continuer à gérer les applications, DevOps, la réponse aux incidents et la récupération d’urgence.