Affiner votre plateforme d’application pour simplifier le développement d’applications et la gestion de l’infrastructure

Une grande partie de l’amélioration des pratiques d’ingénierie de plateforme de votre organisation consiste à évaluer votre plateforme d’application. Une plateforme d’application inclut tous les outils et services utilisés pour prendre en charge le développement, le déploiement et la gestion des applications dans votre organisation.

Simplifier et normaliser

L’infrastructure en tant que code (IaC) et les outils d’automatisation peuvent être combinés avec des modèles pour normaliser le déploiement d’infrastructure et d’application. Pour réduire la charge des spécificités de la plateforme sur l’utilisateur final, extrayez les détails de la plateforme en décomposant les choix en conventions de nommage pouvant être relatables, par exemple :

• Catégories de types de ressources (calcul élevé, mémoire élevée)
• Catégories de taille des ressources (dimensionnement de t-shirt, petit moyen et grand)

Les modèles doivent représenter des exigences générales qui ont été testées avec des configurations prédéfinies, afin que les équipes de développement puissent immédiatement commencer à fournir des paramètres minimaux et sans avoir à passer en revue les options. Toutefois, il y aura des occasions où les équipes doivent modifier davantage d’options sur les modèles publiés que celles disponibles ou souhaitables. Par exemple, une conception approuvée peut avoir besoin d’une configuration spécifique qui se trouve en dehors des valeurs par défaut du modèle pris en charge. Dans cette instance, les équipes d’ingénierie de plateforme peuvent créer une configuration ponctuelle, puis décider si le modèle doit incorporer ces modifications par défaut.

Vous pouvez suivre les modifications à l’aide d’outils IaC avec des fonctionnalités de détection de dérive qui peuvent corriger automatiquement la dérive (GitOps). Ces outils sont des outils IaC natifs terraform et cloud (exemples, API cluster, Crossplane, Opérateur de service Azure v2). En dehors de la dérive des outils IaC, détectez qu’il existe des outils de configuration cloud qui peuvent rechercher des configurations de ressources, telles qu’Azure Resource Graph. Ceux-ci peuvent servir de deux avantages ; vous surveillez les modifications en dehors du code d’infrastructure et pour examiner les configurations prédéfinies modifiées. Pour éviter d’être trop rigide, vous pouvez implémenter des tolérances dans les déploiements avec des limites prédéfinies. Par exemple, vous pouvez utiliser Azure Policy pour limiter le nombre de nœuds Kubernetes qu’un déploiement peut avoir.

Auto-géré ou géré ?

Dans les clouds publics, vous avez le choix d’utiliser SaaS, PaaS ou IaaS. Pour en savoir plus sur SaaS, PaaS et IaaS, consultez le module de formation Décrire les concepts cloud. Les services PaaS offrent des expériences de développement simplifiées, mais sont plus prescriptifs avec leurs modèles d’application. En fin de compte, il existe un compromis entre facilité d’utilisation et contrôle que vous devez évaluer.

Pendant la conception de la plateforme, évaluez et hiérarchisez les besoins de service de votre organisation. Par exemple, si vous créez des applications directement sur Azure Kubernetes Service (AKS) ou via Azure Container Apps (ACA) dépend de vos besoins pour le service et de votre capacité interne et de votre ensemble de compétences. Il en va de même pour les services de style fonction comme Azure Functions ou Azure App Service. ACA, Azure Functions et App Service réduisent la complexité, tandis qu’AKS offre plus de flexibilité et de contrôle. Des modèles d’application plus expérimentaux comme le projet d’incubation OSS Radius tentent de fournir un équilibre entre les deux, mais sont généralement dans des phases antérieures de maturité que les services cloud avec une prise en charge complète et une présence dans les formats IaC établis.

Les problèmes que vous avez identifiés lorsque vous avez planifié doivent vous aider à évaluer la fin de cette échelle. Veillez à prendre en compte votre propre ensemble de compétences existant interne au fur et à mesure que vous prenez une décision.

