Right Sizing, or Paying for What You Actually Use

Almost every machine in a migrated estate is the size it is because somebody read the specification of the server it replaced. That server was bought years ago, sized for a peak that was guessed at, and then bought one size larger for safety because nobody wanted to go back for more budget in eighteen months.

That was reasonable when you owned the hardware. The margin was paid for once, it sat there quietly, and having spare capacity was a virtue. When you rent by the hour, the same margin is billed every hour of every month for as long as the machine exists.

So the first move is to find out what each system actually uses, before anybody buys a discount or turns on a clever feature. Almost nobody does that before the first bill arrives, and a great many people do it afterwards.

Expect to find two things. A set of machines using a fraction of what they were given, and one or two that are genuinely constrained and have been quietly slow for a year without anybody raising it.

Processor use is the easy one and the least interesting. Look at it over a full business cycle rather than a day, because the shape matters more than the average. A machine sitting low all month with one sharp climb at month end is a different problem from one sitting low all the time.

Memory is the measurement that matters most and the one most often missing, because on many platforms the machine does not report it unless you install an agent. Install the agent. Undersizing memory is how you turn a cost saving into an outage, and it fails in a way that looks like a mysterious application fault rather than like a capacity problem.

Then disk and network. Storage speed is bought separately from storage space on most platforms, and it is very common to find a large slow disk where a small fast one was needed, or the reverse. Network throughput has a ceiling that depends on machine size, which catches people who shrink a machine and then wonder why backups take all night.

Set the target against the busy end of a normal week rather than the single worst minute of the year. Sizing for the absolute peak is how you end up back where you started. Handle the once a year peak by scheduling a temporary larger size for that week, which is a thing you can do now and could not do with a server in a rack.

Resize one step at a time and let a full business cycle pass before the next one. The instinct after seeing a low usage graph is to cut hard, and the result is a system that copes fine for three weeks and falls over during month end processing.

Do it in a change window, because most resizes require a restart, and write down the previous size so going back is a two minute job rather than an investigation. Tell the people who use the system that it happened. When something feels slower a fortnight later, you want them to mention it rather than absorb it.

Some things resize easily and some do not. Machines usually take a restart. Managed databases often resize with a brief interruption. Disks on many platforms can grow but not shrink, so an oversized disk has to be replaced rather than adjusted, which is a real piece of work and worth planning as one.

Keep a record of what you changed and when. Six months later somebody will be investigating a performance complaint, and knowing that the machine was halved in March turns a week of guessing into a five minute answer.

Databases are usually the largest single cost in an estate and the most often oversized, because they are sized by fear. Nobody wants to be the person who made the order system slow, so the answer to what size shall we make it is always the next one up.

Look at the database's own measurements rather than the machine's. Buffer cache behaviour, connection counts, slow query logs, whether the working set fits in memory. A database that is genuinely memory constrained will tell you clearly. A database chosen at that size for comfort will show a memory graph that has never moved.

Check the surrounding choices at the same time. Whether the storage tier matches the read pattern. Whether the replica exists for reading or only for failover, and whether anything is actually using it. Whether the backup retention was set to a number somebody chose or to whatever the default was.

And check the copies. Test and staging databases are often running at the same size as the live one because the environment was cloned. A testing copy rarely needs the capacity of a system serving customers, and this is frequently the easiest saving in the whole account.

Committing to a term genuinely lowers the rate, and it is the most straightforward saving available. It is also a promise, and the promise is what people get wrong. You are agreeing to spend a certain amount for a period whether or not you use it.

So commit to the baseline, never to the peak. Look at the level your spend never drops below over a year, and commit at or under that. Everything above it stays on demand, where you can change your mind. Committing to a number that includes waste locks that waste in for the whole term, and it is the most common expensive mistake in this kind of work.

Order matters. Clean up first, right size second, commit third. Committing to the size of an oversized fleet means you have bought a discount on machines you were about to delete, and the discount will be smaller than the deletion would have been.

Match the term to the certainty. A database that will still be there in three years is a good candidate for a longer commitment. A workload that a team is actively rebuilding is not. Where the platform offers a more flexible commitment that applies across machine types, that flexibility is usually worth the slightly smaller discount for anything you are less sure about.

Autoscaling adds and removes copies of something that was built to run as several copies. Every disappointment people have with it follows from that one sentence.

It does nothing for a single database, because there is one of those and it cannot be cloned on demand. It does nothing for an application that keeps a user's session in the memory of one machine, because removing a machine logs those people out. It does nothing for a workload whose load is flat, because there is nothing to scale away from.

Even where it fits, the timing is awkward. Scaling out takes as long as the new machine takes to start and warm up, which is often minutes, while a traffic spike arrives in seconds. That gap is why people who turned it on for cost end up leaving a comfortable minimum running, and most of the saving goes with it.

Where it does earn its keep is on predictable shapes. A workload that is busy during office hours and quiet at night, or heavy on weekdays and light at weekends, can be scheduled rather than reactive, and scheduled scaling is far more reliable than the reactive kind. Take the easy version first and reach for the clever one only when the load is genuinely unpredictable.

Development, test and staging environments run around the clock for people who work office hours. Switching them off overnight and at weekends removes a large share of their cost, needs no architecture, and breaks nothing that a start button will not fix.

Make off the default and let teams request exceptions. Somebody will need an environment running for an overnight test, and that is a fine exception with an owner and an end date. What you are removing is the environment that runs all year because nobody ever considered the question.

Size them smaller too. A test environment usually needs to prove that the software works, not that it performs, and where performance testing is genuinely needed, it needs a full size environment for a few days rather than all year.

One caution worth naming. Where an environment is used by people in another time zone, or by an offshore team, office hours is not the window you think it is. Ask before you schedule, or you will find out through a ticket at an awkward hour.

Sizing drifts back. New systems land oversized because nobody yet knows what they need, machines get bumped up during incidents and stay there, and every new team repeats the pattern the last one grew out of.

So put a short review in the calendar every quarter with a named owner. It looks at the biggest lines, the machines with flat low usage, anything created since the last review, and any commitment coming up for renewal. An hour or two, four times a year, holds the ground that a big clean up wins.

Give teams their own numbers. When a team can see what their systems cost and how that has changed, they make sensible decisions without being asked, because most engineers would rather not waste money. When the cost only exists as one company total, nobody can act on it.

And leave some margin on purpose. Squeezing every system to its exact measured need produces an estate with no headroom, and the money you save will be spent on the incident that follows. Right sizing means paying for what you use plus a margin you chose, rather than for a margin somebody guessed at years ago.