Skip to main content
This article compares CRDs and custom controllers (Operators), Argo Workflows, and Crossplane so platform teams can quickly pick the right automation engine for their problem. These technologies are common building blocks for Kubernetes-based automation and are often integrated with Git-based workflows. Instead of debating for weeks, use this practical decision framework to make a choice in minutes. We will:
  • Compare execution models and mental models for each tool.
  • Identify sweet spots and anti-patterns.
  • Match common problems to the right tool.
  • Show how multiple tools can be combined in a platform architecture.
A single right answer is rare — most real platforms combine tools. Start with diagnostic questions:
  • Is this a one-time task or continuous reconciliation?
  • Does it require complex, multi-step orchestration or simple steps?
  • Who will maintain the automation, and what languages are they comfortable with?
  • Is the primary goal provisioning cloud resources declaratively?
A slide titled "Platform Engineers Have Too Many Options" showing a toolbox list (Operators, Workflows, Crossplane, Tekton) on the left and a Kubernetes icon pointing to a Git logo on the right. Below the diagram are brief questions about reconciliation, provisioning, and maintenance.
Real example that motivates the decision framework
  • A consultancy implemented a 2,000-line Go Operator to provision developer environments. The operator watched a custom DevEnvironment CR and performed multiple tasks: create a namespace, configure RBAC, deploy monitoring, and set up DNS.
  • A colleague showed the same behavior could be implemented with Crossplane composition and a small function—about 80 lines of YAML. The operator’s continuous reconciliation was unnecessary because the workflow’s goal was “run to completion” (provision and leave) rather than long-term lifecycle management.
Takeaway: Ask the core diagnostic question first — is this run-to-completion (one-shot) or continuous reconciliation (lifecycle management)? Operators (custom controllers)
  • Mental model: always-on controllers that watch resources and continuously reconcile cluster or application state until it matches the desired state.
  • Use when:
    • The application or resource needs ongoing lifecycle management (backups, upgrades, scaling, failover).
    • Operational knowledge must be encoded (for example, orchestrating zero-downtime PostgreSQL upgrades).
    • You want “set-and-forget” automation that heals and enforces desired state continuously.
  • Avoid when:
    • The problem is a one-off, multi-step task that should run to completion and exit.
    • You prefer to avoid a language-specific implementation — operators are commonly written in Go (although SDKs exist).
  • Real-world examples: PostgreSQL operators, Redis/Kafka operators, Prometheus operator, cert-manager.
Argo Workflows — Complex task orchestration
  • Mental model: run-to-completion DAGs or step sequences. Execute tasks (containers, scripts) and exit when finished.
  • Use when:
    • You have complex multi-step jobs with dependencies and conditional logic (build -> test -> deploy).
    • You need parallelism (run multiple test suites or data transforms simultaneously).
    • Steps require retries with backoff and passing artifacts between steps.
  • Avoid when:
    • You need continuous reconciliation or drift correction — workflows do not watch resources after completion.
    • The task is a simple container run — a Kubernetes Job may be sufficient.
    • You are primarily provisioning cloud resources declaratively — Crossplane is a better fit.
A presentation slide titled "Argo Workflows – Complex Task Orchestration" that says it's best for multi-step jobs with dependencies, parallelism, and retries. It highlights three use cases in boxes: Data Pipelines, ML Training, and Batch Processing.
A presentation slide titled "Argo Workflows – Complex Task Orchestration" showing two columns labeled "Use When" and "Avoid When" with example criteria for when to use or avoid Argo Workflows. The slide is branded with a KodeKloud copyright.
Workflows are well-suited for many real-world pipelines:
A presentation slide titled "Argo Workflows – Complex Task Orchestration" showing a "Real-World Examples" box with five tiles: ML Training Pipelines, ETL Data Processing, Integration Test Suites, Nightly Builds, and Environment Provisioning Scripts.
Crossplane — declarative cloud resource provisioning
  • Mental model: treat cloud infrastructure as Kubernetes resources. Crossplane exposes cloud APIs through CRDs and continuously reconciles cloud state to match the declared configuration.
  • Use when:
    • You provision cloud resources (databases, VPCs, storage buckets, IAM roles).
    • You want Kubernetes-style declarative infrastructure and kubectl apply semantics.
    • You’re building self-service platform APIs: XRDs let developers request resources without learning cloud-specific APIs.
    • Continuous reconciliation and drift correction of cloud state is required.
  • Avoid when:
    • You need to run compute jobs or complex data pipelines — workflows are a better fit.
    • You need lifecycle management of stateful in-cluster applications — Operators are preferable.
    • You are building CI/CD pipelines — use Tekton or Argo CD for CI/CD workflows.
