A customer action starts in one application, calls another service, waits for a database and finally asks a provider to send a message. When it fails, everybody involved can produce a log showing that they were mostly fine.
It’s a bit like organizing a group trip where each person has booked a perfectly valid ticket to a slightly different airport.
Before adding another cloud service, I would like a clearer picture of the journey already in place.
.NET Aspire reached general availability at Microsoft Build in May 2024.1 Its tools for application composition, dependencies and diagnostics make this a useful moment to discuss that clarity. Adopting it should follow the needs of the application, rather than become a reason to distribute more things.
Start with a journey the business recognizes
Choose one task, such as submitting an order or preparing an account export. Record the services it relies on and the result that counts as finished.
For that journey, the team should be able to explain:
- Which application owns the business change.
- Which dependencies it calls and how they are configured.
- What a healthy response means for each dependency.
- How one request can be followed across those calls.
- What happens when a step fails or takes too long.
That modest inventory can reveal more than another impressive infrastructure diagram.
Give dependencies names people can follow
Service discovery helps applications locate dependencies through logical names and configured addresses. The benefit is reducing scattered assumptions about where another component lives.
It doesn’t remove environment-specific configuration. Development, staging and production can still have different addresses, credentials and deployment arrangements.
Aspire’s original preview introduced an approach to composing local resources and supplying shared service defaults. Its general availability expands the case for evaluating that developer experience.
The review should include whether another team member can start the application and understand its dependencies without receiving several connection strings through an archaeological search of chat history.
This is the kind of problem our custom development team enjoys.
Ask what each health check really checks
A running process may answer a basic health endpoint while being unable to reach a required database. A dependency might be available but returning the wrong business result.
Name the purpose of each check. Some establish that a process is alive. Others can examine readiness or particular dependencies.
Do not make a dashboard promise more than the checks establish. Five green indicators don’t necessarily mean an order can complete. The instruments can all be switched on while the orchestra is still looking for its conductor.
Pick checks that support useful operating decisions, and understand their cost and failure behavior.
Follow the delay across the boundaries
Distributed tracing connects related work across components. Rather than searching several logs independently, the team can inspect the parts of a request and where time was spent.
Milan Jovanovic’s OpenTelemetry walkthrough explains how instrumentation can collect and export those traces in a .NET application.3 OpenTelemetry also supports a broader set of telemetry signals; it is not itself the storage and review interface for every deployment.
Carry the context far enough to explain the outcome
Automatic instrumentation can capture important calls, but business-specific work may need additional context. Use identifiers that connect the evidence without placing unnecessary sensitive data in telemetry.
A queue or asynchronous handoff may extend the process beyond the original page response. The diagnostic story should still help explain what completed and what remains outstanding.
For an export, a quick page response means little if the background preparation never finishes. Trace the task people care about, not only the part that returns an HTTP status.
Sampling and retention also need thought. Collecting more information is useful only when the team can afford, secure and interpret it.
If this was useful, try Your cloud provider has an incident. Who owns the next hour?
Choose the tool and the operating agreement together
Aspire’s consolidated developer dashboard can help make resources, logs and traces understandable. That does not replace deciding how production monitoring, access, alerting and retention will work.
Evaluate it with one representative application. Check the deployment fit, team familiarity and existing tools. A simpler application may benefit from improved instrumentation without adopting every part of a new stack.
Someone needs to own the resulting evidence. Agree which symptoms require attention and who investigates. Otherwise, a beautiful dashboard becomes a very sophisticated way to discover that nobody was looking.
The outcome I’d value is modest and concrete: a developer can trace an ordinary task, a failure can be located and staff can learn whether work is complete.
Then, when another service has a genuine job to do, it can join a journey the team already understands. Preferably through the same airport.