Derfor bruker han Microsoft Aspire
– Microsoft Aspire er et kraftig verktøy. Og man trenger ikke å svelge hele fisken, skriver Einar Ingebrigtsen.
Du har kanskje droppet mikrotjenester og gått for en modulær monolitt-løsning, eller aldri vært innom tanken om å gjøre mikrotjenester i det hele tatt.
Sansynligvis har du allikevel mer enn bare en ting i løsningen din, for eksempel flere infrastrukturelle deler som databaser, søke indekser eller en distribuert cache.
Kanskje du også har deler av løsningen som omhandler for eksempel integrasjoner med tredjeparts løsninger som du da har valgt å kjøre for seg selv.
Eller så har du mest sannsynlig en backend og en frontend som kjører hver for seg under utvikling.
Microsoft har jobbet med å lage utvikler vennlige verktøy for å løse ulike typer orkestrering i flere år. Det startet i sin tid med et open source eksperiment som het Project Tye, man høstet erfaringer fra dette og endte opp med et nytt prosjekt; Aspire.
Aspire representerer en “code-first” tilnærming til alt av ressurshåndtering og hele livs-syklusen for en løsning:
Lokal orkestrering
Pakketering av ressurser, typisk Docker (OCI) images
Provisjonere opp infrastruktur
Deploy av løsning
Monitorering av løsning
Lokal orkestrering
Med Aspire er alt som nevnt; “code-first”. Det betyr at det ikke er noen JSON eller YAML filer for å beskrive orkestreringen av de ulike komponentene løsningen består av.
Man trenger et nytt C# prosjekt som holder selve orkestreringen; Aspire AppHost prosjekt. I AppHost prosjektet benytter man seg av ny type applikasjons modell som kalles for DistributedApplication og det er fra denne man beskriver løsningen med alle tjenester og avhengigheter mellom tjenester samt nødvendig infrastruktur.
For .NET prosjekter legger man i AppHost prosjektet til referanser til disse og man kan benytte dem i beskrivelsen man gjør:
var builder = DistributedApplication.CreateBuilder(args);
var cache = builder.AddRedis("cache");
var apiService = builder.AddProject<Projects.AspireSample_ApiService>("apiservice");
builder.AddProject<Projects.AspireSample_Web>("webfrontend")
.WithExternalHttpEndpoints()
.WithReference(cache)
.WaitFor(cache)
.WithReference(apiService)
.WaitFor(apiService);
builder.Build().Run(); Ved å da gjøre `dotnet run`, så vil orkestreringen starte og Aspire sin dashboard hvor du kan lett se på ressursene, få tilgang til logger, metrics og traces.
For å komme i gang, har Microsoft laget en god quickstart.
Aspire kan kjøre mer enn .NET prosjekter, man kan f.eks. lett legge til det man omtaler som Node baserte løsninger enten det er backends eller frontends.
Integrasjoner
En av styrkene til Aspire er mengden med støttede integrasjoner.
Det finnes allerede et økosystem med opp mot 400 NuGet pakker som representerer ulike infrastruktur ressurs typer (PostgreSQL, Redis, RabbitMQ…).
I tillegg til ressurs typer finnes det også integrasjoner som er knyttet til provisjonering og deployment som f.eks. AWS støtte som ble vist på .NET Conf 2024.
Det er lagt til rette for å kunne lett lage dine egne integrasjoner og du kan kople deg på og ta del i deployment pipelinen.
Deployment verktøy
Hvis man er villig til å svelge hele fisken, så kan man la Aspire styre hele showet hele veien til deployment.
Dette kan gjøres enten ved å benytte seg av azd (Azure Developer CLI) hvis man er i Azure, eller for en Kubernetes deployment kan man benytte seg av Aspir8. Det er også for Aspire CLI en ny deploy command som er i preview.
Hvis man ønsker mer kontrol og bare ønsker at den skal generere nødvendig infrastruktur filer som f.eks. Bicep eller K8s helm charts kan man benytte seg av Aspire sin publish command.
Service Discovery
Når man lager løsninger som består av flere bevegelige deler og disse har behov for å snakke sammen, trenger man en måte å gjøre dette på som ikke er hardkodet.
Aspire bygger på toppen av .NET sin service discovery mekanisme og gjør dette transparent for deg som utvikler via automatisk generering av konfigurasjon som er eksponert som environment variabler. Dette plukkes i .NET automatisk opp.
Basert på avhengigheten mellom prosjekter vil da de ulike tjenestene bli konfigurert for service discovery, som vist nedenfor.
var builder = DistributedApplication.CreateBuilder(args);
var catalog = builder.AddProject<Projects.CatalogService>("catalog");
var basket = builder.AddProject<Projects.BasketService>("basket");
var frontend = builder.AddProject<Projects.MyFrontend>("frontend")
.WithReference(basket)
.WithReference(catalog); Man kan også gi eksplisitte navn på endepunktene og konfigurere base adresser som du kan lese mer om her.
Monitorering
Når man setter opp et Aspire prosjekt fra bunnen så får man i tillegg til AppHost prosjektet et prosjekt med boilerplate for å konfigurere opp OpenTelemetry riktig.
Ved å benytte dette er alt konfigurert riktig og vil fungere ut av boksen både lokalt og i produksjon. Man får logging, traces og metrics konfigurert og alt av data blir fanget opp. I lokal orkestrering vil du se alt i Aspire dashboardet.
Aspire dashboard kan også kjøres i produksjon for real time monitorering med å benytte en standalone container. Enda lettere er det hvis man kjører Azure Container apps hvor lett kan slå det på.
Viktig å merke seg at dataene ikke er lagret, så det er på ingen måte en erstatning for historiske data. Det er heller ikke meningen å være noen erstatning for eksisterende monitorerings løsninger, bare for typisk dev / test miljøer. Det er planlagt støtte for lagring av data, slik at dataene overlever restart. Det vil være en stor forbedring.
AI
Man kan jo ikke i 2025 skrive en artikkel uten å snuble innom AI.
Aspire er selvfølelig ikke unntatt AI. Og den kan være ganske nyttig.
Har man konfigurert Visual Studio eller VSCode med GitHub CoPilot og kjører løsningen, vil man se GitHub CoPilot-ikonet i Aspire dashboardet.
Fra her kan man stille spørsmål direkte om egen orkestrering og de ulike tjenestene som er der.
Testing
Det er ikke alltid enhetstestene dekker behovet for testing og man bør derfor også ha integrasjonstester.
Ofte benytter man kanskje ting som TestContainers for å sette opp miljøet man trenger å teste mot.
Med Aspire test prosjekt templatene jobber man direkte med Aspire orkestreringen og kan lettere komme i gang med testing som har infrastrukturen tilgjengelig.
Det er støtte for xUnit, MSTest og NUnit ut av boksen.
Konklusjon
Microsoft Aspire er et kraftig verktøy. Man trenger ikke å svelge hele fisken. Har man f.eks. allerede etablerte løsninger for deployment som man er fornøyd med, så benytter man ikke denne delen. Man får allikevel mye verdi bare med den lokale utvikler opplevelsen.
Men hvorfor ikke bare bruke Docker Compose? Et helt gyldig spørsmål å stille. Selvfølgelig kan man orkestrere alt med Docker Compose. Der kunne man f.eks. satt opp med egne dashboards som Jaeger eller Seq, eller hvis man liker godt Aspire sitt dashboard - bruke det direkte i Docker Compose.
Man kan f.eks. benytte seg av VSCode extensionen for Docker Compose og på den måten få en enkel måte å starte og stoppe individuelle services.
Hvis det er orkestrering man er ute etter, så gjør Docker Compose det helt fint. Men den gjør også kun det. Aspire leverer en helhetlig verdikjede og har fokus på utvikleropplevelsen hele veien.
Aspire er ikke for alle. Den har definitivt mange meninger som Microsoft har bygd inn. Og det er også her verdien ligger for mange. Hvis man kan leve med alle disse meningene vil man få mye verdi, raskere tilbake. Den gir en total opplevelse hvor du selv slipper å tenke så mye på limet, men bare heller fokusere på komponentene du bygger og dens avhengigheter.
Det at man i prinsippet kan orkestrere med vanlig kode er veldig kraftfullt og gir økt fleksibilitet og kan gi mer kontroll. Man trenger ikke å måtte forholde seg så mye til deklarative modeller med de begrensningene som følger.
Å kunne lettere reprodusere kjøremiljøet man f.eks. har i cloud uten å benytte cloud vil være med på å drive kostnadene ned. Litt for mange ganger syns jeg det virker unødvendig å bruke cloud ressurser mens man utvikler.
Min personlige preferanse er friheten til å kjøre alt lokalt, det gir meg en bedre feedback loop og offline muligheter, som har reddet meg mange ganger på pendlertoget. Med Aspire føler jeg at jeg lettere kan stole på at dette er tilfellet, spesielt hvis man svelger hele fisken.
Fremtiden for Aspire ser veldig spennende ut med enda flere ting som vil blant annet løfte utvikler opplevelsen enda mer og med flere deployment targets og bedre integrasjoner i GitHub Actions, Azure DevOps og GitLab.