A presentation slide titled "Crossplane – Cloud Resource Provisioning" showing two columns: "Use When" listing scenarios to use Crossplane (provisioning cloud resources, Kubernetes-style declarative infra, self-service APIs, continuous reconciliation) and "Avoid When" listing cases to avoid it (running compute jobs, managing stateful apps, CI/CD pipelines).
A presentation slide titled "Crossplane — Cloud Resource Provisioning" showing four example boxes: Database-as-a-Service, VPC Provisioning, S3 Bucket Management, and IAM Role Automation. A footer notes Crossplane as "infrastructure as K8s resources" with continuous reconciliation of cloud state.
Decision framework (cheat sheet)
  • The execution model is the primary discriminator:
    • Operators and Crossplane: continuous reconciliation (long-lived controllers).
    • Workflows: run-to-completion (execute and exit).
  • Drift correction / continuous healing: Operators or Crossplane.
  • Complex DAG / multi-step logic: Workflows.
  • Stateful application lifecycle management: Operators.
  • Declarative cloud resource provisioning / self-service APIs: Crossplane.
  • For simple single-run tasks, prefer Kubernetes Jobs or lightweight scripts rather than a full workflow engine.
Comparison at a glance:
A slide titled "Decision Framework – Quick Reference" showing a comparison table of three approaches — Operators, Workflows, and Crossplane — against criteria like execution model, best use cases, complexity, multi-step logic, and drift correction. It summarizes which tool fits continuous loops, run-to-completion jobs, stateful apps, cloud resources, and their relative complexity.
How these tools complement each other (layered responsibilities)
  • Infrastructure layer: Crossplane for cloud resources (RDS, VPCs, S3 buckets).
  • Orchestration layer: Argo Workflows for pipelines, ETL, model training, and complex release gating.
  • Runtime management: Operators for stateful application lifecycle operations and in-cluster self-healing.
  • Deployment / GitOps: Argo CD for continuous delivery and Tekton for CI/build tasks.
Examples of combined architectures
  • Database-as-a-Service: Crossplane provisions the RDS instance; a PostgreSQL Operator manages backups, failover, and schema migrations.
  • ML platform: Crossplane provisions GPU nodes and object storage; Argo Workflows runs data fetch, training, evaluation, and model upload; Operators manage long-running model-serving instances.
  • Self-service infra via GitOps: Argo Events detects a PR; Argo Workflows runs validations; a successful workflow triggers Crossplane to provision requested infrastructure; Argo CD ensures manifests are continuously deployed.
Use the execution model as your first filter: if automation must continuously watch and heal state, prefer Operators or Crossplane. If automation is a complex job that runs to completion, prefer Workflows. Then apply secondary criteria: complexity, maintainability, team language preference, and long-term support.
Key takeaways
  • Operators: best for managed, stateful applications that require continuous lifecycle operations and drift correction.
  • Workflows (Argo Workflows): best for complex multi-step jobs, DAGs, parallelism, and artifact passing — these run to completion.
  • Crossplane: best for declarative cloud resource provisioning and building self-service platform APIs that need continuous reconciliation.
  • Most platforms combine tools: think in layers (infrastructure, orchestration, runtime, deployment) and choose the right tool for each layer.
Links and references

Watch Video