Chris Ayers

Principal Software Engineer
Azure EngOps AzRel
Microsoft

BlueSky: @chris-ayers.com
LinkedIn: - chris-l-ayers
Blog: https://chris-ayers.com/
GitHub: Codebytes
Mastodon: @Chrisayers@hachyderm.io

The Polyglot Problem

Modern apps are a big city without a map — and for polyglot teams,
the streets are in five different languages.

Your team doesn't use one language — it uses five.

Your stack today

• Python ML services
• Go microservices
• Java Spring Boot APIs
• TypeScript/React frontends
• .NET backend APIs

The question: How do you orchestrate, observe, and wire all of this from one place?

Your Stack in One File

One C# AppHost wires Python, React, and .NET — auto-discovery, observability, lifecycle:

var builder = DistributedApplication.CreateBuilder(args);

var redis = builder.AddRedis("cache");
var postgres = builder.AddPostgres("db")
                      .AddDatabase("appdata");

builder.AddUvicornApp("ml-service", "../python", "main:app")
       .WithUv()
       .WithReference(redis);

builder.AddViteApp("frontend", "../react")
       .WithHttpEndpoint(env: "PORT")
       .WithReference(postgres);

builder.AddProject<Projects.Api>("api")
       .WithReference(redis)
       .WithReference(postgres);

builder.Build().Run();

Standalone Dashboard — No AppHost Required

Already on OTEL? Get the dashboard with zero rewrites.

The Aspire Dashboard ships as a standalone container. Point any OTLP-emitting app at it and you get logs, traces, and metrics — no AppHost, no .NET, no commitment.

• Node.js / Python / Java / Go / Rust — anything with an OTEL SDK works
• Same UI as the AppHost-managed dashboard
• Local-only by default — OTLP endpoint and dashboard auth keys printed at startup
• Use it in CI, in a Dockerfile, in docker-compose.yml, or attached to a Kubernetes pod

docker run --rm -it -p 18888:18888 -p 4317:18889 \
  -d --name aspire-dashboard \
  mcr.microsoft.com/dotnet/aspire-dashboard:latest

Open http://localhost:18888 — done.

Wire Any OTEL App in 30 Seconds

Point your Node.js app at the standalone dashboard:

// otel.js
import { NodeSDK } from "@opentelemetry/sdk-node";
import {
  OTLPTraceExporter
} from "@opentelemetry/exporter-trace-otlp-grpc";

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({
    url: "http://localhost:4317"
  })
});
sdk.start();

Migration path: start with the standalone dashboard for observability today; adopt the AppHost later when you want service discovery, integrations, and aspire deploy.

OpenTelemetry — Python

Wire OTEL once. Aspire injects OTEL_EXPORTER_OTLP_ENDPOINT automatically.

from opentelemetry import trace
from opentelemetry.exporter.otlp.proto.grpc \
  .trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export \
  import BatchSpanProcessor

provider = TracerProvider()
provider.add_span_processor(
  BatchSpanProcessor(OTLPSpanExporter(
    endpoint=os.environ.get(
      'OTEL_EXPORTER_OTLP_ENDPOINT')
  ))
)
trace.set_tracer_provider(provider)

One block of boilerplate — and your Python service is in the dashboard.

OpenTelemetry — Node.js

Same idea, different runtime — and you get auto-instrumentation for free.

const { NodeSDK } =
  require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } =
  require('@opentelemetry/auto-instrumentations-node');
const { OTLPTraceExporter } =
  require('@opentelemetry/exporter-trace-otlp-grpc');

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({
    url: process.env.OTEL_EXPORTER_OTLP_ENDPOINT
  }),
  instrumentations: [getNodeAutoInstrumentations()]
});
sdk.start();

Auto-instrumentations capture Express, Fastify, fetch, pg, redis — without code changes.

Service Discovery — The Pattern

Aspire injects service endpoints as environment variables:

# Pattern: services__<name>__<protocol>__<index>
services__api__http__0=http://localhost:5000
services__frontend__http__0=http://localhost:3000

