Cloud Distributed Apps and Aspire

Purpose

Distributed applications need repeatable local development, service discovery, configuration, telemetry and deployment patterns.

AIC may use .NET Aspire for distributed .NET applications where it improves developer productivity, observability and consistency.

When to Use Aspire

Use Aspire when a solution contains:

• multiple services

• APIs plus background workers

• databases and dependent infrastructure

• local container dependencies

• distributed tracing needs

• service discovery needs

• repeated developer setup pain

Avoid Aspire where:

• the solution is a simple single-process application

• customer hosting standards prohibit it

• the team cannot support the additional model

• the deployment target is not compatible with the approach

AIC Standard

Aspire MAY be used for:

• local orchestration

• service defaults

• telemetry defaults

• local dashboards

• integration environment modelling

• developer onboarding

Aspire usage MUST NOT hide production deployment reality. The production deployment model must still be documented and tested.

Distributed Application Rules

• Each service has a clear ownership boundary.

• Each service has independent health checks.

• Service-to-service calls have timeouts.

• Retries are bounded and safe.

• Idempotency is implemented for commands and integration messages.

• Logs, metrics and traces correlate across service boundaries.

• Configuration is environment-specific and validated.

• Secrets are externalised.

• Local orchestration mirrors production dependencies where practical.

Evidence

Retain:

• architecture diagram

• service dependency map

• local development instructions

• health check list

• telemetry configuration

• deployment model

• failure mode analysis