Principes de conception pour les applications natives en nuage dans ASP.NET

Explorons les bases des applications natives en nuage et la manière de concevoir des applications .NET pour un avenir dans le nuage.

Alors que de plus en plus de éditeurs de logiciels commencent à exécuter leurs applications dans le nuage, vous vous demandez peut-être quoi vous pouvez faire pour faciliter la transition de vos applications. Même si vous n’avez pas l’intention de faire le saut de sitôt, la conception de vos applications pour qu’elle soit native au cloud n’exige pas un investissement substantiel et vous facilitera la vie. Dans cet article, vous apprendrez quelques modèles et pratiques à suivre pour rendre vos applications plus compatibles avec le cloud.

Que signifie "Cloud Native"?

Un terme que nous commençons à entendre de plus en plus est cloud. originaire de. Effectuer une recherche sur le Web sur des applications natives en nuage donne souvent lieu à de nombreuses explications vagues. La meilleure définition provient de la Cloud Native Computing Foundation un consortium d’organisations promouvant le style architectural en nuage. Nous citons la Charte du CNCF :

Les technologies natives en nuage permettent aux organisations de créer et d’exécuter des applications évolutives dans des environnements modernes et dynamiques tels que les clouds publics, privés et hybrides. Les conteneurs, les maillages de service, les microservices, l'infrastructure immuable et les API déclaratives illustrent bien cette approche. Ces techniques permettent des systèmes à couplage lâche qui sont résilients, gérables et observables. Combinées à une automatisation robuste, elles permettent aux ingénieurs d’apporter des modifications à fort impact fréquemment et de manière prévisible, avec un travail minimal.

La Cloud Native Computing Foundation cherche à favoriser l’adoption de ce paradigme en favorisant et en préservant un écosystème de projets open source, indépendants du fournisseur. . Nous démocratisons les modèles de pointe pour rendre ces innovations accessibles à tous.

La ​​version abrégée indique que les applications natives en nuage constituent un ensemble de services sans état exécutés dans un environnement conteneurisé. De manière réaliste, cela signifie très probablement que les conteneurs Docker s'exécutent dans Kubernetes. Bien que le cloud native signifie généralement l'hébergement d'applications dans des conteneurs, les techniques décrites dans cet article s'appliquent également aux applications des services PAAS et aux solutions cloud sur site.

Un autre terme que vous pourriez rencontrer lorsque vous recherchez des applications natives en nuage est le concept d '" application à 12 facteurs ". Il s'agit d'une méthodologie d'application créée par les employés d'Heroku pour expliquer comment rendre les applications plus compatibles avec des services en nuage tels que Heroku. Bon nombre des principes de conception énoncés dans cet article sont basés sur 12 concepts de facteurs; mais lorsque le cadre à 12 facteurs est indépendant de la plate-forme, nous allons nous concentrer sur la mise en œuvre .NET de ces principes.

Why Bother

Le gros avantage du développement natif en nuage réside dans le fait que vous ne dépendez plus d'un hébergement spécifique. fournisseur. Si vous travaillez dans une grande entreprise, vous n'avez pas besoin d'attendre deux mois pour qu'une équipe d'infrastructure interne clique sur certains boutons. Si vous utilisez déjà un cloud public et que vous ne l'aimez pas, vous pouvez facilement passer à un autre. Votre application est portable, évolutive et facile à gérer. En suivant ces principes, vous pouvez obtenir l'infrastructure de votre application pour pouvoir vous concentrer sur la création de fonctionnalités pour les clients.

En outre, le respect des principes ci-dessous facilitera le déploiement de votre application. Même si vous n'allez pas dans le cloud, vous gagnez quand même. Des déploiements plus faciles signifient que vous pouvez aller plus vite, ce qui signifie que vous pouvez rentrer chez vous plus tôt. Plus de fonctionnalités en moins de temps sont valables pour tout le monde.

Principes de conception

Automatisez vos versions et vos versions

Si vous réalisez des versions et des versions manuelles de vos logiciels, prenez le temps de les automatiser – vous ne le regretterez pas. l'effort. Des outils tels que Azure DevOps facilitent l’assemblage de versions automatisées. Aucun projet en production ne devrait être dépourvu de processus de construction et de publication automatisé. Même les petits projets doivent être automatisés. L'automatisation est essentielle, en particulier lorsque vous adaptez votre application. De plus, assurez-vous que vos versions automatisées exécutent vos tests. Les tests automatisés vous permettent de déployer plus rapidement tout en maintenant la qualité du code.

Utilisation de .NET Core

Le .NET Core présente de nombreux avantages par rapport au .NET Framework complet. Il est plus léger, plus rapide, plus facile à utiliser et fonctionne multi-plateforme. Chaque nouvelle version de .NET Core prend en charge davantage d’API et de fonctionnalités .NET Framework complètes. Si vous construisez une application Web, vous devez choisir .NET Core par la suite.

