> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/resilience-testing/chaos-engineering/use-chaos-engineering/infrastructure/types/ddcr-vs-dedicated.md).
# Delegate Versus Dedicated Chaos Infrastructure
This section compares the characteristics of Delegate-Driven Chaos Infrastructure and Dedicated chaos infrastructure (Legacy Kubernetes infrastructure).
| Harness Delegate-Driven Chaos Infrastructure or Runner (DDCR) | Dedicated Chaos Infrastructure |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Involves installing [**Delegates** ](/resilience-testing/chaos-engineering/use-chaos-engineering/infrastructure/types/ddcr.md#what-is-ddcr), a service used to connect to **artifact repositories, collaboration tools, verification systems**, and more. | Involves [setting up](/resilience-testing/chaos-engineering/use-chaos-engineering/infrastructure/types/legacy-infra/kubernetes.md) a separate, dedicated environment for running chaos experiments. |
| Leverages the **existing infrastructure**, allowing chaos experiments to be run without requiring a separate setup, eliminating the need of CRDs. | Requires CRDS and its own **resources** (servers, network configurations, etc.) that are **isolated** from the main application infrastructure. |
| Includes **automated Kubernetes service discovery** and workload analysis using a [**transient discovery agent** ](/resilience-testing/chaos-engineering/use-chaos-engineering/service-discovery.md#how-does-harness-ce-leverage-discovered-services). | N/A |
| Supports [**automated and guided application map creation** ](/resilience-testing/chaos-engineering/use-chaos-engineering/application-maps.md), representing a fully functional application within the cluster. | N/A |
| Enables [**chaos experiment auto-creation** ](/resilience-testing/chaos-engineering/use-chaos-engineering/infrastructure/infrastructures.md#auto-create-experiments)for a given [application map ](/harness-ai/use-harness-platform/application-map.md)based on the **workload specification and network traffic lineage**. | N/A |
| Provides **application-level and application map-level resilience scores**, giving a broader resilience assessment. | Provides **chaos experiment-level** resilience scores. |
| Seamlessly **integrates with the existing infrastructure**, avoiding additional setup. | Provides **complete isolation**, making it independent from the existing setup. |
| **Adaptable** for varying environments, making it easy to execute chaos experiments within **CI/CD pipelines**. | Requires **additional resources, setup, and time**, making it less adaptable for dynamic environments. |
| Enables fault execution on following platforms:
| Enables fault execution on following platforms:
|