Difference compared to using same pattern with Fluxes Kustomization

[gitbluf]

Hello,

I was reading kraans documents and what I fail a bit to understand is what would be the bigger advantage with using Kraan compared to Kustomization?
An example, imagine this dir structrure:

.
├── apps
│   └── common
│       ├── helmrelease1.yaml
│       └── helmrelease2.yaml
├── clusters
│   ├── dev
│   │   └── common-ks.yaml
│   └── prod
└── infra
    └── common
        ├── helmrelease1.yaml
        └── helmrelease2.yaml

Where content of /clusters/dev/common-ks.yaml is:

---
apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
  name: apps-common
  namespace: flux-system
spec:
  interval: 10m0s
  dependsOn:
    - name: infra-common
  sourceRef:
    kind: GitRepository
    name: flux-system
  path: ./apps/common
  prune: true
  wait: true
  timeout: 5m0s
---
apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
  name: infra-common
  namespace: flux-system
spec:
  interval: 10m0s
  sourceRef:
    kind: GitRepository
    name: flux-system
  path: ./infra/common
  prune: true
  wait: true
  timeout: 5m0s

So besides versioning and conditional k8s version requirement I fail to see much of a difference between Kraan and approach from above?
Interested in the response :)

[nab-gha]

Agreed, one idea discussed early on was to implement this using the Kustomization controller and use Kubernetes jobs and the depends on facility of the Kustomization controller to gate on k8s version.

However when this project was started Flux2 was brand new and there was some concern among the project leadership about over reliance on unproven software. Also implementing this a controller was seen a a safer option in case other user requirements emerged that could not be addressed by Flux quickly enough to meet the business drivers behind the initial implementation.