Ressources partagées et dédiées

Au sein de votre organisation, il existe des ressources qui peuvent être partagées par plusieurs applications pour augmenter l’utilisation et l’efficacité des coûts. Chaque ressource partagée a son propre ensemble de considérations. Par exemple, il s’agit de considérations relatives au partage de clusters K8s, mais certaines s’appliquent à d’autres types de ressources :

• Organisation : le partage de ressources telles que des clusters au sein de l’organisation, plutôt que sur l’ensemble des limites de l’organisation, peut améliorer la façon dont elles s’alignent sur la direction de l’organisation, les exigences et la priorité.
• Location d’application : les applications peuvent avoir des exigences d’isolation de location différentes ; vous devez examiner la sécurité des applications et la conformité réglementaire individuelle si elles peuvent coexister avec d’autres applications. Par exemple, dans Kubernetes, les applications peuvent utiliser l’isolation de l’espace de noms. Toutefois, vous devez également envisager la location d’applications pour différents types d’environnement. Par exemple, il est souvent préférable d’éviter de combiner des applications de test avec des applications de production sur les mêmes clusters afin d’éviter les impacts inattendus en raison de problèmes de sécurité ou de configuration incorrects. Vous pouvez également choisir de tester et d’optimiser d’abord les clusters Kubernetes dédiés pour suivre ces problèmes avant le déploiement sur un cluster partagé à la place. Quelle que soit votre approche, la cohérence est la clé pour éviter la confusion et les erreurs.
• Consommation des ressources : comprendre l’utilisation de chaque ressource d’application, la capacité de rechange et effectuer une projection pour estimer si le partage est viable. Vous devez également connaître les limites des ressources consommées (capacité du centre de données ou limites d’abonnement). L’objectif est d’éviter de déplacer votre application et vos dépendances en raison de contraintes de ressources dans un environnement partagé ou d’avoir des incidents de site en direct lorsque la capacité est insuffisante. Utilisez des limites de ressources, des tests représentatifs, des alertes de surveillance et des rapports pour identifier la consommation des ressources et protéger contre les applications consommant trop de ressources.
• Optimiser les configurations partagées : les ressources partagées telles que les clusters partagés nécessitent une considération et une configuration supplémentaires. Ces considérations incluent la facturation croisée, l’allocation des ressources, la gestion des autorisations, la propriété de la charge de travail, le partage de données, la coordination de la mise à niveau, le placement de la charge de travail, l’établissement, la gestion et l’itération d’une configuration de base, une gestion de la capacité et un placement de charge de travail. Les ressources partagées présentent des avantages, mais si les configurations standard sont trop restrictives et ne évoluent pas, elles deviennent obsolètes.

Implémenter des stratégies de gouvernance

La gouvernance est un élément clé de l’activation de la libre-service avec des garde-fous, mais l’application de règles de conformité d’une manière qui n’a pas d’impact sur la valeur métier des applications est un défi courant. Il existe deux parties de la gouvernance :

• Conformité initiale du déploiement (début droit) : cela peut être réalisé avec des modèles IaC standardisés mis à disposition via des catalogues, avec la gestion des autorisations et les stratégies pour garantir que seules les ressources et configurations autorisées peuvent être déployées.
• Maintien de la conformité (restez à droite) : les outils basés sur des stratégies peuvent vous empêcher ou vous alerter en cas de modification des ressources. Au-delà de votre infrastructure principale, envisagez également de prendre en charge la conformité à l’intérieur des ressources telles que les K8, ainsi que les systèmes d’exploitation utilisés dans vos conteneurs ou machines virtuelles. Par exemple, vous pouvez appliquer une configuration de système d’exploitation verrouillée ou installer des outils logiciels de sécurité tels que la stratégie de groupe Windows, SELinux, AppArmor, Azure Policy ou Kyverno. Si les développeurs ont uniquement accès aux référentiels IaC, vous pouvez ajouter des flux de travail d’approbation pour examiner les modifications proposées et empêcher l’accès direct aux plans de contrôle des ressources (par exemple, Azure).

