Hacker News Reader

Comment by bcantrill | Hacker News Reader

Our big belief is that elastic infrastructure (that is, cloud computing) should be orthogonal to the economic model (that is, own versus rent). Today, that is not the case: if you want cloud computing, you more or less have to rent it. But we know that there are many who wish (or need) to run cloud computing but on an owned asset. There are many factors that deter that today, not least the odious per-core licensing that we highlight here. (For a particular brazen example of this, see VMware's infamous "AMD tax" ca. 2020.[0])

[0] https://news.vmware.com/company/cpu-pricing-model-update-feb...

View on HN

Why aren't there prices on the website? (Seems weird that there isn't given that blog post, where costs are pretty central.)

(not Bryan, not actively part of the decision to put prices on the website or not, just my own take.)

Different audiences have different expectations. In the place we are, that is, enterprise sales, the expectation is not that you can go to a website, get a price, and click a button. The expectation is that the two organizations will communicate over a period of time ("the sales cycle") to work through everything that goes into a deal, and eventually come to an agreement or not. This includes so many variables that putting the price on the website wouldn't make sense, as you're never going to end up at that exact price.

I used to find this attitude frustrating, as an engineer, but the longer I have been a professional, and worked at various organizations, the more I come around to that being a good thing, not a bad thing.

All I really want to know is "ballpark" - are we talking four, five, ten figures?

I feel bad burning salesman time for a solution that is way out of our range, but I can't learn that until after a meeting or two.

I hear you, but I can assure you that this comes with the territory for sales people. Qualifying leads is part of the job.

It's between a half million and a million.

Oxide is offering you radically different -better- terms. The price they mean to charge will almost be based around what they need to a) fund more development, b) grow, and probably also relate to what their competition charge. The actual price you would actually negotiate surely depends on other factors, like how badly you want those better terms. If the better terms aren't enough to make you talk to them about pricing, then Oxide surely isn't for you.

If the price isn't listed, I always take it as a sign that nobody is buying it for price reasons ("if you have to ask, you can't afford it"). Outside of the blog, I don't even see a claim that it's cheaper so that's consistent.

That is understandable, but you would be mistaken.

That quote (which may not even have been said by J.P. Morgan) is talking about luxury consumer goods, which is a completely different market than business to business sales.

I wonder how many startups are overpaying for things like cloud because they are using consumer thinking instead of business thinking.

A huge number. I do a lot of due diligence of companies, and the over engineering on the cloud and costs have to be seen to believed. A common theme now is people use lambdas and step functions in replace of function calls. So a page load or transaction may involve two dozen serial lambda invocations. It is madness.

By way of contrast, a payments provider we explored had four moderate sized boxes running everything. They were about six years old and fully depreciated, but more than adequate to run millions of transactions through a month.

"If you have to ask, you probably can't fit it in your house."

As someone that often has limited time to research viable options to present to leadership, I expect to be able to negotiate pricing at the enterprise level if we want to move forward. What's deeply frustrating that keeps me from sometimes mentioning an option is having no idea what the rough order of magnitude pricing is. Some kind of pricing is deeply appreciated.

If I don't know whether something will fit within the approximate budget for the project and can't quickly get an idea from other research I'm not going to mention it as an option. I'm used to spending about a million per rack but that's for a complete ESX cluster with storage and networking, if I have no idea how alternatives stack up against that it's hard to put it on the table.

I will echo this. A product with no pricing information will often just get no further exploration, especially if a competitor does have it. Don't underestimate the overhead of just having to talk sales before you have a price.

You are right that this sort of sales style has its downsides. I am also not saying there's no value in having something on the page, or that Oxide is always going to be this way. I am just talking about why it is a norm in many parts of the B2B world.

I’m surprised there is anything that you can spend a million dollars on where nearly all the alternatives aren’t “please contact sales”. And even if there was, you couldn’t do any real analysis without contacting sales, because any displayed price would be highly negotiable.

Where I’m frustrated by this attitude is when I just want to buy 10 seats of something and it doesn’t have a price, not at the seven digit level.

> Our big belief is that elastic infrastructure (that is, cloud computing) should be orthogonal to the economic model (that is, own versus rent).

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.

(not Bryan)

> 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?

It does make sense, thanks.

I'm not Bryan, obviously, but part of the answer here is that 100 servers running at 100% capacity is an absolute upper bound, but most of the time you're nowhere near that. Most of the time few things are at full capacity, which means that you can multiplex your physical hardware resources to increase utilization efficiency.

I actually find it interesting how many things we (which, in part, I mean I) got wrong about cloud computing early on. Various other things too.

Reply on news.ycombinator.com