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

Launch HN: Fly.io (YC W20) – Deploy app servers close to your users

news.ycombinator.com

Post reply on HN
Print view View original

111–120 of 268 posts

Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users

#111

Post by [deleted] »

ar0b wrote: post #107
dathinab wrote: post #80

> 2. Max monthly spend: unexpected traffic spikes happen, and the thought of spending an unbounded amount of money in a month is really uncomfortable. You can configure fly.io apps with a max monthly budget, we'll suspend them when they hit that budget, and then re-enable them at the beginning of the next month. I like this, not having caps is a major problem with some of your competition for smaller projects/compani…

I don't think I like the failure mode of your app getting slower (losing your ApplicationDN) right at the time it's really popular. I don't have a better solution though.

[deleted]

Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users

#112

Post by jimleroyer »

jeromegn wrote: post #43
jimleroyer wrote: post #32

Pretty nice to see Rust being used for network performance code. Do you have any learning using it to share? Would you rather use C++ if you'd have to do it again? Do you feel more confident in your code? Do you feel it was slower or quicker to write code compared to C++

We attempted C++ about a year ago, but I was never confident in our ability to clean up memory allocations (we had leaks) or avoid undefined behavior (we had segfaults). I definitely feel more confident about our Rust code. It's no silver bullet, but it prevents a lot of unsoundness with its compile-time guarantees. I can't really compare to C++, but it's easy to write new code or refactor old code. It took some time…

Thanks for sharing! It's nice to hear about this learning. Also, wasn't aware of tokio, it looks real nice.

Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users

#113

Post by mrkurt »

a13n wrote: post #92
michaeldwan wrote: post #86

Earlier quoted context omitted.

We're not solving db latency yet. A good place to start is aggressively caching at the edge. We offer an in-memory redis cache for this that can replicate commands globally. Beyond that you'd need read replicas which will be possible once we launch persistent storage. That said, latency between data centers on the same continent is often less than I would have thought!

Gotcha, honestly that feels pretty niche to me, which might be a good place for a startup to start. I can't think of many back-end applications between purely static content (just use a CDN) and needs a database connection. Probably video game servers, where you don't need the game state to be (immediately) stored/accessed globally.

Game servers are a great example. What's interesting is how many different kinds of apps need game-server like infrastructure: https://www.figma.com/blog/how-figmas-multiplayer-technology...

We've been talking to a lot of startups doing communications tools, especially for remote work.

Lots of full stack apps benefit from app servers + redis cache in different regions. They need a database connection, but if they're already done the work to minimize DB round trips they might just work with no code changes.

There are also a bunch of folks doing really dynamic video and image delivery. Where an individual user gets an entirely unique blob of binary data.

Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users

#114

Post by riquito »

Hi, cool service!

I have some questions about the pricing.

Say I want to use micro-1x with hard_limit/soft_limit = 20 and I get 40 concurrent request for one hour, would it cost $2.67 (micro-1 price) * 2? ($5.34) (monthly cost) If that is the case, can I set a limit on how many instances I want to run at most?

Another question: is the price calculated per second or is it there just to compare it with other services? If it's per second, since you don't fully scale to zero, should I consider having always at least one vm active full time?

Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users

#115

Post by michaeldwan »

lpellis wrote: post #100

The max monthly spend is awesome, I'l probably try it out just because of that :) Its a bit unclear to me though how exactly the heroku deploy works? Is it basically a replacement for the web dynos that heroku provides, but then still connecting to existing postgres instances for example? What are the limits for the redis store? I'm using it on heroku but constantly running into max connection issues, if you can impr…

Glad to hear :)

You're exactly right about the Heroku deploy. We convert your app's slug to a Docker image and launch the web process in it. DB & other dynos still run on Heroku.

We don't have any hard connection limits on the redis cache. It's usually not an issue anyway since apps are often distributed across many regions and many redis servers.

Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users

#116

Post by mrkurt »

tomcam wrote: post #88

Fascinating idea. I’d like gently to suggest that you make this your elevator pitch, since I don’t care about who you are. It’s pretty much what you said, but up at the top: “fly.io is really a way to run Docker images on servers in different cities and a global router to connect users to the nearest available instance. We convert your Docker image into a root filesystem, boot tiny VMs using an Amazon project called…

This is actually one of my favorite things about Hacker News. I end up redoing landing pages each time we get comments like this.

Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users

#117

Post by samcrawford »

davidkhess wrote: post #93

How does this compare to StackPath? https://www.stackpath.com

We use StackPath in a similar capacity to the one being pitched here. They support both containers and VMs, and have a very good spread of locations. Their heritage is a CDN - they were formerly MaxCDN and Highwinds - so their connectivity to eyeball networks is excellent.

We had some minor reliability issues with the edge platform early on, but their support and responsiveness was excellent.

We are very happy with them!

Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users

#118

Post by CraftThatBlock »

riquito wrote: post #114

Hi, cool service! I have some questions about the pricing. Say I want to use micro-1x with hard_limit/soft_limit = 20 and I get 40 concurrent request for one hour, would it cost $2.67 (micro-1 price) * 2? ($5.34) (monthly cost) If that is the case, can I set a limit on how many instances I want to run at most? Another question: is the price calculated per second or is it there just to compare it with other services?…

It looks like the pricing is actually seconds base, so you would have 2 * 3600s * 0.000001015$/s = 0.007308$

Re: Launch HN: Fly.io (YC W20) – Deploy app servers close to your users

#119

Post by mrkurt »

dmix wrote: post #101
mrkurt wrote: post #73

Earlier quoted context omitted.

We actually have servers in North America, Europe (including Frankfurt), and Asia Pacific. The complete list is here: https://fly.io/docs/regions/#discovering-your-applications-r... Building an anycast network is expensive. That's part of what we want to make accessible to devs. There are a couple of companies (like Packet, and possibly Vultr) you can lease servers from that will handle anycast. These tend to get you…

Having a more prominent 'locations' or 'regions' link on the website navigation/homepage might be helpful. It was the first thing I looked for even before pricing. It's currently a bit hidden in the docs. I know locations are probably not super important to you guys as you see it as a starting point or something super flexible, but I always find myself drawn to the concrete stuff like that. Largely as a measure of ho…

Good call. We have a neat visualization we want to build to show what's happening, but we don't need to wait on that to make it more obvious.
Post reply on HN