La maintenance de la conformité nécessite des outils permettant d’accéder, de signaler et d’agir sur les problèmes. Par exemple, Azure Policy peut être utilisé avec de nombreux services Azure pour l’audit, la création de rapports et la correction. Il dispose également de différents modes tels que Audit, Deny et DeployIfNotExists en fonction de vos besoins.

Bien que les stratégies puissent appliquer la conformité, elles peuvent également interrompre les applications de manière inattendue. Par conséquent, envisagez d’évoluer vers une stratégie en tant que pratique de code (PaC) lors de l’exploitation à grande échelle. Dans le cadre de votre démarrage droit et de votre bonne approche, PaC fournit :

• Normes gérées de manière centralisée
• Contrôle de version pour vos stratégies
• Test et validation automatisés
• Réduction du temps de déploiement
• Déploiement continu

PaC peut aider à réduire le rayon d’explosion d’une stratégie potentiellement incorrecte avec des fonctionnalités telles que :

• Définitions de stratégie stockées en tant que code dans un référentiel qui est examiné et approuvé.
• Automatisation pour fournir des tests et une validation.
• Le déploiement progressif basé sur l’anneau des stratégies et la correction sur les ressources existantes permettent de réduire le rayon d’explosion d’une stratégie potentiellement incorrecte.
• La tâche de correction est intégrée, avec des contrôles tels que l’arrêt de la tâche de correction si plus de 90 % des déploiements échouent.

Implémenter l’observabilité et la journalisation spécifiques au rôle

Pour prendre en charge vos applications et votre infrastructure, vous avez besoin de l’observabilité et de la journalisation sur l’ensemble de votre pile.

Les exigences diffèrent par rôle. Par exemple, l’équipe d’ingénierie et d’exploitation de la plateforme nécessite des tableaux de bord pour examiner l’intégrité et la capacité de l’infrastructure avec des alertes appropriées. Les développeurs nécessitent des métriques d’application, des journaux et des traces pour résoudre les problèmes et les tableaux de bord personnalisés qui montrent l’intégrité de l’application et de l’infrastructure. L’un de ces rôles peut rencontrer un problème : la surcharge cognitive provenant de trop d’informations ou de lacunes de connaissances en raison d’un manque d’informations utiles.

Pour résoudre ces problèmes, tenez compte des éléments suivants :

• Normes : appliquez des normes de journalisation pour faciliter la création et la réutilisation de tableaux de bord standardisés et simplifier le traitement de l’ingestion par le biais d’une infrastructure d’observabilité OpenTelemetry.
• Autorisations : fournissez des tableaux de bord au niveau de l’équipe ou de l’application à l’aide de quelque chose comme Grafana pour fournir des données inscrites pour toute personne concernée, ainsi qu’une installation permettant aux membres approuvés des équipes d’application d’accéder en toute sécurité aux journaux d’activité si nécessaire.
• Rétention : la conservation des journaux et des métriques peut être coûteuse et peut créer des risques inattendus ou des violations de conformité. Établissez les valeurs par défaut de rétention et publiez-les dans le cadre de vos conseils de démarrage appropriés.
• Surveiller les limites des ressources : les équipes d’opérations doivent être en mesure d’identifier et de suivre les limitations d’un type donné de ressource. Ces limitations doivent être considérées comme des modèles ou des stratégies IaC à l’aide d’outils tels qu’Azure Policy. Les opérations doivent ensuite surveiller de manière proactive l’utilisation de tableaux de bord dans quelque chose comme Grafana et développer des ressources partagées où la mise à l’échelle automatisée n’est pas possible ou activée. Par exemple, surveillez le nombre de nœuds de cluster K8s pour la capacité à mesure que les applications sont intégrées et modifiées au fil du temps. Les alertes sont nécessaires, et ces définitions doivent être stockées en tant que code afin qu’elles puissent être ajoutées par programmation aux ressources.
• Identifier les métriques de capacité et d’intégrité clés : surveiller et alerter le système d’exploitation et les ressources partagées (exemples : PROCESSEUR, mémoire, stockage) pour la faim avec la collecte de métriques à l’aide de quelque chose comme Prometheus ou Azure Container Insights. Vous pouvez surveiller les sockets/ports en cours d’utilisation, la consommation de bande passante réseau des applications chatteuses et le nombre d’applications avec état hébergées sur le cluster.

