Priya was proud of her team’s container setup. Builds were quick, images were tidy, and deploys went out several times a day. Then a message from finance landed in her inbox: the line for storage and transfer around the container registry had been climbing for months, and could she explain it? She could not. She knew everything about how the images were built and nothing about what they cost to keep. What followed was a small piece of detective work that taught her more about her career than about Docker.
The symptom: a line that only goes up
The registry charge was not huge. That was part of the problem. It was small enough to ignore and steady enough to be annoying. Priya’s first instinct was the one most of us share: look for a switch to flip. Delete old things, shrink something, hope it works. But which things? She had hundreds of images, a build for every commit, and no memory of why half of them existed.
Her mentor on a previous team had once told her that a total is a rumour until you divide it. She decided to try, with a pencil, a spreadsheet and an afternoon she could not really spare.
Choosing units that match how the team works
Priya picked three: cost per image stored, cost per build and cost per pull. Each answered a different question.
- Per image stored showed what it costs to keep one thing around.
- Per build showed what each commit added to the pile.
- Per pull showed what it costs when a server or a teammate fetches an image, which relates to data transfer.
She counted images from the registry, builds from the pipeline history and pulls from the registry’s access records, then divided the relevant charges. The figures were rough, so she wrote down every assumption, including which repositories she had left out and why. A reader could disagree with any of them, and that was the intention. The picture that emerged was clear within an hour.
The diagnosis
Cost per build had been fairly steady. Cost per pull was reasonable. But the cost to keep each image had barely moved, while the number of images had grown without pause, because nothing ever removed old ones. Every commit created a new image, each image carried layers that were largely the same as the last, and none of it was cleaned up. The bill was not climbing because the team was careless with builds. It was climbing because the team had never decided how long an image deserved to live.
If this sounds familiar, the advice in the guide to managing Docker images well across an engineering team goes into tagging, layering and retention in more depth. Priya found that none of it was exotic. It was a set of small decisions that nobody had made on purpose.
The solution, in small steps
- Decide retention. The team agreed to keep images that were in use plus a recent handful, and let the rest expire.
- Tag with meaning. Images tagged for releases were kept longer than throwaway builds.
- Trim the layers. A few images were bigger than they needed to be, a classic trap covered in the piece on common Docker mistakes beginners should avoid.
- Watch the unit. Priya added the three costs to her monthly review notes so the trend would stay visible.
She did not promise a particular saving, and neither should you. The point was that the team now knew what it was choosing.
What it did for her career
Here is the part that surprised her. The explanation she gave to finance, short and unit-based, was repeated by people she had never met. A director quoted it in a planning discussion. A colleague asked her to show how she had done it. Within a few months she was the person others sought out when a bill did not make sense, which is a very good thing to be known for.
If you are building a reputation in DevOps, this is worth noting. Technical skill earns respect from peers, but the ability to connect your work to the business gets you heard further up. Writing up a case like this on your own blog, with the assumptions stated openly, is a fine way to build a public profile without any self-promotion. People remember the engineer who explained something clearly.
Where she went to learn more
Priya wanted a framework rather than a one-off trick, so she explored the FinOps training and certification offered by FinOpsSchool, available online or in a classroom for engineers, testers, managers and architects. What drew her in was the mixed audience: engineering and finance people studying the very same problems side by side.
How to run your own diagnosis
You can follow Priya’s steps in an afternoon. Pick a charge you cannot explain. Choose two or three units that match how your team works. Count each, divide, and write down what you assumed. Look for the unit that has moved and ask what decision, or absence of one, lies behind it. Then share the result with someone outside engineering and ask what they would want to know next.
A growing bill is rarely a sign of carelessness. More often it marks a decision nobody got round to making. Unit costs do not make the decision for you, but they point to where it belongs, and they hand you a story worth telling.
