Resiliency builder
Building reliable distributed applications requires effectively managing failures, timeouts, and service degradation. Conductor’s Resiliency Builder simplifies this process with a visual interface for defining Dapr Resiliency policies including timeout, retry, and circuit breaker configurations, generating validated YAML files.
Key features include:
- Error prevention: Parameter validation and auto-completion for namespaces, apps, components, and actor names reduces mistakes.
- Guided configuration: Field dependency guidance and support for complex policy combinations ensures correctness.
- In-app docs: Comprehensive documentation for each field, including formats and allowed values.
- Customization: Easily override Dapr's default retry policies.
Setting Context
The first step in creating a resiliency policy is configuring its context and scope. Access the Resiliency Builder through the Conductor side menu and enter a unique name for your policy. Optionally select a cluster context, which enables you to scope the policy to specific namespaces and applications within that connected cluster.
Selecting a cluster context gives you access to automatically use resources within that cluster in the resiliency policy, rather than typing them manually. Resources include:
- Available namespaces
- Deployed applications
- Component configurations
- Actor types
Create policy types
The Resiliency Builder supports creating all three types of policies available in Dapr:
- Retries
- Timeouts
- Circuit breakers
Timeout policies
Timeout policies prevent system bottlenecks by terminating long-running operations that exceed specified durations. For example, if a service responds within 200 ms, you might set a timeout of 500 ms to account for occasional delays while preventing indefinite waits.
Retry policies
Retry policies help applications recover from transient failures by automatically retrying failed operations. These policies support various strategies including fixed intervals, incremental delays, and exponential backoff.
See the below example for how to configure a retry policy that will retry forever, using a constant backoff stretegy and a 5 second time interval between retries:
Circuit breaker policies
Circuit breakers monitor request patterns and automatically stop traffic to failing services. This prevention mechanism gives services time to recover instead of being overwhelmed with requests. Circuit breakers operate in three states:
Configure targets
A policy gets activated when the scoped application interacts with the specified target. The Resiliency Builder supports three types of targets:
- Apps
- Components
- Actors
App targets
App targets apply policies to service invocation calls between Dapr applications. These policies activate automatically when communication issues occur between Dapr sidecars. Each target is linked to specific app-ids, ensuring precise policy application.
Component targets
Component targets manage resilience for both inbound and outbound component operations. This includes state management, pub/sub messaging, and other operations that involve backing infrastructure. Policies are linked to component names and can handle both calls from your application to the Dapr sidecar and vice versa.
Actor targets
Actor targets apply policies to actor operations, with additional configuration options for circuit breaker scope and cache size. These settings help manage the stateful nature of actors and their unique lifecycle requirements.
Preview and download
When you are done configuring your policy, the Resiliency Builder generates the desired YAML file containing all the policies, targets and scopes. Review, and if necessary edit this file before downloading it. If you manually edit the YAML file, then you will be prevented from making further changes through the builder interface.
Conductor will not apply the manifest to your Kubernetes cluster.
To apply the policy to your cluster, use the kubectl command:
kubectl apply -f dapr-resiliency.yaml