Beyond waste

Deleting zombies is the easy half of cleaning up a cloud. The harder half is complexity: five Kubernetes clusters where two would do, forty service accounts where a dozen are needed, three environments that differ in ways nobody remembers, and services built on options that were fashionable a few years ago. None of these is "waste" in the sense of unused, but they all cost money, slow people down and make mistakes more likely.

The useful question is a thought experiment: if we started from scratch today, what would our cloud look like, and how far is the current one from that?

Five decisions

For each resource, or better, for each group of resources that belong together, choose one of five outcomes:

  • Keep. It is used, well designed, and has an owner. Leave it alone, and document it.
  • Remove. It is unused. Follow a safe deletion routine, as in our guide to deleting cloud resources without breaking production.
  • Merge. It duplicates something else. Two clusters, three buckets for the same purpose, or two databases with the same data that could share one.
  • Modernize. It works but sits on an outdated design: an unmaintained runtime, a manually built server, a service with keys where it could use short-lived access.
  • Replace. It no longer fits at all, and a different service would do the job with less cost or less risk.

The questions to ask

The same short list works for everything:

  1. Is it used? What is the evidence, and over what period?
  2. Who owns it? Is there a person or a team who can say what it is for?
  3. Does it duplicate anything? Is there another resource that does the same job?
  4. What depends on it? What breaks if it changes, and how easily can we undo that?
  5. Is it still the right design? Would we choose it again today, for this need?
  6. What does it cost, and what does it risk? In money, in security exposure and in time spent on it.

Write the answers and the decision next to each group. That record is the plan, and it is also what lets another person check your thinking.

In what order

  1. Remove first. It is the safest, and it shrinks the problem you have to think about.
  2. Merge next. Consolidating duplicates cuts cost and reduces what you have to secure and operate. Do it one pair at a time.
  3. Modernize after that. Fix what you keep: runtimes, access patterns and infrastructure as code.
  4. Replace last. It is the most work and the highest risk. Often a modernised resource turns out to be good enough.

Run each step through your normal environments, DEV first, then STAGE, then PROD, and write the infrastructure as code so that the new state is the one you can reproduce.

Pitfalls

  • Rebuilding everything at once. A big-bang rebuild stops other work and breaks in surprising ways. Small steps that each reduce risk win.
  • Deciding without evidence. "This looks old" is not a reason. Use usage, ownership and dependency data.
  • Ignoring people. The teams who use a resource often know why it exists. Ask them before you decide.
  • No follow-up. Without a rule that stops sprawl from growing back, you will repeat the exercise in two years.

The first move is a map of what you have: see our guide to mapping your cloud and finding its owners. When you want a structured review with a roadmap your team can execute, our cloud architecture consulting and FinOps consulting cover exactly that.