An umbrella Helm chart bundles 14 services plus a third-party ingress-controller chart, and its 7-minute upgrade blocks every team. Which signals say split it?

### Read the symptom as a boundary mismatch A 7-minute upgrade that blocks everyone is not a Helm performance problem. It is the visible form of a design statement: this system's release boundary is fourteen services wide. Every signal below is a way of measuring how far that boundary has drifted from the ownership and lifecycle boundaries that actually exist. ### Signal 1 — deploy cadence has diverged The cheapest measurement is deploys per week per service against upgrades per week of the release. If catalog ships twenty-three times a week and the third-party ingress controller changes twice a quarter, they do not belong in one release. The cost is concrete: Helm takes a pessimistic lock on a release while an operation is in flight, and a second upgrade during that window is refused with "another operation (install/upgrade/rollback) is in progress". Add an explicit wait strategy — which you need if you want failures detected at all — and the lock is held for as long as the slowest workload in the umbrella takes to become ready. Every team pays the tail latency of the worst service in the bundle, twenty-three times a week. ### Signal 2 — blast radius crosses ownership When a bad change to the document-indexing job leaves the whole release `failed`, or when `--rollback-on-failure` reverts thirteen healthy services along with the broken one, the release is coupling teams who have no relationship to each other. The tell is cultural as much as technical: engineers start asking permission to deploy, or batching changes into a weekly "platform release", which is the org routing around the chart boundary. ### Signal 3 — the history stops answering questions `helm history` on a shared release is a merged log. With the default `--history-max` of 10, ten revisions may be a single afternoon of other teams' deploys, so the revision that predates your regression is already pruned. When "which revision was my service last good at?" is no longer answerable from the release record, the record has stopped being useful for the unit people actually reason about. ### Signal 4 — one version, many changes An umbrella publishes one chart `version`, so every change to any service bumps the parent and republishes it. Two consequences follow. The parent's `Chart.yaml` becomes a serialisation point where unrelated pull requests conflict and re-resolve dependencies against each other. And the published version number stops carrying meaning: 4.11.3 tells a reader nothing about which service changed, so nobody can look at a version and know what shipped. ### Signal 5 — a bundled component has a foreign lifecycle A third-party ingress-controller chart pulled from a public repository is the classic one. It is upgraded on the vendor's schedule, it is likely cluster-scoped, it usually ships CustomResourceDefinitions, and it may be a prerequisite for the very services sitting beside it in the umbrella. Bundling it means the vendor's upgrade becomes a release-wide event, and it means an emergency fix to your indexer re-renders and re-applies the ingress controller too. Anything that is shared infrastructure, cluster-scoped, or owned by somebody outside the team that owns the umbrella is a strong split candidate — it should be a release with its own cadence, and probably its own namespace and its own reviewers. ### Signal 6 — different environments want different subsets If staging installs eleven of the fourteen and production installs all of them, the umbrella is already being conditionally disassembled through values toggles. Conditional inclusion inside a parent chart is a way of expressing "these are not really one thing" in the most expensive available syntax. ### When to keep the umbrella The honest counter-case matters in an interview. Keep the umbrella when the set is genuinely one shippable product — something an external installer runs as a unit and versions as a unit; when a single team owns and on-calls all of it; when the components are meaningless apart; and for ephemeral stand-ups where a one-command install of a whole system is the entire point (CI environments, demos, per-branch preview stacks). Those are real, and "split everything always" is as unexamined as "one chart to rule them all". ### What splitting costs, so you can price it Saying "split it" without the bill is a weak answer. You lose the single command and the single rendered view, so something else must compose the releases — a pipeline, or a GitOps controller such as Argo CD or Flux, which then owns the ordering the umbrella used to imply. You lose the `global` values block as a single edit point and must replace it with a shared values file that something enforces. And the migration itself is not free: subchart resources carry the parent release's ownership metadata, so a new per-service release will refuse to adopt live objects until that metadata is corrected or the adoption is explicitly requested. Sequence it one service at a time, starting with the noisiest, and keep the umbrella shrinking rather than attempting a big-bang cutover.