Why double underscore? Env vars can't have colons — so __ stands in for the path separator. Every language can read env vars; that's the universal interface.

No hardcoded URLs. No .env files. Aspire wires it.

Service Discovery — Read It Anywhere

Same env-var pattern, every language:

api_url = os.environ['services__api__http__0']
requests.get(f'{api_url}/data')

apiURL := os.Getenv("services__api__http__0")

const apiUrl = process.env['services__api__http__0'];
await fetch(`${apiUrl}/data`);

String apiUrl = System.getenv("services__api__http__0");

Connection Strings — The Pattern

Infrastructure resources get connection strings as environment variables:

# Pattern: CONNECTIONSTRINGS__<resource>
CONNECTIONSTRINGS__cache=localhost:6379
CONNECTIONSTRINGS__db=Host=localhost;Port=5432;Username=postgres;Password=...
CONNECTIONSTRINGS__messaging=localhost:9092

Python — Redis:

client = redis.from_url(
  f"redis://{os.environ['CONNECTIONSTRINGS__cache']}"
)

Aspire injects the env var — your service reads it using its language's standard mechanism.

Same Pattern, Every Language

Node.js — Kafka:

const kafka = new Kafka({
  brokers: [process.env.CONNECTIONSTRINGS__messaging]
});

Java — PostgreSQL:

String url = "jdbc:postgresql://"
  + System.getenv("PG_HOST") + ":"
  + System.getenv("PG_PORT") + "/"
  + System.getenv("PG_DB");

Go, Rust, .NET, PowerShell — same pattern. Aspire sets the env var; your code reads it.

The AppHost — C#

Write your AppHost in the language your team knows. Here's C#:

var builder = DistributedApplication
    .CreateBuilder(args);

var redis = builder.AddRedis("cache");

builder.AddPythonApp("api", "../api", "app.py")
       .WithReference(redis)
       .WithHttpEndpoint(env: "PORT");

builder.Build().Run();

40+ integrations — Redis, Azure, Kafka, MongoDB, PostgreSQL — available out of the box.

The AppHost — TypeScript

Same model, different syntax. Best fit for Node.js / TS workspaces:

const builder = await createBuilder();

const redis = await builder.addRedis("cache");

await builder
  .addPythonApp("api", "../api", "app.py")
  .withReference(redis)
  .withHttpEndpoint({ env: "PORT" });

await builder.build().run();

Same 40+ integrations as C# — auto-generated via [AspireExport] attributes. A JS/TS team never needs to touch .NET.

Two AppHost Languages

Author your AppHost in C# or TypeScript today — both officially supported.

C# (.NET) — AppHost.cs — best fit for teams already on .NET tooling.

TypeScript — apphost.ts — best fit for Node.js / TypeScript workspaces.

Same model, different syntax. Both produce the same dashboard, service discovery, health checks, and deployment artifacts.

Same integration surface — the TypeScript SDK is auto-generated from the same .NET hosting integrations via the Aspire Type System (ATS). No separate integration code to maintain.

Write Once with ATS

Author the integration in C#. Use it from any AppHost.

Aspire Type System (ATS) — the contract that bridges .NET and guest languages.

• Author your hosting integration in C# as you always have
• Annotate exported APIs with ATS attributes — [AspireExport], [AspireExportType], [AspireExportMethod]
• Aspire's analyzer validates the export shape at build time

[AspireExport]
public static class MyIntegrationExtensions
{
    [AspireExportMethod]
    public static IResourceBuilder<MyResource>
        AddMyService(
            this IDistributedApplicationBuilder builder,
            string name) { ... }
}

Use From TypeScript — Zero Bindings

The CLI auto-generates a TypeScript SDK into .modules/ when a TS AppHost runs aspire add <your-package>. TypeScript callers get fluent, typed methods.

import { createBuilder } from "./.modules/aspire.js";
import { addMyService } from
    "./.modules/my-integration.js";

const builder = await createBuilder();
const svc = await addMyService(builder, "svc");

