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

41–49 of 49 posts

Re: How the economics of multitenancy work

#41

Post by Imustaskforhelp »

nitwit005 wrote: post #24
andrewstuart wrote: post #17

Earlier quoted context omitted.

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.

> Crud app

> Slaps cryptocurrency sticker in 2019-2021 era

Gets 1 million $ funding

> in 2025, slaps AI powered sticker

Gets 10 million $ funding.

But its still a crud app nonetheless.

I know it sounds really over the line example but I am sure that there are examples like this where the same thing gets some new terms and it gets a lot of funding that is, there is an incentive to put on new stickers.

The goal is not to appear different, the goal is probably profit, which they can get if they can get better funding I suppose, and they get better funding by slapping stickers.

Re: How the economics of multitenancy work

#42

Post by Imustaskforhelp »

__turbobrew__ wrote: post #34

Am I reading this right, they are going to rack their own servers for this business? If I were them I would be looking at renting from bargin bin hosting providers like hetzner or ovh to run this on. The great thing is that hetzner also has a large pool of racked servers that you can tap into. You are basically going to re-implement hetzner at a smaller (and probably worse) scale by creating your own multitenant mini…

Yeah, your goal is pretty nice if you want to open source blacksmith at their level, but I think most people would be pretty happy with just a hetzner vm using act https://github.com/nektos/act if they want github actions, or jenkins.

I think we can rent hetnzer vms on a per hour basis or maybe we can't , but I do know that there are services like (linode?) I guess, which use a per second model.

Combine that with I think automatic installation of act and you pay for per second use of your CI.

Plus points if we can use criu to scale from lower end machines to higher end machines depending upon the task while continuing the task from where it was left.

Re: How the economics of multitenancy work

#43

Post by jillesvangurp »

Imustaskforhelp wrote: post #40
jillesvangurp wrote: post #39

For the last two years, I've been running github actions like this: - start a paused vm in google cloud - run the build there (via a gcloud ssh command) and capture the output - pause the vm after it is done Takes about 4-5 minutes. Maybe a few dozen times per month. It's a nice fast machine with lots of CPU and memory. Would cost a small fortune to run 24x7. It would cost more than it costs to run our entire product…

very interesting idea! How much cheap is this as compared to github actions? also why are you using gcloud? would certain other competitors like aws/(hetzner? if we are talking about vps) also suit the case. I would love it if you could write a blog post about it.

We don't really pay for gh actions; we're staying below the freemium limit.

We use gcloud for convenience. Our production environment is there. So spinning up a vm is easy. Our builds also deploy there so we need gcloud credentials in our gh actions anyway. It only runs for a few hours per month in total. So the cost isn't very high. A few dollar at most.

No time for blog posts but feel free to adapt my gh action: https://gist.github.com/jillesvangurp/cccf5f9d61f4b457a994dc...

It basically runs a script on the vm. Should be fairly easy to adapt. There's a bit of bash in there that waits for the machine to come up before it does the ssh command that runs the build script.

Re: How the economics of multitenancy work

#44

Post by hinkley »

esseph wrote: post #33
hinkley wrote: post #15

Earlier quoted context omitted.

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…

Nah, oxide is standardizing pluggable, scalable, rack-unit API driven local cloud, with extremely tight integration that nobody else has largely except Apple. There's different takes on it, that's just mine. I really appreciate and respect their work.

They aren’t standardizing the way the PC was standardized. They’re making custom hardware with custom connectors. Their parts are interchangeable with themselves but the rack is the unit of delivery and operation. Their software is closer to standardizing in the normal sense of the word.

That’s a mainframe, sport. At their height they were modular and in at least IBM’s case they could run with damaged parts and were delivered with dark hardware that could replace damaged parts until a maintenance person could arrive, or be remotely enabled to increase throughput for a fee.

All of this cloud stuff, except the geographical redundancy parts, is recreating software that business had versions of forty years ago.

Re: How the economics of multitenancy work

#45

Post by mlhpdx »

hinkley wrote: post #14
mlhpdx wrote: post #10

Everyone 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.

I’m not sure I get the connection? Designing systems for sub-linear cost scaling is just an engineering problem.

Re: How the economics of multitenancy work

#46

Post by steveklabnik »

hinkley wrote: post #44
esseph wrote: post #33

Earlier quoted context omitted.

Nah, oxide is standardizing pluggable, scalable, rack-unit API driven local cloud, with extremely tight integration that nobody else has largely except Apple. There's different takes on it, that's just mine. I really appreciate and respect their work.

They aren’t standardizing the way the PC was standardized. They’re making custom hardware with custom connectors. Their parts are interchangeable with themselves but the rack is the unit of delivery and operation. Their software is closer to standardizing in the normal sense of the word. That’s a mainframe, sport. At their height they were modular and in at least IBM’s case they could run with damaged parts and were…

It really depends on what you mean by “mainframe.” Architecturally, we are nothing like mainframes. But for what mainframe seems to mean for you, I can see your perspective.

(While the rack is the unit of delivery overall, we can ship individual sleds and they’re operator replaceable, if say, one of your sleds dies, incidentally.)

Re: How the economics of multitenancy work

#47

Post by esseph »

hinkley wrote: post #44
esseph wrote: post #33

Earlier quoted context omitted.

Nah, oxide is standardizing pluggable, scalable, rack-unit API driven local cloud, with extremely tight integration that nobody else has largely except Apple. There's different takes on it, that's just mine. I really appreciate and respect their work.

They aren’t standardizing the way the PC was standardized. They’re making custom hardware with custom connectors. Their parts are interchangeable with themselves but the rack is the unit of delivery and operation. Their software is closer to standardizing in the normal sense of the word. That’s a mainframe, sport. At their height they were modular and in at least IBM’s case they could run with damaged parts and were…

Some of us still touch mainframes, almost daily.

Re: How the economics of multitenancy work

#48

Post by latchkey »

pphysch wrote: post #22
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.

Yeah, isn't this just HPCaaS, with an emphasis on CI workloads?

Seems amazing given that most HPC is locked up in super computers.

Re: How the economics of multitenancy work

#49

Post by latchkey »

jillesvangurp wrote: post #39

For the last two years, I've been running github actions like this: - start a paused vm in google cloud - run the build there (via a gcloud ssh command) and capture the output - pause the vm after it is done Takes about 4-5 minutes. Maybe a few dozen times per month. It's a nice fast machine with lots of CPU and memory. Would cost a small fortune to run 24x7. It would cost more than it costs to run our entire product…

We are building something like this for AMD MI300x GPU CI workloads. Except that every time someone shuts down a VM, we start a fresh one; hot spares cuts down your start up time.

We take on the small fortune expense and multi tenancy does the rest. The plan is to offer this as inexpensive as possible (far cheaper that deploying and running this type of compute yourself), so that it is a no brainer to take advantage of.

Post reply on HN