Le but de cette série d’articles est de présenter les principes de la technologie .NET Aspire, au travers de la mise en place d’une application « cloud native », que nous commencerons par définir. 

Enjeu

Toute application « Cloud Native » doit répondre à 4 besoins principaux : 

Observabilité 

Dans un environnement d'exécution déporté dans le Cloud, une application observable permet aux Dévs et aux Ops de comprendre le comportement du système, de détecter au plus tôt d'éventuels problèmes, et d'aider à l'amélioration continue par la surveillance des performances du système. 

Pour cela, les outils principaux sont : 

• les logs, via les traces distribuées (cf https://learn.microsoft.com/en-us/dotnet/core/diagnostics/distributed-tracing), 

• la télémétrie, généralement via OpenTelemetry (cf https://github.com/open-telemetry/opentelemetry-dotnet/blob/main/src/OpenTelemetry.Api/README.md#introduction-to-opentelemetry-net-tracing-api). 

Résilience 

La résilience est la capacité du système à supporter les défaillances de ses ressources, qu'elles soient internes (BDD, Stockage, etc.) ou externes (API tierces, services de mail, etc.). 

Le pattern Retry (cf https://learn.microsoft.com/en-us/azure/architecture/patterns/retry) est typiquement utilisé pour mettre en œuvre ce besoin de résilience. 

Mise en échelle 

Une application « cloud native » doit être capable de supporter : 

• les montées en charge afin de répondre à des demandes volumineuses, qu'elles soient planifiées ou soudaines, 

• les descentes de charge lorsque les besoins de ressources diminuent, dans le but de maîtriser les coûts au plus juste. 

La mise en place de plusieurs instances (scaling horizontal), ou l'adaptation de la puissance (scaling vertical), sont les techniques permettant de répondre à ce besoin (cf https://learn.microsoft.com/en-us/azure/azure-monitor/autoscale/autoscale-overview#horizontal-vs-vertical-scaling). 

Évolutivité 

Au fil de la durée de vie de l'application, les besoins techniques sont susceptibles d'évoluer, de même que les besoins métier. Une application « cloud native » doit ainsi pouvoir être facilement déployable et extensible pour permettre à tout moment d'adapter son architecture à ces besoins. 

Quel socle technique utiliser ? 

Afin de répondre à toutes ces contraintes, le Développeur est confronté aux questions suivantes : Comment partir ? Sur quelle base technique ? Avec quelles briques logicielles ? 

Une solution : .NET Aspire 

Les avantages 

Microsoft a dévoilé lors de la .NET Conf 2023, en même temps que .NET 8, la technologie .NET Aspire. Celle-ci permet, au travers d’outils, de templates de projets et de packages NuGet : 

• de créer des applications « Cloud natives » en partant de zéro,  

• ou d’adapter une application existante afin de la rendre « Cloud-ready ». 

Grâce à ces outils, .NET Aspire donne aux Développeurs plusieurs avantages : 

• la garantie d’utiliser les bonnes pratiques d’observabilité, de résilience et d’évolutivité, que ce soit dans le code de l’application elle-même ou dans les packages tiers qu’elle utilise, 

• une base de code « clé-en-main » pour optimiser la productivité, 

• enfin, une garantie de facilité de mise en œuvre, car les blocs de base sont aisément adaptables et évolutifs. 

Blocs de base 

.NET Aspire s'appuie sur un ensemble de blocs pour le développement cloud natifs. 

Smart Defaults 

Intégré automatiquement dans une solution .NET Aspire, les « Smarts Defaults » (ou « valeurs par défaut intelligentes »… !) fournissent la configuration des services qui activent les bonnes pratiques telles que : 

• le Health Check : vérification automatisée de la santé de l'application et de ses ressources, 

• la Résilience : activation du mode Retry dans les appels HTTP, 

• l'Observabilité : activation des services de traces distribuées, et de télémétrie via OpenTelemetry. 

Après création d'un projet SmartDefaults, le code peut être modifié par le Développeur afin de brancher des services externes de type Azure Monitor, par exemple. 

Tableau de bord 

Fourni sous forme d'image Docker, le tableau de bord .NET Aspire permet aux Développeurs : 

• de visualiser l'état de fonctionnement des services,  

• De consulter les logs,

• De suivre les requêtes (HTTP ou gRPC),

• D'accéder aux données de télémétrie (mémoire, CPU, nombre de requêtes / seconde,…)

Concrètement, c'est un frontal Web qui collecte toutes ces informations au travers des protocoles gRPC et Open Telemetry (OTLP). 

Note : 

Ce tableau de bord peut également être lancé en mode autonome, en collectant les données de télémétrie externalisées par une application .NET existante. Le principe est illustré dans cet article : https://learn.microsoft.com/fr-fr/dotnet/core/diagnostics/observability-otlp-example. 

Orchestration 

Le noyau central d’une application .NET Aspire est l’orchestrateur, qui permet de lancer les différents composants de l’application (sites web, API, containers, etc.) à partir d’un projet nommé AppHost. 

Chaque élément de l’application est déclaré au sein de ce projet AppHost, et .NET Aspire permet de déclarer les interdépendances entre ces éléments afin d’assurer leur bon fonctionnement. 

Le code source d’un projet AppHost fournit une description claire de l’architecture d’une application distribuée construite avec .NET Aspire.  

Ainsi dans l’exemple ci-dessus : 

• l’application a 2 projets principaux nommés techd-aspire-api et techd-aspire-web, 

• l’application utilise un service externe nommé cache, 

• le projet techd-aspire-api référence le service cache pour ses besoins internes, 

• le projet techd-aspire-web référence le projet techd-aspire-api afin de l’invoquer. 

Découverte de services 

Le rôle de cet orchestrateur est aussi de fournir les éléments de configuration permettant aux différents composants de communiquer entre eux. Cela se fait au travers de chaînes de connexion, ou d'URL préformatées, permettant d'invoquer facilement tel ou tel service par son simple nom. 

Par exemple, l'URL invoquée par le site Web de notre exemple précédent est configurée ainsi : 

Packages d'intégration 

Les packages d'intégration sont des packages NuGet permettant facilement d'ajouter des services externes à une application .Net Aspire (ex : PostgreSQL, SQL Server, bus, cache Redis, OpenAI, etc.). 

Ces packages fournissent nativement les éléments de Health Check, de Résilience, de Télémétrie et d'Observabilité. Ils sont donc à utiliser sans modération ! 

La liste des packages d'intégration est disponible ici : https://learn.microsoft.com/fr-fr/dotnet/aspire/fundamentals/integrations-overview#official-integrations. 

Cette liste est déjà très large, et elle s'enrichit à chaque version de .NET Aspire ! 

Note : 

Le .Net Aspire Community Toolkit (cf https://learn.microsoft.com/fr-fr/dotnet/aspire/community-toolkit/overview) est une initiative OpenSource sous GitHub, qui a pour but de fournir des packages d'intégration et des méthodes d'extension supplémentaires pour .NET Aspire. 

Déploiement 

.NET Aspire s'appuie sur des outils de déploiement puissants et robustes, comme Azure Developer CLI (ou azd, cf https://learn.microsoft.com/fr-fr/azure/developer/azure-developer-cli/). Grâce à ces outils, il devient très facile de déployer en quelques lignes de commande l'application dans Azure (c'est la cible par défaut, par la mise en place d'un Azure Container App). 

La commande permettant de déployer entièrement l'application dans Azure est celle-ci : azd up 

La commande permettant de supprimer tout ce qui a été déployé est celle-ci : azd down 

L'idée est ainsi de fournir aux Développeurs un moyen de prototyper leur application dans un environnement proche ou identique à celui de la production, et facilement supprimable. 

Note : 

Si la cible de déploiement est un cluster Kubernetes, ou un DevContainer, un outil Open Source existe pour déployer une application .NET Aspire : c'est aspir8 (ou « aspirate » – cf https://github.com/prom3theu5/aspirational-manifests). 

Conclusion

Ceci termine notre présentation générale de .NET Aspire. 

La prochaine partie illustrera l’adaptation d’une application web avec son backend, avec un exemple concret.