The trade-off: the guest process talks to the .NET host over a local JSON-RPC socket (Unix socket / named pipe), authenticated with a per-session token. One IPC hop, no port exposure, no duplicated integration code per language.

Status: preview feature in 13.x.

Cheat Sheet — Common Patterns

Chainable methods you'll use everywhere:

.WithReference(redis)              // wire endpoints
.WaitFor(postgres)                 // start ordering
.WithHttpEndpoint(env: "PORT")     // expose http
.WithExternalHttpEndpoints()       // public ingress
.WithUv()                          // python: uv
.WithNpm() / .WithBun()            // js: package mgr
.WithBuildSecret("key", secret)    // build-time secret
.WithRunScript("dev")              // npm script
.WithHttpHealthCheck("/health")    // probe
.WithMcpServer("mcp")              // expose MCP

aspire.config.json — The File

This file tells the CLI which language your AppHost uses.

{
  "appHost": {
    "path": "apphost.py",
    "language": "python"
  },
  "sdk": { "version": "13.2.0" },
  "channel": "stable",
  "features": {
    "polyglotSupportEnabled": true
  },
  "profiles": {
    "default": {
      "applicationUrl": "https://localhost:17000"
    }
  }
}

Manage Config From the CLI

No manual JSON editing required:

# Read & write config values
aspire config list
aspire config get <key>
aspire config set <key> <value>

# Manage secrets (encrypted at rest)
aspire secret set <key> <value>
aspire secret list / get / delete

# Local dev certs
aspire certs clean
aspire certs trust

Every sample in this talk has an aspire.config.json at its root — peek inside.

Getting Started

No .NET SDK required — get.aspire.dev

curl -sSL https://aspire.dev/install.sh | bash
aspire new aspire-py-starter -n my-app
aspire new aspire-ts-starter -n my-app
aspire new aspire-starter -n my-app
cd my-app && aspire run

aspire run / aspire start    # Run / background
aspire ps / aspire stop      # List / stop
aspire describe --follow     # Watch resources
aspire doctor                # Environment check
aspire otel / aspire logs    # Telemetry & logs
aspire export                # Capture to zip

Wire It Up in 30 Seconds

One-time setup, then any MCP-aware agent works:

# 1. One-time setup in your AppHost dir
$ aspire agent init
   Aspire skill file       (recommended)
   Aspire MCP server
   Playwright CLI

# 2. Start your stack, open your agent
$ aspire run
$ claude    # reads .mcp.json
$ code .    # reads .vscode/mcp.json

// .vscode/mcp.json (auto-generated)
{ "servers": { "aspire": {
    "type": "stdio",
    "command": "aspire",
    "args": ["agent", "mcp"]
} } }

Same Model, Two Commands

One AppHost. Local, staging, production.

aspire run       # Local development
aspire deploy    # Deploy to target  (Preview)
aspire publish   # Generate artifacts (Preview)
aspire do        # Pipeline step      (Preview)

What Aspire generates from your AppHost:

• Container images for all languages
• Azure Container Apps / Kubernetes manifests
• Infrastructure wiring (Redis, Postgres, Kafka…)
• Service connections + environment variables

No separate deploy config. The AppHost is the contract.

What That Looks Like

 redis (cache)         healthy   :6379
 postgres (db)         healthy   :5432
 ml-service (python)   running   :8000
 frontend (vite)       running   :5173
 api (.net)            running   :8080

Dashboard: http://localhost:15888

→ Building images for python, node, .net
→ Pushing to acrcdbytes.azurecr.io
→ Provisioning Container Apps environment
→ Wiring Postgres + Redis connection strings
 Deployed to dev environment in 4m 12s

Same code-first AppHost drives both.

Key Takeaways

One orchestrator for every language — Define your entire stack in one AppHost file, regardless of runtime

Unified observability out of the box — One dashboard for logs, traces, and metrics across all services via OpenTelemetry

From local dev to production — Same model, same CLI, same config — aspire run to aspire deploy

Resources

Questions?