ENTERPRISE Pattern 3 — Platform Team + Tenant Model

At 20+ developers across multiple teams, the medium pattern breaks down: teams fight over the charts/ directory, base charts accumulate too many feature flags, and onboarding a new team takes days. The enterprise pattern separates platform concerns from product concerns.

platform-infra/                         # owned by Platform Team
├── base-charts/                        # golden path charts (opinionated)
│   ├── web-service/                    # any HTTP service
│   ├── worker-service/                 # any background worker
│   ├── cronjob/                        # any scheduled task
│   └── postgres-instance/             # managed DB provisioning
│
├── platform/                           # cluster-level config
│   ├── clusters/
│   │   ├── prod-eu-west-1/
│   │   │   ├── platform-apps.yaml      # ArgoCD AppOfApps
│   │   │   └── cluster-config/
│   │   └── prod-us-east-1/
│   ├── addons/                         # cert-manager, external-dns, etc.
│   └── policies/                       # Kyverno/OPA baseline policies
│
└── tenants/                            # one directory per product team
    ├── team-payments/
    │   ├── namespace.yaml
    │   ├── rbac.yaml
    │   └── apps/
    │       ├── checkout-api.yaml       # ArgoCD Application
    │       └── payment-worker.yaml
    └── team-catalog/
        ├── namespace.yaml
        └── apps/

product-team-payments/                  # owned by Payments Team
├── services/
│   ├── checkout-api/
│   │   ├── src/
│   │   ├── Dockerfile
│   │   └── deploy/                     # THIS is all a product team owns
│   │       ├── values.yaml             # base values for their service
│   │       ├── values.dev.yaml
│   │       ├── values.staging.yaml
│   │       └── values.prod.yaml        # PR to this = prod deploy
│   └── payment-worker/
│       └── deploy/
└── .github/
    └── workflows/
        └── update-image-tag.yaml       # CI: PR to platform-infra on merge

The App-of-Apps pattern with ArgoCD

In large clusters, you don't want to manually create ArgoCD Application objects. The App-of-Apps pattern uses one root ArgoCD Application that watches a directory of other Application manifests and deploys them automatically — self-bootstrapping the entire cluster:

# platform/clusters/prod-eu-west-1/platform-apps.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: platform-apps
  namespace: argocd
  annotations:
    argocd.argoproj.io/sync-wave: "-1"   # deploy infra before apps
spec:
  source:
    repoURL: https://github.com/myorg/platform-infra
    path: tenants/                  # watches ALL team application files
    directory:
      recurse: true
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

📐 Naming Conventions — The Rules That Save You

Standard labels — always include these

# In every Deployment/Pod template (Helm helper or Kustomize commonLabels)
labels:
  app.kubernetes.io/name:       checkout-api
  app.kubernetes.io/instance:   checkout-api-prod   # Helm release name
  app.kubernetes.io/version:    v2.4.1              # image tag
  app.kubernetes.io/component:  api                 # api / worker / web
  app.kubernetes.io/part-of:    payments-platform  # owning system
  app.kubernetes.io/managed-by: Helm               # or Kustomize

MEDIUM Pattern 2 — Dedicated Infra Repo + Helm Charts

Once you have 3+ services and a real CI/CD pipeline, the manifests outgrow the app repo. A dedicated infrastructure repository becomes the single source of truth for what is deployed where. This is also the natural home for a GitOps controller like ArgoCD or Flux.

infra/                              # separate git repo: "my-org/infra"
├── charts/                         # Helm charts owned by this team
│   ├── frontend/
│   │   ├── Chart.yaml
│   │   ├── values.yaml             # defaults
│   │   └── templates/
│   ├── api/
│   │   ├── Chart.yaml
│   │   ├── values.yaml
│   │   └── templates/
│   └── database/
│       ├── Chart.yaml
│       └── templates/
│
├── environments/                   # what is deployed in each env
│   ├── dev/
│   │   ├── frontend.values.yaml    # dev-specific overrides
│   │   ├── api.values.yaml
│   │   └── argocd-apps.yaml        # ArgoCD Application manifests
│   ├── staging/
│   │   ├── frontend.values.yaml
│   │   └── api.values.yaml
│   └── prod/
│       ├── frontend.values.yaml
│       └── api.values.yaml
│
├── platform/                       # cluster-level resources
│   ├── namespaces.yaml
│   ├── rbac/
│   ├── network-policies/
│   └── monitoring/
│
└── scripts/
    └── deploy.sh                   # helm upgrade --install wrapper

Key discipline: values files are the interface

The chart (in charts/) is shared infrastructure. Each environment's *.values.yaml is what changes between environments. A PR changing a production value file is the deployment artifact — reviewable, auditable, rollbackable via git revert.

# environments/prod/api.values.yaml
replicaCount: 3
image:
  repository: ghcr.io/myorg/api
  tag: v2.4.1   # ← CI bumps this via PR on merge to main
resources:
  requests: { cpu: 200m, memory: 256Mi }
  limits:   { memory: 512Mi }
autoscaling:
  enabled: true
  minReplicas: 3
  maxReplicas: 20
ingress:
  host: api.example.com
env:
  LOG_LEVEL: warn
  DB_HOST:   postgres.production.svc.cluster.local

# environments/dev/api.values.yaml
replicaCount: 1
image:
  tag: main-abc123   # latest commit on main branch
resources:
  requests: { cpu: 50m, memory: 64Mi }
autoscaling:
  enabled: false
ingress:
  host: api.dev.example.com
env:
  LOG_LEVEL: debug
  DB_HOST:   postgres.dev.svc.cluster.local

ArgoCD Application per environment

# environments/prod/argocd-apps.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: api-prod
  namespace: argocd
spec:
  project: production
  source:
    repoURL: https://github.com/myorg/infra
    targetRevision: HEAD
    path: charts/api
    helm:
      valueFiles:
      - ../../environments/prod/api.values.yaml
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true   # revert manual kubectl changes

🧠 Knowledge Check