En introduktion til .NET Aspire

Hos cVation brænder vi for cloud-udvikling, og i løbet af de sidste 10 år har vi kanaliseret vores erfaring ind i vores Cloud Accelerated Development & Delivery (CADD) værktøjskasse. CADD sikrer best practices, kvalitet og ydeevne, når vi udvikler til cloud, og gør det muligt for os at fokusere på forretningsapplikationen tidligt i udviklingsfasen.

.NET Aspire

Med Microsofts egne ord er .NET Aspire “an opinionated, cloud ready stack for building observable, production ready, distributed applications”.

Hensigten er at simplificere og strømline måden hvorpå distribuerede applikationer bliver skabt og konfigureret, samtidig med at der tilbydes de features man vil forvente fra en moderne distribueret arkitektur, såsom logging, service discovery og health checks.

I de næste afsnit vil jeg vise nogle eksempler på hvad .NET Aspire tilbyder ved at dykke ned i Microsofts .NET Aspire Sample.

.NET Aspire Distributed App Host

.NET Aspire samplen indeholder to applikationer:

• Et ASP.NET API med et enkelt endpoint der producerer vejrdata.

• En frontend-applikation der benytter vejrdataen og viser den i en brugergrænseflade.

Applikationerne har en afhængighed, fordi frontenden skal kalde APIet for at hente vejrdataen. Desuden er denne sample konfigureret til at bruge Redis til at cache vejrdataen i stedet for at spørge hver gang. Så hvordan ved frontenden at APIet og cachen eksisterer? Og hvordan ved .NET Aspire, hvad der skal deployes?

Svaret på dette er hvad .NET Aspire kalder en distributed app host. Dette er et .NET-projekt, der er ansvarligt for at definere den overordnede arkitektur, herunder ressourcer og referencer imellem dem.

I det ovenstående billede definerer app hosten, at der i alt er tre ressourcer: To .NET-projekter og en Redis-komponent, hvor frontenden refererer til de to andre. Denne definition, også kendt som app-modellen, gør det klart, hvilke ressourcer der skal kommunikere med hinanden. Når .NET Aspire deployes til et cloud-miljø, bliver de nødvendige komponenter provisioneret, og connection strings og service bindings bliver automatisk konfigureret for de ressourcer der har brug for dem.

Bemærk også, hvordan Redis tilføjes ved blot at kalde en metode på builderen uden behov for at håndtere connection strings. Denne Redis-metode leveres af en NuGet-pakke, og Redis er blot en af ​​mange .NET Aspire-ressourcer, der er tilgængelige allerede i dag. Ved at tilføje Redis-ressourcen bliver den en del af det provisionerede miljø og tilgængelig for frontend-projektet, men for at kunne benytte cachen i koden i frontend-projektet refereres der også til en .NET Aspire-komponent i selve frontend-projektet.

.NET Aspire Komponenter

En .NET Aspire-komponent er en NuGet-pakke, som de individuelle applikationer inden for et .NET Aspire-projekt kan referere til for at strømline brugen og konfigurationen af almindelige cloud-tjenester.

I dette eksempel bliver Redis-komponenten refereret i frontend-projektet ved hjælp af samme ressource-id som defineret i app-modellen. Denne måde at specificere et ressource-id på er nyttig i situationer hvor en enkelt app-model bruger flere instanser af den samme cloud-tjeneste, f.eks. flere instanser af en cache.

Når man tilføjer en .NET Aspire-komponent bliver applikationen automatisk konfigureret med mange gode egenskaber:

• Den registrerer relevante tjenester, såsom SDK-klienter, ved hjælp af Dependency Injection. Hvis applikationen har brug for flere instanser, er det muligt at bruge .NET 8 Keyed Services.

• Den konfigurerer automatisk logging, tracing og telemetri.

• Den tilføjer flere typer af health checks for at kontrollere om appen kører, og om den er "sund".

• Den gør applikationen mere robust ved at konfigurere timeouts og retries.

• Den har et konsistent format til at konfigurere komponenten, hvor man f.eks. kan vælge om tracing er aktiveret. Det er muligt at definere konfiguration for flere applikationer på én gang et centralt sted ved hjælp af "Service Defaults".

Lokal Udvikling Med .NET Aspire

Når man kører .NET Aspire lokalt starter både alle applikationerne og der åbnes et .NET Aspire dashboard. Bemærk, at dette dashboard kun er tilgængeligt ved lokal udvikling og betragtes som et udviklingsværktøj.

Som det ses på dashboardet, kører der tre ressourcer: En Redis-cache indeni en Docker-container og to .NET-projekter.

Dashboardet giver også en masse anden nyttig information, såsom adgang til relevante URLer, logs og miljøvariabler, og det kan visualisere trace logging og derved skabe et bedre indblik i kommunikationen mellem applikationerne.

.NET Aspire Deployment

.NET Aspire er bygget på cloud-agnostiske teknologier og dikterer ikke hvor man skal deploye til. Hvis man gerne vil deploye til et miljø, der ikke er officielt supporteret, kan man generere en manifestfil, der beskriver app-modellen i detaljer, og bruge denne fil som grundlag for sin deployment.

I øjeblikket har .NET Aspire kun officiel support for deployments til Azure Container Apps ved hjælp af Azure Developer CLI, men de "forventer at antallet af miljøer, som Aspire kan deploye til, vil vokse over tid".

Det følgende billede viser de Azure-ressourcer, der bliver oprettet af denne .NET Aspire sample.

Afsluttende tanker

.NET Aspire hjælper udviklere med at bygge distribuerede applikationer på flere måder. Man kan definere sin app model meget kort og præcist, og sammen med komponentpakkerne, gør dette det nemt at beskrive ressourcer og referencer for de distribuerede applikationer. Den strømlinede tilgang til konfiguration forenkler tilføjelsen af nye komponenter og den lokale udvikleroplevelse forbedres af dashboardet. Hertil kommer at provisionering af et miljø baseret på Azure Container Apps er meget nemt.

Dog bør det også nævnes, at min erfaring med CADD-værktøjskassen fremhæver nogle områder, der potentielt kan forbedres endnu mere i fremtidige versioner af .NET Aspire:

I CADD-ækvivalenten af .NET Aspire-komponenter ledsages hver komponent af komponent-specifik test tooling. Dette kan bruges både i almindelige in-memory-tests og browserbaserede frontend-tests. .NET Aspire har ikke noget tilsvarende koncept, og dokumentationen nævner ikke noget om teststrategier.

Hvert projekt og miljø kan have behov for forskellig opsætning, og CADD-komponenterne tilbyder konfigurationsmuligheder for de deployede ressourcer, såsom at kunne reducere omkostninger ved at vælge forskellige SKUer. Det ligner ikke at .NET Aspire-komponenter tilbyder sådanne muligheder for konfiguration. Dog er det på grund af manifestfilen, og muligheden for at hente Bicep-filer ved hjælp af Azure Developer CLI, muligt at foretage manuelle ændringer i det deployede miljø.

En af fordelene for udviklingsteams, når de bygger en distribueret applikation, er evnen til at bygge, teste og deploye applikationer separat. CADD kan generere pipelines med separate job til hver individuel applikation og kan identificere, hvad der automatisk skal køres baseret på filændringer. Selvom .NET Aspire dokumenterer et eksempel på en pipeline, ved hjælp af Azure Developer CLI, nævnes det ikke om sådan en afkobling er mulig.

Jeg er meget spændt på at se, hvad fremtiden bringer for .NET Aspire.