Do You Really Wanna Be First?

Yesterday’s post was about shortages ending in gluts. Today’s is about the moment before that, the announcement moment, when a cloud provider launches a new SKU and the marketing machine spins up to full volume. New GPU family, new Arm chip with more memory than anything before it, new instance type with a number that sounds one generation better than what you run now. The temptation is to get on it right away. If you run capacity at any real scale, you should read that announcement differently.

The reason the marketing is dialed up to maximum is not that the provider wants to celebrate with you. It is that the provider does not actually know what the demand for this SKU will be, and it probably does not have enough capacity to serve much of it yet. Your usage is the signal. Every team that adopts the new SKU feeds a number into a procurement engine somewhere, and that number is what justifies buying more of whatever chip is on the board of the new machines. You are not just a customer in the first year of a new SKU. You are a sensor.

Being a sensor comes with conditions, and the first one shows up before you write a single line of code. New SKUs land in a couple of regions first, not everywhere. The rollout of Amazon’s C8gb instances, the latest Graviton4 generation, is a clean current example: the October announcement extended them to Ohio, N. California, Frankfurt, Ireland, Paris, Stockholm, and Cape Town, and even then the full list was still a short one.¹ So the first question is not whether the new chip is faster. It is whether the region you run in has it, and whether your data gravity, your latency budget, and your disaster-recovery footprint survive a move to the regions that do. Often the answer is yes and you proceed. Sometimes the answer quietly kills the project, and you find out after the evaluation is half done.

The second condition is support. A brand-new SKU has not soaked in production the way the three-generations-old SKU around it has. The drivers are newer, the firmware is newer, the observability you have built around the older fleet does not know what the new hardware reports or what it breaks on. If something goes wrong at two in the morning, you are closer to the front of the line finding out than the back of it. The preview terms that govern early-access features say this in the vendor’s own words: previews are provided “AS-IS,” “WITH ALL FAULTS,” excluded from service level agreements, may not be covered by customer support, and may be discontinued without ever reaching general availability.² The GA instance you get twelve months later carries none of those caveats. The early version of the same machine carries all of them.

Which is why the honest translation of a launch announcement, when you run capacity at scale, is this: you are going to be a beta tester for a new SKU for about a year, and if it works it will be wonderful, and if it does not, you will be the one holding the shortages while everyone else waits it out. The book has a name for the underlying trap, the double bubble: paying twice for the same thing because you replaced something before its replacement was proven.³ Jumping on a new SKU is the compute version. You pay for the evaluation, the migration, the re-tuning, and the incidents, and if the SKU turns out to be scarce or short-lived, you pay again to get off it or to wait behind everyone who did the math you skipped.

None of this means the new chip is bad. Most of them are genuinely good, and some of them become the default within two years. The point is about timing and who absorbs the risk. A first adopter absorbs all of it, alone, at production scale. A second-year adopter absorbs almost none of it: the regions are filled in, the firmware is mature, the support engineers have seen the failure modes, the capacity exists, and the pricing has usually relaxed from the launch premium.

So the recommendation is boring and it holds: if you run capacity at scale, give it about a year. Let somebody else generate the demand signal. Let the provider work out the shortages, the region gaps, and the early driver bugs. Then jump in as a consumer, when the machine you asked about on day one is actually available in your region, at a sane price, with support that has already met your failure modes. Being first is a job. The provider is already getting paid for it. There is no reason you should do it for free.