Créer une sécurité avec le principe des privilèges minimum, la gestion unifiée de la sécurité et la détection des menaces

La sécurité est requise à chaque couche, à partir du code, du conteneur, du cluster et de l’infrastructure/cloud. Voici les étapes de sécurité minimales recommandées :

• Suivez le principe des privilèges minimum.
• Unifier votre gestion de sécurité DevOps sur plusieurs pipelines.
• Assurez-vous que les insights contextuels pour identifier et corriger vos risques les plus critiques sont visibles.
• Activez la détection et la réponse aux menaces modernes dans vos charges de travail cloud au moment de l’exécution.

Pour résoudre les problèmes dans ce domaine, vous avez besoin d’outils pour évaluer les outils qui fonctionnent sur vos systèmes d’ingénierie et d’applications, ressources et services dans les clouds et hybrides (par exemple, Microsoft Defender pour le cloud). Au-delà de la sécurité des applications, évaluez :

• Gestion de la surface d’attaque externe à l’aide de quelque chose comme Gestion de surface d’attaque externe Microsoft Defender (Defender EASM).
• Services de sécurité réseau - Applications et protection des charges de travail cloud contre les cyberattaques basées sur le réseau avec quelque chose comme Azure Network Security.
• Sécurité intelligente analytique - Utilisation d’une solution SIEM (Security Information and Event Management) comme Microsoft Sentinel
• Méthodes de gouvernance, de protection, de visualisation et de gestion sécurisées de votre patrimoine de données, comme Microsoft Purview
• Méthodes d’analyse du code pour détecter les vulnérabilités de sécurité potentielles, détecter les secrets, passer en revue les dépendances telles que GitHub Advanced Security et GitHub Advanced Security pour Azure DevOps.
• Gestion de votre chaîne d’approvisionnement logicielle, en particulier pour les conteneurs (par exemple, appliquez l’infrastructure de chaîne d’approvisionnement sécurisée des conteneurs).

Les exigences en matière d’autorisations peuvent différer selon l’environnement. Par exemple, dans certaines organisations, les équipes individuelles ne sont pas autorisées à accéder aux ressources de production et les nouvelles applications ne peuvent pas être déployées automatiquement tant que les révisions ne sont pas terminées. Toutefois, le déploiement automatisé des ressources et des applications et l’accès aux clusters pour la résolution des problèmes peuvent être autorisés dans les environnements de développement et de test.

La gestion de l’accès aux identités aux services, aux applications, à l’infrastructure à grande échelle peut être difficile. Fournisseurs d’identité pour créer, gérer et gérer des informations d’identité. Votre plan doit inclure des services d’authentification pour les applications et les services et qui peuvent s’intégrer aux systèmes de contrôle d’accès en fonction du rôle (RBAC) à grande échelle. Par exemple, vous pouvez utiliser l’ID Microsoft Entra pour fournir l’authentification et l’autorisation à grande échelle pour les services Azure comme Azure Kubernetes Service sans avoir à configurer les autorisations directement sur chaque cluster individuel.

