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 , a service used to connect to artifact repositories, collaboration tools, verification systems, and more. | Involves setting up 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 . | N/A |
| Supports automated and guided application map creation , representing a fully functional application within the cluster. | N/A |
| Enables chaos experiment auto-creation for a given application map 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: |