Ranking My Most Unpopular DevOps Opinions

Ranked by how much argument each one starts, not by how sure I am. Every entry gets the strongest counterargument I know, because an opinion you cannot argue against is a slogan. Confidence ratings are my own and calibrated to how often I have been wrong about that specific thing.

1. Most teams running Kubernetes should not be

Confidence: high. The typical case is a three-node managed cluster running four services that would fit on one machine. What you have bought is not scalability, it is an operational surface: a control plane on a release cadence of roughly three or four minor versions a year, an ingress controller, a CNI plugin, cert-manager, a CSI driver, and a set of upgrade windows where all of those must line up. That is a part-time job at minimum, and it is the job nobody was hired for. Container platforms such as ECS with Fargate, Fly or Render, or frankly a couple of VMs behind a load balancer with systemd units, cover a lot of production.

The counterargument, and it is a real one: past roughly five teams deploying independently, Kubernetes is the cheapest common interface anyone has agreed on, and managed control planes have made upgrades far less frightening than they were. If your alternative is five bespoke deployment systems, take the cluster.

2. A two-hour CI pipeline is a design failure, not a hardware problem

Confidence: very high. The reflex response is bigger runners, which buys perhaps 30 percent and hides the actual causes: no test parallelism, a cache key that never hits, rebuilding every package because a README changed, and integration tests that boot the entire stack per test file. The fixes are unglamorous. Build only what changed, using a tool that understands the dependency graph or, at minimum, path filters on the diff. Split test shards by historical duration rather than by directory, because alphabetical splits always leave one shard doing three times the work. Cache at the layer that actually changes. Target under ten minutes to first useful signal; beyond about fifteen, people stop watching their own builds and start batching merges, which is where the compounding damage happens.

Counterargument: some builds are genuinely enormous, and for a large C++ or monolithic mobile build, more hardware really is the honest answer.

3. Microservices are an organisational decision, not a performance one

Confidence: very high. Services exist so that teams can deploy without coordinating. That is the whole benefit and it is a large one. Splitting a system that one team owns, for "scalability", converts function calls into network calls and inherits everything that comes with them: timeouts, retries, partial failures, distributed transactions, and a debugging story that now requires tracing you have not set up. One Postgres and one well-built application server handle far more traffic than most teams will ever see.

Counterargument: there are non-organisational reasons that are legitimate, chiefly blast-radius isolation and compliance boundaries where a component must run in a separate trust zone. Those are architecture, not fashion.

4. YAML is the wrong language for the logic we keep putting in it

Confidence: high. YAML is fine for a flat list of settings. It is a poor host for conditionals, loops and templating, which is exactly what CI definitions and Helm charts are full of. You end up with Go templates generating whitespace-sensitive text, no type checking, no way to unit test a branch, and errors that only surface at apply time. It also has genuine footguns: unquoted no parsing as false under YAML 1.1, version strings silently becoming floats, and tabs being illegal. Typed configuration languages such as CUE or Dhall, or infrastructure defined in a real language through CDK or Pulumi, let you test the logic.

Counterargument, and it lands: a real programming language gives you the power to write configuration nobody can review either. Declarative YAML is diffable, greppable and boring, and boring is worth a lot in a change that touches production.

5. Monorepo versus polyrepo is a tooling argument in disguise

Confidence: high. Both structures work at every size; what differs is which failure you inherit. A monorepo fails when CI rebuilds everything on every commit, so it needs affected-target detection to be usable. A polyrepo fails through version drift and the fourteen-pull-request change, so it needs automated dependency updates and a way to make cross-cutting changes atomically. Pick the failure you already have tooling for, and stop having the philosophical version of the discussion.

Counterargument: at genuine scale the tooling gap is not symmetric, and the monorepo tools are more mature than the cross-repo coordination tools.

6. Blue/green beats canary for small teams

Confidence: medium. Canary deployment only works if you can tell, quickly and automatically, that the canary is worse. That means enough traffic for a difference to be statistically visible and an automated analysis step wired to real metrics. At fifty requests per second you will not detect a one percent error regression before the rollout finishes, so what you actually have is a slower deploy plus somebody squinting at a dashboard. Blue/green gives you one switch, one rollback, and a version boundary you can reason about at three in the morning. The related opinion: a staging environment with no traffic, a different data shape and different IAM is a very expensive way to feel safe, and preview environments plus feature flags usually beat it.

Counterargument: blue/green needs double capacity during the switch and cannot expose a risky change to one percent of users, which is exactly what you want for a schema migration or a pricing change.

7. Alert thresholds should come from an SLO, not from a round number

Confidence: very high, and this is the least unpopular on the list, which is why it is last. Nobody defends CPU above 80 percent as a paging condition, yet those alerts survive in most rotations because deleting them feels risky. A threshold picked because it is a round number carries no information about whether a user noticed. Burn-rate alerting does: page when a large share of the monthly error budget is consumed in an hour, open a ticket when a smaller share goes in six. It gives you a defensible reason to delete two thirds of your alerts, and the resulting rotation is one people will actually stay on. That connects to the honest version of "you build it, you run it", which is that ownership without a funded on-call budget, compensation and a real headcount is just unpaid overtime with a nicer name. Related reading: CI/CD pipelines by the numbers.