3 ms·
This math _is_ right. 1000 requests/s is 86.4M requests per day. So for 1000 requests in a given second, that's $0.05 per second if you substitute the term. But
by Xorlev 10y ago
This math _is_ right. 1000 requests/s is 86.4M requests per day. So for 1000 requests in a given second, that's $0.05 per second if you substitute the term. But to show you otherwise:
1000 req/s * 86400s * 30d / 1000 * 0.05 = 129600
It's only $129/mo if it's 0.05c and not $0.05, which is not what the website says.
- mrkurt 10y agoOh I see what you're saying. Then yes, your math is right, but our assumptions probably don't match. :) 1. This is our earliest launch. We're very expensive for 86mm requests per day right now. We have volume pricing planned but not rolled out. If you're interested, I'd suggest trying a low volume site to see how it feels and then get ahold of me to talk about volume pricing. 2. Our service is designed for "valuable" requests, not any ol' asset. API calls and pageviews are usually a good fit. Sustaining 1k "valuable" requests/s for a full month is pretty rare. I know you and other people on HN run that level of infrastructure, but our value prop for you won't be very high until we're more mature.
- pvg 10y agoSure but even at dozens or 100s of rps, the point where a loadbalancer really starts making sense, it's quite pricy. I think you just priced out $126 for a monthly average of one rps above. One.
- mrkurt 10y agoThis is an interesting point. I actually think our service makes sense from 0 requests, because we can (a) speed ssl stuff up immediately (and latency sucks at any volume) and (b) let people ship faster. If you're building a SaaS that's doing ~2.6mm pageviews per month, you've probably saved enough time using our features that $126 is nothing. The economics for a free service or media property are different, but we'll be valuable for different reasons too (and possibly even have a different pricing model for stuff like that).
- pvg 10y agoThe pricing structure has similar problems at the low end. A small (2.6mm pageviews per month is tiny) SaaS would presumably have more than one request per page they want to fly-ify so once again fly becomes a big chunk of infrastructure costs. What's worse, it's linearly-really-expensive. A lot of services targeted at the low end tend to sell some sort of peace of mind - 'give us $100/mo for capacity you don't use but should you suddenly need it, we have you covered'. Whereas Fly is priced "it's expensive now but should you experience sudden growth we're really gonna ream you". And traffic growth doesn't necessarily mean revenue growth so the fact you were on the evening news or got really popular Malaysia might just mean a big bill. For a small service, Fly pricing is practically a DOS vector.
- mrkurt 10y agoWe should clarify this, but fly is best suited for the "valuable" requests, and we've been recommending that people put their static assets on a more traditional CDN. We should _also_ document a policy on DOS stuff. We don't intend to run people out of money if they do get attacked. In fact, we have some ideas for middleware that would end requests early and not bill at all. Still, when we've done metered services in the past we were really generous with refunds / credits after bursts (which is basically what AWS et all do too).
- Xorlev 10y agoI'd still say you need to take a hard look at your pricing. Lets assume we're talking about a pretty standard Rails site on Heroku without ridiculous traffic. Lets say 1500 requests per minute average (25/s). 25 * 86400 * 30 * 0.05 / 1000 = $3,240 I'm legitimately going to be spending 5-10x as much for my loadbalancer as I am 2 Heroku dynos and a reasonable Heroku Postgres instance. All I can say is that I'd recommend discounting your price by 5-10x to put it in reach. You don't want to be the biggest line item in someone's budget, you'll be the first to go. Back in the early days of FullContact, we charged a _lot_ per record for our Person API. After a lot of feedback at SXSW Interactive, we announced a 50x price cut. I'm pretty sure that's the only reason our API took off as a business. We optimized on volume and made it cheap to sustain thousands of requests a second. Five years later, that's paid off for us quite well.
- mrkurt 10y agoWould it surprise you if I said we're testing pricing as part of our launch? I don't think anyone ever gets it right from the get go. :D Hopefully if we get to be the biggest infrastructure charge in someone's budget, it'll be really hard to get rid of us. 5-10x discounts for volume probably aren't unreasonable.
- Xorlev 10y agoBeen in the startup game, totally understand. I'm presenting my view, which could be wrong but I figured you'd like my unfiltered feedback. Like I said before, we too had it wrong from the start and products we launched after weren't priced correctly either. It's a fine balance to price something just right to drive new customers, retain old, and maximize margins to ensure your venture succeeds (or can at least take another round to continue building). Are you guys bootstrapped? Curious to hear more on that front. :)
- mrkurt 10y ago:thumbsup: We aren't bootstrapped, we raised a seed round. Turns out when you don't need money it's easy to get ... I'm happy to give you all the gory details if you want to shoot me an email (mrkurt at gmail). I think we triggered the flamewar thing on HN so I can't respond here very fast.
- jhgg 10y agoPretty interesting - but doing some number crunching, Fly looks to be two orders of magnitude more expensive than enterprise cloudflare. Which does offer smart routing, load balancing and what not.
- mrkurt 10y agoHey, we're huge discord fans (we're mostly using it instead of Slack). I'd love to find out more about what you all use for this stuff. I'm not shocked we're more than Enterprise Cloudflare, primarily because we don't have an Enterprise product just yet.
- jhgg 10y agoYah sure - hit me up jh@<ourwebsitehere.com> (where ourwebsiteher is discordapp)
- steeve 10y ago1k req/s to an API is not that uncommon at all. We were running at that rate way before we could even afford cloud services.