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.
How the economics of multitenancy work
11–20 of 49 posts
Re: How the economics of multitenancy work
#12Back in the ancient era of the mainframes, this "multitenancy" concept would have been called "time sharing". It looks like everything old is new again.
Oh the memory. IBM3090 MVS with TSO...
Re: How the economics of multitenancy work
#13One 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 had a service that was used to do a bunch of compute at deployment time but even with the ramp up in deployment rates anticipated by the existence of the tool, we had machines that were saturated about 6 hours a month, 12 at the outside. The amount of hardware we has sitting around for this was initially equivalent to about 10% of our primary cluster, and I got it down to about 3%.
But at the end of that project I realized that all this work could have been done on a CI agent if only they had more compute on them. My little cluster was still almost the size of the build agent pool tended to be. If I could convince them to double or quadruple the instance size on the CI pipeline I could turn these machines off entirely, which would be a lower total cost at 2x and only a 30% increase at 4, especially since some builds would go faster resulting in less autoscaling.
So if one other team could also eliminate a similar service, it would be a huge win. I unfortunately did not get to finish that thought due to yet another round of layoffs.
Re: How the economics of multitenancy work
#14Everyone doing multi-tenant SaaS wants cost to be a sub-linear function of usage. This model of large unit capacity divided by small work units is an example of how to get there. The tough bit is that it’s stepwise at low volumes, and becomes linear at large scale, so it’s only magic during the growth phase — which is pretty solid for a growth phase company showing numbers for the next raise.
Something for nothing or the Tragedy of the Commons. Many want a fair division of the cost but an unfair portion of the shared resource, subsidized by people who have not figured out how to minmax their slice of the pie. Doesn’t work when several clever people share the same resource pool.
Re: How the economics of multitenancy work
#15Back 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, in a world where the suppliers got too much leverage and started getting uppity.
Re: How the economics of multitenancy work
#16Surprised 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
If their businessmodel is high performance runners and cheap cost they probably don't want to budge on speed, and once renting something fast on the cloud the costs run up quickly enough that they are probably just better off with a few more machines that pay themselves over time.
Re: How the economics of multitenancy work
#17Back 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!
Re: How the economics of multitenancy work
#18Surprised 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.
Re: How the economics of multitenancy work
#19Back 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!
It pretty much is the same, the only change is the level of abstraction. Apparently the easiest thing for everyone is just giving the user access to the whole damn OS via a container, rather than have them deal with vendor specific mainframe minutea.
Re: How the economics of multitenancy work
#20Surprised 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
yeah, like the others have said, the tradeoff isn't really worth it for us as a business. spot instances also generally come with low qos guarantees (since they tend to be interruptible). tbf there are on-demand alternatives with better guarantees though
another thing to note is that we bootstrap the hosts, and tune them a decent amount, to support certain high-performance features which takes time and makes control + fixed-term ownership desirable
[disclaimer: i work at blacksmith]