Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Une solution native cloud crée une valeur métier en créant de nouvelles charges de travail (applications) ou en ajoutant de nouvelles fonctionnalités aux charges de travail existantes. Que vous développiez une nouvelle application ou que vous ajoutiez de nouvelles fonctionnalités à un système existant, le développement natif cloud est un parcours de planification, de création, de déploiement et d’optimisation de vos charges de travail. Cette infrastructure fournit des conseils de bout en bout pour vous assurer que votre application native cloud est alignée sur les objectifs métier, bien conçus et fournis avec un risque minimal.
Conditions préalables :Zone d’atterrissage Azure
Définir des objectifs métier pour les solutions natives cloud
Commencez par des objectifs métier clairs. Définissez les résultats spécifiques que votre solution native cloud doit atteindre, comme activer un nouveau produit numérique, entrer sur un nouveau marché, améliorer l’expérience client ou réduire les coûts opérationnels. Utilisez des indicateurs mesurables tels que la croissance du chiffre d’affaires, la réduction du délai de commercialisation ou le volume de tickets de support pour quantifier le succès. Pour les nouvelles fonctionnalités, définissez des objectifs tels que l’amélioration de l’expérience client, la réduction des coûts opérationnels ou l’augmentation de l’évolutivité du système.
Identifiez les contraintes et les critères de réussite. Documentez toutes les contraintes métier telles que le budget, la conformité ou les chronologies de livraison. Définissez à quoi ressemble la réussite pour chaque objectif. Par exemple, « lancez un nouveau portail client par Q4 » ou « réduisez la latence de paiement de 40%». Ces critères guident la hiérarchisation et aident à évaluer les compromis pendant la planification.
Valider l’alignement des parties prenantes. Vérifiez que toutes les parties prenantes (métier et techniques) sont d’accord sur les objectifs, les contraintes et le succès. Cet alignement peut impliquer des ateliers ou des approbations formelles. L’alignement précoce empêche la mauvaise communication ultérieure et évite une remaniement coûteuse, ce qui garantit que tout le monde partage les mêmes attentes dès le début.
Définir les exigences pour les solutions natives cloud
Documenter les exigences fonctionnelles. Documentez les capacités et fonctionnalités que le système doit fournir pour répondre aux besoins de l’utilisateur. Chaque exigence doit se lier à un objectif métier, ce qui garantit que l’effort de développement appuie directement les résultats souhaités. Utilisez des entrevues avec les parties prenantes et des documents de stratégie métier pour identifier les résultats à valeur élevée. Hiérarchiser les fonctionnalités en fonction de la valeur métier et de la faisabilité technique. Tracez chaque exigence d’un objectif métier mesurable pour justifier son inclusion.
Établissez des exigences non fonctionnelles. Les exigences non fonctionnelles définissent les exigences techniques pour répondre aux exigences fonctionnelles et à la gouvernance. Établissez les attributs de qualité et les cibles techniques nécessaires pour prendre en charge ces fonctionnalités. Définissez les métriques de fiabilité cibles telles que les objectifs de niveau de service (SLA) pour le temps d’activité, les objectifs de point de récupération (RPO) et les objectifs de temps de récupération (RTO). Établissez une base de référence de sécurité. Créez un modèle de coût. Définissez des cibles de performances.
Maîtriser l’étendue des solutions natives pour le cloud. Définissez clairement ce qui est in-scope vs out-of-scope pour la version initiale. Il est tentant d'inclure des fonctionnalités supplémentaires, mais l'extension de la portée peut compromettre les délais et les budgets. Documentez les limites de votre solution et implémentez un processus de contrôle des modifications pour toutes les nouvelles demandes. Approuvez uniquement les modifications qui appuient directement les objectifs définis et qui peuvent être livrées sans compromettre le calendrier ou le budget. Différer les idées de moindre priorité à un backlog futur. La gestion rigoureuse de l’étendue permet à l’équipe de se concentrer sur la fourniture des fonctionnalités les plus précieuses en premier dans les contraintes.
Planifier les architectures cloud-native
Une architecture bien planifiée est essentielle pour répondre à vos objectifs et exigences. Chaque décision architecturale majeure implique des compromis en matière d’extensibilité, de complexité, de coût et d’agilité. Les étapes suivantes et les points de décision vous aident à créer une conception native cloud alignée sur les meilleures pratiques :
Explorer les architectures cloud natives validées
Passez en revue les principes fondamentaux de l’architecture et les bonnes pratiques. Avant d’inventer une architecture à partir de zéro, passez en revue les architectures de référence validées et les principes de base du Centre d’architecture Azure. Les styles architecturaux familiers incluent l’exploration des architectures de référence validées pour les charges de travail courantes. Ces architectures permettent d’accélérer les décisions de conception et de réduire les risques.
Sélectionnez un style d’architecture approprié. Choisissez un style d’architecture en fonction des caractéristiques et des fonctionnalités d’équipe de votre charge de travail. Les styles d’architecture incluent N-tier (monolithique), microservices, pilotés par les événements (basés sur des messages), web-queue-worker. Par exemple, si vous avez besoin d’un développement rapide pour une application relativement simple, un monolithe de niveau N bien structuré peut suffire. Pour une application à grande échelle ou en évolution rapide avec des domaines distincts, des microservices ou des approches pilotées par les événements offrent une flexibilité (au coût de la complexité). En pratique, de nombreux systèmes finissent par un style hybride. Par exemple, il existe un cœur de microservices avec certains services partagés ou un sous-système piloté par les événements. La clé consiste à comprendre les compromis de chaque style et à sélectionner l’approche qui répond le mieux à vos exigences d’évolutivité, de résilience et d’agilité.
Appliquer les meilleures pratiques en matière de conception. Quel que soit le style que vous choisissez, respectez les principes fondamentaux de l’architecture cloud et les meilleures pratiques. Le Centre d’architecture Azure fournit un catalogue de modèles de conception cloud (nouvelle tentative, disjoncteur , CQRS) qui répondent aux défis courants liés aux charges de travail distribuées. L’intégration de ces modèles dans votre conception peut améliorer la fiabilité et les performances.
Intégrer les cinq piliers aux décisions de conception. Utilisez le framework Well-Architected pour guider les décisions sur la fiabilité, la sécurité, l’efficacité des performances , l’optimisation des coûts et l’excellence opérationnelle. Ces cinq piliers devraient informer toutes les décisions de conception. Par exemple, lors du choix d’une base de données, envisagez la fiabilité (redondance, sauvegarde), les performances et les coûts ensemble pour atteindre le bon équilibre. Documentez l’endroit où vous effectuez des compromis entre les piliers, tels que plus de coûts pour des performances plus élevées. Ces notes sont précieuses pour la gouvernance et les révisions futures.
Planifier des intégrations avec des systèmes existants
Stockez tous les systèmes et services dépendants. Les nouvelles solutions natives cloud fonctionnent rarement de manière isolée, sauf si vous êtes une startup en phase de démarrage. Réfléchissez à la façon dont votre nouvelle charge de travail ou fonctionnalité s’adapte à l’environnement. Mapper les flux de données et garantir la compatibilité avec les normes. Créez une liste complète de tous les systèmes avec lesquels votre charge de travail interagit. Cette liste comprend des API internes, des bases de données, des fournisseurs d’identité (Microsoft Entra ID), des outils de surveillance, des pipelines CI/CD et des systèmes locaux accessibles via VPN ou ExpressRoute. Utilisez des diagrammes d’architecture et des mappages de dépendances pour visualiser ces relations.
Classifiez les types d’intégration et les protocoles. Classez chaque point d’intégration par type (authentification, échange de données, messagerie) et protocole (REST, gRPC, ODBC, SAML, OAuth2). Cette classification permet d’identifier les exigences de compatibilité et les goulots d’étranglement potentiels.
Valider l’intégration des identités et des accès. Vérifiez que votre solution s’intègre au fournisseur d’identité de l’organisation. Par exemple, utilisez l’ID Microsoft Entra pour l’authentification et l’autorisation au lieu d’introduire un nouveau système d’identité. Confirmez la prise en charge de l’authentification unique (SSO), du contrôle d’accès en fonction du rôle (RBAC) et des stratégies d’accès conditionnel.
Évaluez la connectivité et la sécurité réseau. Passez en revue la façon dont votre charge de travail se connecte à d’autres systèmes. Validez les règles de pare-feu, la résolution DNS et les chemins d’accès de routage. Pour les scénarios hybrides, vérifiez que les configurations ExpressRoute ou VPN sont en place et testées. Utilisez Azure Network Watcher pour surveiller et résoudre les problèmes de connectivité.
Vérifiez la compatibilité et la conformité du flux de données. Mapper les flux de données entre les systèmes. Confirmez les formats de données, les schémas et les exigences de transformation. Vérifiez la conformité aux stratégies de résidence, de chiffrement et de rétention des données.
Testez les points d’intégration au début et en continu. Effectuez des tests d’intégration pendant les premières phases de développement. Utilisez des mocks ou des stubs pour les systèmes non disponibles. Automatisez ces tests dans votre pipeline CI/CD à l’aide d’outils tels qu’Azure DevOps ou GitHub Actions. Surveillez la latence, le débit et les taux d’erreur. Par exemple, vous souhaitez éviter une API dont votre application dépend qui ne prendrait pas en charge la charge requise ou un pare-feu réseau qui bloque votre service.
Documentez les contrats d’intégration et les contrats SLA. Définissez et documentez le comportement, la disponibilité et les performances attendus de chaque point d’intégration. Incluez la logique de nouvelle tentative, les paramètres de délai d’attente et les mécanismes de secours. Aligner sur les contrats de niveau de service (SLA) des systèmes dépendants.
Sélectionner les services et niveaux de service Azure appropriés
Utilisez des guides de décision pour sélectionner des services qui correspondent aux exigences de charge de travail. Azure fournit plusieurs options pour exécuter votre code d’application, chacune avec des avantages et des inconvénients. Passez en revue la vue d’ensemble des choix technologiques pour identifier les services qui s’alignent sur vos exigences fonctionnelles et non fonctionnelles. Hiérarchiser les options PaaS (Platform-as-a-Service), car ces services réduisent la surcharge opérationnelle en gérant automatiquement la gestion de l’infrastructure, la mise à jour corrective et la mise à l’échelle.
Définissez les modèles d’utilisation et les exigences de performances pour sélectionner les niveaux de service. La sélection du niveau de service affecte à la fois le coût et la capacité. Documentez les volumes de transactions attendus, les charges utilisateur simultanées, les exigences de stockage et les cibles de performances telles que les temps de réponse et le débit. Utilisez ces métriques pour sélectionner un niveau de service initial (SKU) qui répond aux exigences de référence sans surprovisionnement significatif. Planifiez l’ajustement des niveaux en fonction des modèles d’utilisation réels après le déploiement.
Valider la compatibilité des fonctionnalités entre les niveaux de service sélectionnés. Les fonctionnalités critiques telles que les fonctionnalités de sécurité avancées, les options de haute disponibilité ou les API d’intégration varient selon le niveau de service. Créez une matrice de fonctionnalités qui mappe les fonctionnalités requises aux références SKU disponibles. Vérifiez que le niveau sélectionné prend en charge toutes les fonctionnalités nécessaires pour éviter les migrations coûteuses ou les modifications architecturales ultérieurement. Consultez la documentation spécifique au service pour vérifier la disponibilité des fonctionnalités et leurs limitations.
Sélectionner le nombre de régions à utiliser
Évaluez les compromis des déploiements multirégions. Les architectures à région unique sont plus simples et moins coûteuses, mais une panne régionale entraîne la panne de votre application. Les déploiements multirégions peuvent obtenir une disponibilité plus élevée (une région peut échouer et les utilisateurs sont servis à partir d’une autre) et peuvent également améliorer les performances en servant les utilisateurs de la région la plus proche. Le compromis est une complexité accrue dans le déploiement et la synchronisation des données. Vous devez gérer la réplication des données entre les régions avec des problèmes de cohérence potentiels, le routage du trafic global et des coûts plus élevés. Laissez vos exigences de fiabilité prendre cette décision.
Utilisez des cibles de fiabilité pour guider la stratégie régionale. Définissez les objectifs de niveau de service (SLO), les objectifs de point de récupération (RPO) et les objectifs de temps de récupération (RTO) pour déterminer les exigences régionales.
Vérifiez la conformité aux réglementations de résidence des données. Collaborez avec les équipes juridiques et de conformité pour garantir que les choix régionaux répondent aux obligations réglementaires.
Architectures de document
Créez un diagramme d’architecture détaillé et un document de conception. La documentation prend en charge l’implémentation, la révision et la maintenance future. Incluez les services Azure sélectionnés, les références SKU, les flux de données et les interactions utilisateur. Vérifiez que le diagramme fournit une représentation visuelle claire de l’architecture pour prendre en charge l’implémentation et les révisions.
Enregistrez les principales décisions de conception et compromis. Documentez la justification des choix architecturaux, y compris les exigences non fonctionnelles telles que la fiabilité, la sécurité et les performances. Mettez en évidence tous les compromis faits pour équilibrer les priorités concurrentes.
Planifier la stratégie de déploiement natif au cloud
Lorsque vous déployez la solution native cloud en production, suivez une stratégie planifiée plutôt qu’un push ad hoc. Un plan de déploiement solide réduit les effets sur les utilisateurs et fournit des moyens de récupérer si quelque chose ne va pas.
Planifier les pratiques de développement et de déploiement
Les pratiques de développement et de déploiement garantissent la cohérence de la livraison et de la préparation opérationnelle dans les environnements. Ces pratiques réduisent les risques de déploiement et améliorent la coordination de l’équipe.
Établissez des pratiques DevOps pour l’automatisation du déploiement. Les pratiques DevOps alignent les équipes de développement et d’exploitation via l’automatisation, le contrôle de version et les pipelines CI/CD. Utilisez des outils tels qu’Azure DevOps ou GitHub Actions pour automatiser les workflows de génération, de test et de déploiement. Cette approche réduit les erreurs manuelles, accélère les cycles de publication et fournit des processus de déploiement cohérents entre les environnements.
Planifiez la préparation opérationnelle pour prendre en charge les activités de déploiement. La préparation opérationnelle inclut la surveillance, les alertes et les procédures de réponse aux incidents pour les scénarios de déploiement. Documentez les runbooks de déploiement et les scripts d’automatisation qui couvrent les procédures de restauration, les vérifications d’intégrité et les étapes de résolution des problèmes. Stockez ces ressources dans un emplacement central tel qu’Azure DevOps Wiki ou GitHub pour garantir l’accessibilité pendant les activités de déploiement.
Définissez des pratiques de développement qui prennent en charge des déploiements fiables. Utilisez des normes de codage, des révisions d’homologues et des tests automatisés pour garantir la qualité du code et la préparation du déploiement. Intégrez ces pratiques à votre pipeline CI/CD pour imposer des contrôles de qualité avant le déploiement. Incluez des tests spécifiques au déploiement tels que les tests d’intégration, les tests de fumée et la validation des performances pour vérifier la préparation du système pour la production.
Planifier le déploiement des nouvelles charges de travail
Utilisez une exposition progressive pour limiter l’impact. Pour une nouvelle application (greenfield) sans utilisateurs existants, vous devez effectuer un lancement souple. Déployez en production, mais exposez-le uniquement aux utilisateurs internes ou à un groupe pilote initialement. Cette approche est un déploiement de canari pour nouvelle charge de travail. S’il est vraiment nouveau et isolé, un déploiement unique en production complète est possible, mais l’exposition progressive est toujours recommandée pour détecter les problèmes d’une manière contrôlée. Ne déchaînez pas le système sur 100% d’utilisateurs le jour 1 sans une validation réelle en premier. Pour plus d’informations, consultez WAF - Adopter un modèle d’exposition progressif.
Documenter les procédures opérationnelles et les chemins d’escalade. Créez une documentation claire pour le redémarrage des services, l’accès aux journaux, la gestion des problèmes courants et l’escalade des incidents. Stockez cette documentation dans un référentiel partagé tel que SharePoint ou GitHub pour garantir la disponibilité des équipes de support.
Planifier le déploiement de nouvelles fonctionnalités
Planifiez l’intégration de nouvelles fonctionnalités à l’aide de la gestion des modifications. Suivez le processus de gestion des modifications de votre organisation pour contrôler et documenter les modifications de production. Définissez des procédures de restauration, telles que la restauration des versions d’application ou la restauration des sauvegardes de base de données. Sécuriser l’approbation des parties prenantes avant le déploiement pour garantir l’alignement avec les objectifs métier. Pour plus d’informations, consultez Gérer les modifications dans CAF.
Utilisez des mises à jour sur place pour les modifications mineures ou rétrocompatibles. Déployez des mises à jour directement dans l’environnement de production à l’aide de mises à jour propagées ou d’indicateurs de fonctionnalité. Commencez par un petit pourcentage d’utilisateurs ou d’instances. Surveillez les métriques système et les journaux pour valider la stabilité avant le déploiement complet.
Utilisez des déploiements parallèles (bleu-vert) pour les changements majeurs ou à haut risque. Déployez la nouvelle version dans un environnement distinct. Acheminer une petite partie du trafic en direct vers la nouvelle version pour valider le comportement. Si elle réussit, déplacez tout le trafic vers la nouvelle version. Si des problèmes se produisent, rétablissez le trafic vers la version d’origine pour garantir la continuité.
Planifiez la remise opérationnelle des nouvelles charges de travail. Identifiez l’équipe responsable de l’exploitation et de la prise en charge de la solution après le déploiement. Définissez le modèle de support (support 24/7 sur appel ou heures d’ouverture) et assurez-vous que toutes les parties prenantes comprennent leurs rôles.
Définissez les responsabilités de propriété et de support. Vérifiez que l’équipe des opérations est prête à prendre en charge la nouvelle fonctionnalité. Mettez à jour la documentation et les chemins d’escalade pour refléter les nouvelles responsabilités et garantir une réponse rapide aux incidents.
Définir un plan de repli pour les solutions cloud natives
Un plan de restauration permet aux équipes d’inverser rapidement les modifications lorsqu’un déploiement échoue ou introduit des risques. Un plan bien défini réduit les temps d’arrêt, limite l’impact de l’entreprise et maintient la fiabilité du système. Établissez toujours des critères et des procédures de restauration à l’état antérieur avant de lancer une migration ou un déploiement.
Définir un déploiement ayant échoué. Collaborez avec les parties prenantes de l’entreprise, les propriétaires de charges de travail et les équipes d’exploitation pour déterminer ce qui compte en tant que déploiement ayant échoué. Par exemple, les vérifications d’intégrité ayant échoué, les performances médiocres, les problèmes de sécurité ou les métriques de réussite non satisfaites. Cette définition garantit que les décisions de retrait s’alignent sur la tolérance aux risques de votre organisation. Incluez des conditions spécifiques qui déclenchent une restauration dans votre plan de déploiement, telles que les limites d’utilisation du processeur, les seuils de temps de réponse ou les taux d’erreur. Cette évaluation rend les décisions de retour arrière claires et cohérentes pendant les incidents.
Automatisez les étapes de restauration dans les pipelines CI/CD. Utilisez des outils tels qu’Azure Pipelines ou GitHub Actions pour automatiser les processus de restauration. Par exemple, configurez les pipelines pour redéployer une version précédente si les vérifications d’intégrité échouent.
Créez des instructions de restauration spécifiques à la charge de travail. Développez les étapes de restauration qui correspondent à votre type de charge de travail, à votre environnement et à votre méthode de déploiement. Par exemple, les déploiements d’infrastructure en tant que code nécessitent de réappliquer des modèles précédents. Les restaurations d’application impliquent le redéploiement d’une image de conteneur précédente. Attachez des scripts de restauration, des instantanés de configuration et des modèles d’infrastructure en tant que code à votre plan de restauration. Ces ressources permettent une exécution rapide et réduisent la dépendance à l’intervention manuelle.
Tester les procédures de rollback. Simuler des échecs de déploiement dans un environnement de préproduction pour valider l’efficacité du retour arrière. Identifiez et résolvez les lacunes dans l’automatisation, les autorisations ou les dépendances. Confirmez que le retour en arrière restaure le système dans un état stable et connu.
Améliorer les stratégies de restauration Après chaque déploiement ou événement de restauration, effectuez une rétrospective pour évaluer ce qui a fonctionné et ce qui n’a pas fonctionné. Mettez à jour les critères de restauration, les procédures et l’automatisation en fonction des leçons apprises, des modifications architecturales ou des nouveaux outils. Conservez les documents pour vous assurer que les stratégies de restauration restent actuelles et efficaces.