Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How the economics of multitenancy work

blacksmith.sh

Post reply on HN
Print view View original

21–30 of 49 posts

Re: How the economics of multitenancy work

#21

Post by [deleted] »

hinkley wrote: post #15
TuringTest wrote: post #11

Back in the ancient era of the mainframes, this "multitenancy" concept would have been called "time sharing". It looks like everything old is new again.

I was kind of disappointed the first time I saw an IBM mainframe and it kinda just looked like a rack of servers. To be fair, it was taking up a little bit of a server room that had clearly been designed for a larger predecessor and now almost had enough free space for a proper game of ping pong. Hyperscaler rack designs definitely blur this line further. In some ways I think Oxide is trying to reinvent the mainframe…

[deleted]

Re: How the economics of multitenancy work

#23

Post by matt-p »

zdc1 wrote: post #5

One thing I'd love to see is dynamic CPU allocation or otherwise something similar to Jenkin's concept of a flyweight runner. Certain pipelines can often spend minutes to hours using zero CPU just polling for completion (e.g. CloudFormation, hosted E2E tests, etc.) In these cases I'd be charged for 2 vCPUs but use almost nothing. Otherwise, the customers are stuck with the same sizing/packing/utilisation problems. An…

I'm sure they're doing this, they'd be mad not to - firecracker has cgroup support.

Re: How the economics of multitenancy work

#24

Post by nitwit005 »

andrewstuart wrote: post #17
TuringTest wrote: post #11

Back in the ancient era of the mainframes, this "multitenancy" concept would have been called "time sharing". It looks like everything old is new again.

It’s a common refrain on HN this thing is the same as something old. Dagnab those young folks!

People trying to market things create a lot of new terms. They don't want to seem like they're selling the same old thing, but something new and innovative.

Occasionally, the new term is warranted, of course, but that's far less common than simply trying to appear different.

Re: How the economics of multitenancy work

#25

Post by Havoc »

matt-p wrote: post #18
Havoc wrote: post #9

Surprised they’re doing fixed leases. I would have thought a fixed base with a layer of spot priced VMs for peaks would be more efficient on cost

Outside of the big clouds just buying a 1 Year lease (say) on a dedicated server is so cheap that you'd not be saving much vs spot instances and with spot instances you need code to manage this and you're introducing risk of slowdowns. Probably not worth the trade off. To illustrate a 128GB ram 20 core server with a 10Gbps NIC and some small SSD storage is probably going to cost you <$2000 USD for a years rental.

They've got usage that plummets 80% 2 days a week and the other 5 have a broad predictable time based pattern where usage drops ~66% judging by graph.

If that works out to same prices as keeping compute at literally your peak requirement level round the clock then something is very wrong somewhere. Maybe that issue is not in-house at blacksmith - perhaps spot pricing is a joke...but something there doesn't check out.

Loads of companies do scaling with much less predictable patterns.

>risk of slowdowns

Yeah you do probably want the scaling to be super conservative...but -80% fluctuation is a comically large gap to not actively scale

>To illustrate

Better view I'd say is: That chart looks like ~4.5 peak. So you're paying for 730 hours of peak capacity and using all of it about 90 hrs.

Given that they wrote a blog about this topic they probably have a good reason for doing it this way. Just doesn't really make sense to me based on given info

Re: How the economics of multitenancy work

#26

Post by LunaSea »

aayushshah15 wrote: post #4
shadowgovt wrote: post #2

Interesting writeup. I wonder somewhat what this looks like from the customer side; one downside I've observed with some serverless in the past is that it can introduce up-front latency delays as the system spins up support to handle your spike. I know the CI consensus seems to be that latency matters little in a process that's going to take a long time to run to completion anyway... But I'm also a developer of CI, a…

> one downside I've observed with some serverless in the past is that it can introduce up-front latency delays as the system spins up support to handle your spike [cofounder of blacksmith here] This is exactly one of the symptoms of running CI on traditional hyperscalers we're setting out to solve. The fundamental requirement for CI is that each job requires its own fresh VM (which is unlike traditional serverless wo…

> The fundamental requirement for CI is that each job requires its own fresh VM (which is unlike traditional serverless workloads like lambdas). To provision an EC2 instance for a CI job

Is this different to lambdas or ECS services due to the need to setup a VM / container and nested virtualisation / Docker-in-Docker is not supported?

Re: How the economics of multitenancy work

#27

Post by matt-p »

Havoc wrote: post #25
matt-p wrote: post #18

Earlier quoted context omitted.

Outside of the big clouds just buying a 1 Year lease (say) on a dedicated server is so cheap that you'd not be saving much vs spot instances and with spot instances you need code to manage this and you're introducing risk of slowdowns. Probably not worth the trade off. To illustrate a 128GB ram 20 core server with a 10Gbps NIC and some small SSD storage is probably going to cost you <$2000 USD for a years rental.

They've got usage that plummets 80% 2 days a week and the other 5 have a broad predictable time based pattern where usage drops ~66% judging by graph. If that works out to same prices as keeping compute at literally your peak requirement level round the clock then something is very wrong somewhere. Maybe that issue is not in-house at blacksmith - perhaps spot pricing is a joke...but something there doesn't check out.…

I think you're reading a graph for a single tenant not overall infrastructure.

m7i.4xlarge on AWS spot price right now is $0.39/hour whereas renting the server is about half that per hour.

Re: How the economics of multitenancy work

#28

Post by mgaunard »

In my experience scaling dynamically just makes things slower and it doesn't reduce costs significantly compared to having dedicated resources.

Resourcing dynamically is also difficult because you don't actually know upfront how many resources your CI needs.

Re: How the economics of multitenancy work

#29

Post by Havoc »

matt-p wrote: post #27
Havoc wrote: post #25

Earlier quoted context omitted.

They've got usage that plummets 80% 2 days a week and the other 5 have a broad predictable time based pattern where usage drops ~66% judging by graph. If that works out to same prices as keeping compute at literally your peak requirement level round the clock then something is very wrong somewhere. Maybe that issue is not in-house at blacksmith - perhaps spot pricing is a joke...but something there doesn't check out.…

I think you're reading a graph for a single tenant not overall infrastructure. m7i.4xlarge on AWS spot price right now is $0.39/hour whereas renting the server is about half that per hour.

No, I'm not. I'm looking at the 5 day average across fleet graph right at the bottom. That shows very roughly 2/3 drop from peak to lowest, while the 80% is from the text as fleet wide.

>whereas renting the server is about half that per hour.

If you're at capacity only 90 out of 730 a month then paying 2x for spot to cover those peaks is a slam dunk

Re: How the economics of multitenancy work

#30

Post by [deleted] »

zdc1 wrote: post #5

One thing I'd love to see is dynamic CPU allocation or otherwise something similar to Jenkin's concept of a flyweight runner. Certain pipelines can often spend minutes to hours using zero CPU just polling for completion (e.g. CloudFormation, hosted E2E tests, etc.) In these cases I'd be charged for 2 vCPUs but use almost nothing. Otherwise, the customers are stuck with the same sizing/packing/utilisation problems. An…

[deleted]
Post reply on HN