Recent Posts

There are many different approaches to software development. In the earliest days, there was the “Test Last” or “Code First” approach. A business analyst would work with the client to develop requirements. Once all the requirements were gathered, they would pass them to the developers, who would write the application from beginning to end. The “finished” product would be handed back to the client, or maybe to a QA team for testing (if there was a big enough budget). That testing was usually manual, and slow, and it depended on whomever was selected for testing understanding the product and what it was supposed to do, which they often really didn’t. Sometimes, the process worked. Often, it didn’t. Features and edge cases would often be missed. Critical business logic would be incorrect. The end product was often nothing like the client envisioned, or wanted. Sometimes, if there was a big enough budget available, there would be iterations to fix some of the more egregious issues. But often they would have to make do with the result.

Aspire has basic support for OpenTelemetry out of the box. But what about when we're ready to do more.

While reactive strategies respond to failures after they occur, proactive strategies prevent problems before they happen. In this post, we'll explore the two essential proactive strategies: Timeout and Rate Limiter. The Rate Limiter strategy is particularly versatile, offering both traditional rate limiting (controlling requests over time) and concurrency limiting (controlling simultaneous operations). Together, these strategies help you constrain resource usage and execution time to keep your applications stable and performant.

Explore the real limits of LLM context windows, why infinite growth is impractical, and how to build scalable AI solutions using retrieval, summarization, and memory systems.

Polly provides several reactive resilience strategies that respond to failures as they occur. In this post, we'll explore four essential reactive strategies: Retry, Circuit Breaker, Fallback, and Hedging. Each addresses different failure scenarios and can be combined to create robust resilience pipelines.

It's inevitable that production will fail. Your ability to respond quickly greatly depends on being able to determine what went wrong.

Adding observability to Polly resilience pipelines involves configuring TelemetryOptions for logging, customizing severity levels for resilience events, integrating OpenTelemetry to export metrics to monitoring dashboards, and creating custom MeteringEnricher classes for contextual data. This provides crucial insights into how applications handle service failures and enables data-driven optimization of resilience strategies.

Learn how to create a GitHub template repository with boilerplate files for .NET 10 applications optimized for AI coding agents.

Sometimes it can be really useful to add commands to your Aspire dashboard. It's easy to do and amazingly useful.

One of the greatest features of Aspire is how easy it is to set up, configure, and work with databases.