Pour les applications en nuage, le fonctionnement multiplate-forme constitue un énorme avantage. Bien que vous puissiez exécuter des applications .NET Framework complètes dans des services PAAS tels qu'Azure Web Apps, la plupart des plateformes d'hébergement de conteneurs s'adressent à des conteneurs basés sur Linux. Même le service Azure Kubernetes n'exécute que des conteneurs Linux (à partir d'avril 2019, la prise en charge de Windows est en cours). Il est donc dans l’intérêt de devloper d’avoir une plateforme indépendante – .NET Core le permet.

Ne stockez pas la configuration dans votre application

La plupart des applications ont des paramètres configurables qui varient d’un environnement à l’autre. Celles-ci incluent les chaînes de connexion à la base de données, les clés de cryptage et les options. Il est généralement très déconseillé d'héberger des paramètres de configuration dans votre application même. L'enregistrement de secrets dans votre application est souvent considéré comme une invitation ouverte pour les pirates.

Il existe deux modèles d'application connexes – l'un est pire que l'autre. Dans certaines applications traditionnelles, les secrets des applications, tels que les clés de chiffrement, sont codés en dur dans l'application en tant que constante. Cette pratique est très précaire. Quiconque peut trouver votre code source ou décompiler vos fichiers binaires peut facilement voir ces champs et les exploiter.

Une autre pratique courante consiste à utiliser un fichier de configuration en texte clair pour stocker la configuration et les secrets de l'application. Beaucoup de gens le font, et bien que ce soit mieux que de stocker les paramètres de configuration en tant que constantes codées en dur, ce n’est pas une solution de configuration idéale. Cela est particulièrement vrai si vous avez un contrôle de source accessible au public. Il existe des scripts automatisés qui analysent GitHub à la recherche de clés API et d'autres secrets d'application. Vérifiez le mauvais paramètre de configuration et votre application est maintenant un mineur de crypto-monnaie.

Les développeurs devraient plutôt utiliser des variables d'environnement pour stocker les configurations d'applications. Les développeurs pourraient ensuite utiliser des outils de génération pour injecter ces paramètres dans des environnements lors du déploiement d'applications. L’un des avantages de .NET Core est qu’il n’ya aucune différence entre l’accès aux paramètres de configuration injectés à partir de l’environnement ou d’un fichier de configuration. Pour les applications locales, .NET Core contient un fichier de secrets d’utilisateur pouvant stocker les paramètres de configuration locaux. Les développeurs peuvent utiliser le fichier secret pour le développement local et créer des outils pour définir les variables d'environnement lors des déploiements.

Construire des services sans état

La plupart des applications basées sur un nuage sont distribuées sur un groupe de serveurs. Les développeurs doivent traiter ces serveurs comme des produits bon marché pouvant baisser à tout moment. Si vous utilisez Kubernetes, il construira et détruira les processus en cours à votre guise. Les développeurs doivent concevoir des applications en conséquence. Un moyen d'éviter les problèmes consiste à éviter de stocker l'état dans votre processus de candidature. Même si l’un de vos processus d’application est interrompu, un autre processus peut reprendre là où le processus mort s'est arrêté. Ne supposez jamais qu'un groupe de demandes d'utilisateurs sera traité par le même processus.

En .NET, cela signifie que vous évitez d'utiliser des fonctionnalités propres au serveur, telles que l'état de session et le cache en mémoire. Les deux fonctionnalités stockent des données d'état dans votre processus. En outre, les développeurs doivent éviter de stocker des fichiers sur le processus d'application du serveur exécuté. Il est conseillé d'utiliser un mécanisme de stockage externe, de préférence caché derrière une abstraction.

Dépendances d'infrastructure abstraites utilisant l'injection de dépendances

Lors de la création d'une application, vous devez résumer les dépendances à l'aide d'interfaces, puis injecter des implémentations concrètes dans votre application à l'aide de dépendances. injection. Cette pratique facilite non seulement le test unitaire de votre application, mais facilite également l’échange de dépendances d’infrastructure avec des versions en nuage à venir.

Les priorités élevées en matière d’abstraction incluent les bases de données, les magasins de fichiers, les mécanismes de cache et tout autre. stockage d'état. Les développeurs doivent extraire du code non lié à l'infrastructure pour rendre les tests unitaires plus faciles à gérer. mais si vous recherchez une compatibilité avec le cloud, résumez les dépendances de votre infrastructure.

Évitez les dépendances basées sur une machine

Les développeurs ne doivent pas stocker les bibliothèques d’applications à l’aide de mécanismes basés sur une machine, tels que le Global Application Cache (GAC). Utilisez plutôt les packages NuGet pour distribuer les bibliothèques partagées. En général, les développeurs doivent éviter toute installation sur machine, dans la mesure du possible. Si votre application nécessite un script PowerShell géant pour créer une structure de dossiers et des bibliothèques GAC à exécuter localement, cela signifie que vous devez effectuer des opérations de refactoring.

Travailler vers un avenir natif en nuage

Les modèles décrits dans cet article devraient aider les développeurs à créer des applications faciles à migrer vers le nuage. Même si vous n’utilisez pas le cloud, la plupart de ces pratiques encouragent la création de services sans état faciles à créer, à maintenir et à déployer. Si vous développez une nouvelle application greenfield, tenez compte de ces principes lorsque vous développez votre architecture. Évitez de créer une dette technique qui vous ralentira plus tard. Si vous travaillez sur une application existante, prenez le temps de la reformuler pour utiliser ces principes. Ensemble, c'est parti pour le cloud!