Before the Bill Gets Smaller, I Want to Know Where the Money Goes

I recently watched a video from 理性避難所 about Walmart and Kmart. One line came back to me while discussing metabiz's costs: low prices are an outcome, not a strategy.

The video's explanation does not stop at who is willing to sell more cheaply. It looks behind the price to see what makes it possible. Distribution centers, store density, and replenishment illustrate how several practices support one another and gradually change costs.

The video explains strategic leverage through the connections between distribution, stores, and replenishment. What I want to keep is not Walmart's pricing, but the order of the work.

First find a practice that makes other things easier. Costs and prices may then change. Simply deciding to be cheaper does not explain how we will keep doing it.

This connects with work we were doing in early October.

Our task was concrete: check metabiz's cloud resources one by one, find what could be adjusted, and avoid breaking services that were still in use.

Which services were active? Which resources were no longer needed? What was actually keeping the hosts busy? We were also considering whether some workloads could run on our own equipment again.

I needed more than a lower cost estimate. Engineering needed to check dependencies and load, sales needed to confirm who was still using the services, and we needed to retain evidence from each change. Looking at only one side makes it easy to cut the wrong thing.

But I cannot simply hand over a list and ask everyone to investigate before we talk. We can first organize existing bills, configurations, and monitoring, propose candidate changes, then ask the relevant people to check dependencies that remain unclear. Where monitoring is missing, we need to arrange the evidence ourselves. Not being able to find usage is not proof that nobody uses it.

If you are deciding whether to downsize a host, remove a service, or move it back on-premises, this article is about the checks needed before making that decision.

It is easy to start by asking how much we can save.

Of course I want to know. But the more closely we look, the more we find decisions that cannot begin with price alone.

One host had high CPU usage. From that number, downsizing seemed difficult.

Later diagnosis records showed that a considerable part of the load came from log collection and repeatedly scanning historical logs. After the fix, short-duration samples of Docker resource use dropped noticeably.

In the October 3 verification record, the host had not yet been downsized. Other services, memory, and peak load were still marked for further observation.

Even so, this changed how I saw that high CPU number.

We might have assumed the work required that much capacity. Following the cause showed that some of it was avoidable repeated processing.

In other words, there was work to do before discussing a cheaper machine.

What I want to bring back from the video is the search for practices that reduce unnecessary consumption over time—not a demand that everyone push costs to the absolute minimum.

Removing an unused resource can save money. If the next deployment creates the same resource again, we will have to remove it again.

Finding the cause, verifying the fix, and retaining the configuration gives the next host a chance to avoid the same problem.

Monitoring, diagnosis, and deployment are then no longer three separate tasks. Monitoring helps us see, diagnosis helps us understand why, and deployment gives the fix a chance to last.

I also want to keep the video's three self-checks. Here is how I interpret them for metabiz.

First, is there a specific point of leverage? “Reduce cloud costs” is not enough. We need to identify which consumption to address first and why that makes later configuration changes easier.

Second, do the important actions support one another? If monitoring, fixes, and deployment happen independently, repaired problems may return. The work needs to connect.

Third, does the direction make clear what we will not do? For us, that includes not downsizing from one low CPU sample, not assuming a backup proves recoverability, and not removing necessary work merely to save money.

These questions help me check the direction. Actual savings still need to be checked against configuration, load, and bills.

Nor do I want to assume that moving services onto our own hosts must be cheaper.

The cloud bill may shrink, but electricity, backups, maintenance, and responsibility for failures do not disappear because they are absent from that bill. We need to consider them together.

Likewise, lower CPU usage does not mean costs have already fallen. We must confirm the work still runs correctly, actually adjust the configuration, and examine later bills to know what was saved.

Looking back at the review, some changes were made and some remained under observation. I want every saving to have an explainable source, rather than add estimates from different periods into an attractive number.

If a customer asks us for a similar review, I want them to see where we can begin: what we will check first, what assessment we will deliver, and which permissions are needed. We should not require them to find the waste before we take over. But the depth of the work and the investment it needs should be agreed first.

This also raises a question about products and projects.

If every customer requires fresh organization, fresh integration, and fresh firefighting, a lower quote merely means we charge less. Delivery itself has not become easier.

But if we become better at a class of work, and adoption, acceptance, and support have reusable foundations, we gain choices. We can offer customers better prices, or leave more room for service and quality.

I still want the bill to get smaller.

I just want to know whether that is because we paid for less—or because we genuinely made the work run more smoothly.

— Adam｜metabiz Founder

Further viewing: 理性避難所｜Walmart and Kmart. Read the Chinese original.