1 Getting Started with Distributed Systems and Aspire

Running a distributed application is much harder than running a single app because its pieces must be started, configured, connected, and observed together. The chapter uses an online shop as the running example to show how a storefront, API, database, cache, broker, background services, and telemetry all cooperate as one system, even though they execute independently. It explains that Aspire helps .NET developers manage this complexity by giving them one place to model the whole system, launch its parts, debug them, and view logs, traces, health, and status in a shared dashboard.

The chapter then steps back to define what distributed systems are and why they are used. It contrasts distributed applications and microservices with monoliths and modular monoliths, noting that smaller services can improve deployment speed, scalability, flexibility, resilience, and maintainability, but they also add complexity, operational overhead, network-related failure modes, testing difficulty, performance cost, security concerns, and initial design effort. Orchestration is introduced as the coordination layer that handles deployment, scaling, load balancing, health monitoring, configuration, and resource allocation across those services, which is the role Aspire plays during local development.

Finally, the chapter introduces the Aspire starter project and shows how its main parts fit together: an AppHost orchestrator, a Blazor web frontend, an API service, and shared service defaults. It explains how the host registers projects, waits for dependencies, exposes only selected endpoints, and enables service discovery so the frontend can refer to the API by name instead of hardcoded address. It also outlines the shared defaults used for health checks, OpenTelemetry-based observability, and HTTP client resilience, setting up the foundation for the rest of the book’s gradual build-out toward a production-ready cloud application.

High-level overview of the system we are building

Example of a distributed application

Modular monolith structure

Orchestrated system

Hosting code and infrastructure components in the same Aspire process

The structure of the Aspire solution

Aspire dashboard

Aspire console log

Aspire Resources webfrontend link

Blazor app hosted in Aspire

• Aspire was created by Microsoft to make the process of developing distributed applications easy.
• Distributed applications are systems that consist of multiple independent services that interact with each other.
• Orchestration is the process of coordinating services inside a distributed system
• The main benefit of using Aspire is that it allows running and debugging a distributed application in a single process on a development machine, which substantially simplifies the development process
• Aspire consists of the Aspire Host project, which all other projects can connect to
• Different applications hosted by Aspire can pass each other’s references to each other when they are registered by the orchestrator
• The Service Defaults project is used for shared dependencies that any Aspire-hosted apps can use
• Service discovery allows for resolving addresses of Aspire-hosted apps via the names the apps were registered under in the orchestrator
• Aspire orchestrator displays a dashboard, which shows the status of all running services

FAQ