Introduction
Introduction Statistics Contact Development Disclaimer Help
_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
Visit Hacker News on the Web
COMMENT PAGE FOR:
R0ML's Ratio
osener wrote 1 day ago:
Ah the joys of enterprise.
Once, a team at my old job wanted to try A/B testing for the first
time. After some research, they picked a SaaS tool to make it quick.
Simple, right? Just sign up and go.
Of course not. First they had to go through THE PROCUREMENT! (dun dun
dun dun)
Those legends weren’t about to let us limp along on a humble pro
plan. They wheeled, dealed, and months later emerged triumphant: a
glorious three-year enterprise contract. SLAs! Volume discounts! The
whole nine yards. The art of the deal baby!
Small snag: by the time the ink dried, the original team had moved on.
New PM, new priorities. No one even generated an API key during the
whole time we paid for this top-tier enterprise service.
valicord wrote 1 day ago:
So buy in bulk if it's cheaper then per unit and buy per unit if it's
cheaper than in bulk? Truly a brilliant advice. What's next? "Get
multiple quotes and pick the best one"?
jdpage wrote 1 day ago:
Buy in bulk if it's cheaper per unit that you buy, and per unit if
it's cheaper per unit that you use. (EDIT: with the understanding
that you're unlikely to buy much more than you use if just-in-time
per-unit purchasing is available). No, it's not groundbreaking
advice, but it's a very easy trap to fall into, especially if you're
talking to someone who's good at selling you stuff.
I'm sure we've all had an experience at least once where we've bought
something in a larger container from the grocery store thinking we
were getting a deal, only to find that we didn't get through it as
fast as we thought we would, it started spoiling, and we got to
scrape our savings into the trash can.
And many of us have had an experience where someone higher up in the
company has insisted that we use a tool that isn't very good "because
we've already paid for it", so it's clearly needed advice, even if
it's not groundbreaking. Everyone sometimes needs "obvious"
conclusions pointed out to them, I think. It's a quirk of our mental
processing as humans.
valicord wrote 1 day ago:
No, it's always "per unit that you use". Units that you buy and not
use are wasted, so that's would be the wrong way to compare.
Dressing up an obvious idea with fancy-sounding math formulas and
pages of text is exactly how you get trapped by someone good at
selling stuff.
jdpage wrote 1 day ago:
You're right, but I think you're less likely to buy extra at
per-unit pricing (since you can always buy just-in-time), so
you're less likely to run into a situation where you
overpurchased at per-unit pricing. (Edited to note that.)
nighthawk454 wrote 1 day ago:
Essentially, when you buy in bulk you trade upfront commitment for a
discounted price. Which isn’t a good deal unless you’re confident
you’re going to use all the units/seats you bought.
This is the same logic as over buying at the grocery store. The unit
cost of bulk items may be less, but if the surplus is just gonna spoil
you’ve wasted money in the difference.
1.0 * N * discount_rate * price <= certainty * N * 1.0 * price
—> discount_rate / certainty <= 1.0
—> discount_rate <= certainty
In the event your confidence/usage is lower than the discounted rate -
say discounted to 80% of sticker price but you expect 60% utilization -
this might suggest you buy 60% of your capacity at the bulk rate and
fill any further demand with on-demand full-price option.
jerryjappinen wrote 19 hours 53 min ago:
I saw Unsure Calculator on HN some time ago. Seems like the perfect
use case.
[1]: https://filiph.github.io/unsure/
tekacs wrote 1 day ago:
I found this article somewhat confusing to read, so I asked for a
synthesis of it, shared below for anyone else who might run into the
same.
[1]: https://share.cleanshot.com/7zq42cMg
codazoda wrote 1 day ago:
I once worked for a company that went from 100k annually to over $1B in
under a year. I was 18 and they gave me a corporate card and almost no
particular restrictions on its use. I thought they were a bozo. Now
I’m not so sure.
jiggawatts wrote 1 day ago:
I see this regularly in large enterprise. My favourite example is
getting a 20-30% discount on rack-mount server hardware purchased
up-front for the next 3 to 5 years of growth requirements. Invariably,
the executives that signed this "great deal" treat themselves to a
champagne lunch to celebrate the savings.
Never mind that most of that capacity will sit around unused for years.
The real problem is that by the time they get around to filling the
last half of the capacity, the exponential march of Moore's law -- or
the equivalents for storage and networking -- will have discounted the
cost of that capacity by 50% or more anyway.
Similarly, I saw a corporation "lock in" a sweet discount for the WAN
network provider for 7 years where they got an upgrade from 1 Mbps to 2
Mbps and a discount of 40%. At the same time, residential broadband was
already 25 Mbps minimum and business-grade fibre had three-digit Mbps
speeds within months. The sales rep that got that deal signed probably
laughed his ass off.
It's a fundamental misunderstanding that it's easier or better to
purchase things in big stair-step increments when following an
exponential curve. The waste will be exponentially higher the longer
the steps. Ideally, one would want to purchase hardware in the smallest
possible time-steps, following product release cycles exactly. That's
one of the benefits of the public cloud, you can switch CPUs (or
whatever) with a button-press.
The example of this that's burned into my mind is that a vendor (Dell
or HPE, I can't remember) convinced a government department to buy a
48-core AMD EPYC server for bioinformatics. This is one of those
problems where you want the biggest possible single box because of the
way the algorithms scale ("up", not "out"). They're stuck with that box
for the next five or so years. Meanwhile the cloud public cloud is
making available these monsters: [1] Check out that beautiful
exponential curve! If you "lock in" just 2 or 3 generations back,
you're missing out on 90% of what you could be using.
[1]: https://techcommunity.microsoft.com/blog/azurehighperformancec...
protocolture wrote 1 day ago:
>Similarly, I saw a corporation "lock in" a sweet discount for the
WAN network provider for 7 years where they got an upgrade from 1
Mbps to 2 Mbps and a discount of 40%. At the same time, residential
broadband was already 25 Mbps minimum and business-grade fibre had
three-digit Mbps speeds within months. The sales rep that got that
deal signed probably laughed his ass off.
Its actually one of the least bad ISP business models. Its fantastic
for capacity planning. I worked for an ISP that got a lot of
businesses signed up on 700 buck per month EOC services, 4-5 year
terms, before the NBN rolled out and provided 20 times the bandwidth
for 50 bucks.
Thing is, when the NBN passed those customers, they would reach out
and try and move them sideways. Extend the contract for 2 years, drop
700 bucks down to 400 and bundle in voice and managed router
services. Add in fixed wireless for backup. Offer them 100M business
fibre for a transition up to 1k/ month.
An ISP that can do this can afford service techs, upgrades, more
peering and transit. It can breathe. Trying to sell a 40 dollar TC-4
NBN service for 42 dollars is a losing proposition. The customer
feels good when they get a good deal but they lose out when the ISP
starts downsizing or crawling back costly transit. And if its month
to month, the constant churn is crazy.
maxbond wrote 1 day ago:
As a point of information (I don't disagree with anything you've
said), just because public clouds advertise a gigantic instance type
doesn't necessarily mean you can provision it. I saw a situation at
work once where the ML researchers couldn't figure out why they were
failing to provision a box. The request would be pending for a few
hours before failing. AWS eventually said they simply didn't have the
capacity in that AZ, and it was unlikely to ever succeed.
jiggawatts wrote 1 day ago:
Conversely, if you're in some co-location facility and they run out
of space/cooling/power, then you might be painted into a very small
corner for an extended period. This happened to several government
customers because they all shared a common facility. Entire
departments were squeezing blood from a stone because they had an
iron rule that "no more servers", not even VMs... for years.
In the public cloud, you can almost always just pick another AZ,
another region, or another SKU. Because of how Spot priced compute
works, a PayG customer will essentially always be able to provision
something, somewhere.
<- back to front page
You are viewing proxied material from codevoid.de. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.