7 ms·
Mighty was like compute arbitrage. The bet was that you could buy compute at cloud prices, resell it to end users, and since this is cheaper than buying consume
by anhncommenter25 4y ago
Mighty was like compute arbitrage. The bet was that you could buy compute at cloud prices, resell it to end users, and since this is cheaper than buying consumer compute in the form of workstations, laptops, & tablets, you can pocket the difference.
I can't think of a bigger slice of consumer compute than browser workload; so if the scheme doesn't work there, it won't work for anything. My conclusion is that compute arbitrage isn't viable for B2C. You will have to actually provide a service on top of the resale. For example Github Codespaces is reselling cloud compute while simultaneously solving infra-as-code pain points in the CI/CD pipeline.
- fragmede 4y agoI don't think it means services+arbitrage doesn't work. They were paying (I assume) cloud VM prices, and had to charge 20-30/month. If they had lower costs and were able to charge $5/month and still make money, we might not be having this conversation right now.
- jacurtis 4y agoServices+Arbitrage definitely works. But Mighty didn't solve a painful-enough pain point. The arbitrage was how Mighty made money (buy a cloud VM for $10/mo and sell it for $20 with a software wrapper). But customers need a reason to pay for it. The advantages that Mighty offered weren't significant enough to impact most people. If they did, the advantages gained were questionable IMHO. Forcing people into a whole new workflow to slightly improve client-side JS performance is probably a worse trade-off for the vast majority of people even if you ignore cost entirely. Only a small group of people are encountering this pain point enough to actually seek out a solution for it. Once that small group of people find your solution, then you have to convince them to pay $20-30 a month to remove it. People are already canceling $12/mo Netflix subscriptions. To pay double-that for better JS rendering is a tough sale.
- wmf 4y agoHasn't cloud compute always been far more expensive than local hardware? I don't see any arbitrage opportunity here. Twenty years ago VDI wanted to replace desktop PCs with VMware ($$$) running on quad-socket servers ($$$) with fibre channel SAN storage ($$$). I didn't understand the economics then and I don't today.
- ip26 4y agoThe idea is predicated on economies of scale and low utilization rates typical of local hardware. The success of AWS and Azure show it can be done. (You do have to avoid replacing cheap commodity desktops with exotic bleeding edge servers, it’s hard to make up for that)
- svnt 4y agoWhich means that if Mighty survived the M1 it would have been dead anyway (probably in not more than a few months) by Azure and AWS offering it once Mighty proved the market.
- ip26 4y agoNot exactly, if the market was small it wouldn’t be worth AWS’s time to provide a turnkey. Plenty of small operations provide services backed by AWS without getting eaten for that reason.
- jacurtis 4y agoI interviewed at a very successful startup last year that was basically doing the exact same thing as mighty. But they were selling it as primarily a security advantage (since its effectively an air gap computer) with additional advantages to performance. The product itself was basically identical to Mighty. However, because it was marketed as a Security tool, they got customers from 9 of the 10 largest world banks, several government agencies, and so forth who bought licenses for every employee due to the security advantages that having an ephemeral server in the cloud provides. The companies enjoyed that there was also a performance benefit and they could skimp on physical workstations as a secondary benefit. But the product was selling licenses by the pallet load because of the security aspect, the performance was just a bonus. Like I said, the product was effectively identical to what Mighty was doing. I think it was even younger than Mighty and was vastly more successful due to its market positioning.