I’m probably missing something obvious, so take this as a genuine question rather than an attempt to debate, but why aren’t they fundamentally connected?
If you sometimes need 10 servers and sometimes need 100 (elasticity) then with renting you can always have the proper number. If you own, then you have to own all 100 servers.
> why aren’t they fundamentally connected?
They are connected in the sense that capacity planning is always a thing. But that doesn't mean that the ownership model is inextricably tied to the deployment model, which is how I personally say instead of "elastic infrastructure." "I am making an HTTP call to request a new VM" is very different than "file a ticket with IT to procure me a new server, install it in the data center, and then send me the keys." The slogan "pets vs cattle" is an advanced form of this change in thinking. In some sense, it is hard to own your hardware yet treat your servers like cattle.
You basically have four basic options:
* deploy elastic, rent your hardware: this is the default today for many startups
* deploy to hardware directly, buy your hardware: this is the Old Times
* deploy elastic, buy your hardware: this is Oxide
* deploy to hardware, rent your hardware: this is a thing, though not nearly as popular as the other three
(I call them basic because hybrid is a thing: you can own usual capacity and then rent more for bursts, or as a fallback, etc)
Now, Oxide is not the only game in town when it comes to "deploy elastic, buy your hardware": this is what many IT departments do. You could, for example, buy some servers, toss OpenStack on there. Oxide's thesis is that doing this is less than ideal, and we can make it significantly better. In fact, it is so suboptimal that many people choose "deploy elastic, rent your hardware" because it is so much easier. And now we're back to Bryan's statement.
Does that makes sense?