Earn your complexity
2 minread
Somewhere right now, an ArgoCD instance is reconciling three deployments on a single cluster, and the engineer who installed it left the company in March.
ArgoCD and Flux are good tools. They solve drift across fleets of clusters, many teams, and more environments than anyone can keep in their head. If your platform fits in one person's head and your team fits in one Slack channel, you don't have that problem yet. A CI job running helm upgrade from the same repo gives you the same Git history and the same rollback, without another controller to patch, another set of CRDs to learn, or another thing to page you at 2am. kubectl apply was right there.
It doesn't stop at deployment. Crossplane is excellent when a platform team offers self-service infrastructure to dozens of product teams through one API. If you're three engineers with one Terraform repo, all it does is make your cloud depend on your cluster. And if that cluster runs on the cloud resources Crossplane manages, it's now a circular dependency with a YAML interface. Good luck reconciling the reconciler when the cluster is down. The same pattern repeats across the stack: Istio for four services, Backstage for a team that already knows each other's names, Vault for five secrets. Each tool is right somewhere. The question is whether that somewhere is you.
AI has made this worse, quietly. Ask an assistant how to deploy to Kubernetes and you get the reference architecture of a company a hundred times your size: GitOps controllers, Crossplane compositions, a service mesh, progressive delivery. None of it is wrong. It just answers a bigger question than the one you asked, and it looks great in a design review. It's résumé-driven development with a very fast typist.2 Nobody wants to be the person who asks "do we actually need this?", because the question sounds less clever than the diagram.
That question is the job. Gall's law says every complex system that works grew out of a simple system that worked.1 A chatbot drawing the complex version for you doesn't let you skip the simple one. Every component you add is something you run, upgrade, secure, debug, and eventually explain to whoever inherits it.45 Clever stacks get built on good days and debugged on bad ones.3
A complex system that works is invariably found to have evolved from a simple system that worked.
My test is simple. Name the failure this tool prevents. Has it happened to you, or is it realistically about to? If you can't answer, you're paying an operational tax for a line on your CV.
None of this is an argument against GitOps, Crossplane or AI. Adopt a tool when you hit the problem it solves, not when the output looks impressive. When a sophisticated answer costs nothing to generate, the scarce skill is knowing which one you need.
References
- 1.John Gall, Systemantics: How Systems Really Work and How They Fail. 1975, p. 71.↩Gall's law
- 2.Jonas Fritzsch, Marvin Wyrich, Justus Bogner and Stefan Wagner, Résumé-Driven Development: A Definition and Empirical Characterization. ICSE SEIS, 2021.↩Résumé-driven development, studied rather than joked about
- 3.Brian W. Kernighan and P. J. Plauger, The Elements of Programming Style. 2nd edition, McGraw-Hill, 1978.↩Debugging is twice as hard as writing the code: clever stacks get debugged on bad days
- 4.Dan McKinley, Choose Boring Technology. 2015.↩Innovation tokens: every new component spends one
- 5.Max Luebbe, Simplicity. Site Reliability Engineering, O'Reilly, 2016, ch. 9.↩Essential and accidental complexity, from Google's SRE book