Les applications peuvent avoir besoin d’accéder à une identité pour accéder aux ressources cloud telles que le stockage. Vous devez examiner les exigences et évaluer la façon dont votre fournisseur d’identité peut le prendre en charge de la manière la plus sécurisée possible. Par exemple, dans AKS, les applications natives cloud peuvent utiliser une identité de charge de travail qui fédère avec l’ID Microsoft Entra pour permettre aux charges de travail conteneurisées de s’authentifier. Cette approche permet aux applications d’accéder aux ressources cloud sans échange de secrets dans le code de l’application.

Réduire les coûts en identifiant les propriétaires de charge de travail et les ressources de suivi

La gestion des coûts est une autre partie de l’ingénierie de la plateforme. Pour gérer correctement votre plateforme d’applications, vous avez besoin d’un moyen d’identifier les propriétaires de charge de travail. Vous souhaitez obtenir un inventaire des ressources qui sont mappée aux propriétaires pour un ensemble particulier de métadonnées. Par exemple, dans Azure, vous pouvez utiliser des étiquettes AKS, des étiquettes Azure Resource Manager, ainsi que des concepts tels que des projets dans des environnements de déploiement Azure pour regrouper vos ressources à différents niveaux. Pour que cela fonctionne, les métadonnées choisies doivent inclure des propriétés obligatoires (à l’aide de quelque chose comme Azure Policy) lors du déploiement de charges de travail et de ressources. Cela permet d’allouer des coûts, de mapper les ressources de solution et les propriétaires. Envisagez d’exécuter des rapports réguliers pour suivre les ressources orphelines.

Au-delà du suivi, vous devrez peut-être attribuer des coûts aux équipes d’applications individuelles pour leur utilisation des ressources à l’aide de ces mêmes métadonnées avec des systèmes de gestion des coûts tels que Microsoft Cost Management. Bien que cette méthode effectue le suivi des ressources approvisionnées par les équipes d’application, elle ne couvre pas le coût des ressources partagées telles que votre fournisseur d’identité, la journalisation et le stockage de métriques et la consommation de bande passante réseau. Pour les ressources partagées, vous pouvez également diviser les coûts opérationnels par les équipes individuelles ou fournir des systèmes dédiés (par exemple, le stockage de journalisation) où il existe une consommation nonuniforme. Certains types de ressources partagées peuvent être en mesure de fournir des insights sur la consommation des ressources, par exemple Kubernetes dispose d’outils tels qu’OpenCost ou Kubecost et peuvent vous aider.

Vous devez également rechercher des outils d’analyse des coûts dans lesquels vous pouvez passer en revue les dépenses actuelles. Par exemple, dans Portail Azure il existe des alertes de coût et des budgets qui peuvent suivre la consommation de ressources dans un groupe et envoyer des notifications lorsque vous atteignez des seuils prédéfinis.

Décider quand et où investir

Si vous avez plusieurs plateformes d’application, il peut être difficile de décider quand et où investir dans des améliorations qui résolvent des problèmes tels que des coûts élevés ou une mauvaise observabilité. Si vous démarrez à nouveau, le Centre d’architecture Azure a plusieurs modèles potentiels pour vous permettre d’évaluer. Mais au-delà de cela, voici quelques questions à prendre en compte lorsque vous commencez à planifier ce que vous voulez faire :

L’adaptation de vos investissements de plateforme d’applications existants peut être un bon moyen de se lancer. Lorsque vous effectuez des mises à jour, envisagez de commencer par de nouvelles applications pour simplifier les idées de pilotage avant tout type de déploiement. Factor in this change through IaC and application templating. Investissez dans des solutions personnalisées pour vos besoins uniques dans des domaines à fort impact et à valeur élevée. Sinon, essayez d’utiliser une solution prête à l’emploi. Comme pour les systèmes d’ingénierie, concentrez-vous sur l’automatisation de l’approvisionnement, du suivi et du déploiement plutôt que de supposer un chemin rigide pour vous aider à gérer les changements au fil du temps.

Contenu connexe