Live data from Hacker News

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

news.ycombinator.com

171–180 of 268 posts

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

#171
post #128

Earlier quoted context omitted.

you might be running into max connection issues because your library is leaving stale connections. i know this is the case for ruby & php. check if you have timeout set. see this github issue for ruby: https://github.com/redis/redis-rb/issues/524

I have the timeout set to 10 seconds which certainly helps, I think the issue is how gunicorn/gevent handle web requests. I think each request spawns a new redis connection, and as far as I can see there is no global pool I can use :( On heroku you are limited to 20 connections in the free tier, and it quickly gets expensive.

Oh yes... I remember bitterly upgrading to a larger size just so >20 goroutines could use the same ~1mb of cached data.

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

#172
post #99

This sounds great. How suitable do you think this is for CPU-intensive work? I'm interested in having servers for scientific-computational work, which would be rather CPU-heavy. It would be great to offload some of this to a nearby browser for bits and pieces that desire low-latency.

We have some customers doing CPU heavy tasks like image and video processing, but we're not specifically optimizing for that right now. If there's demand we might offer better processors or GPUs for those workloads, or maybe even spot pricing on idle nodes, but that's far off.

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

#173
post #161

Earlier quoted context omitted.

They originally had (and seem to still have) the same JS runtime at the edge to give you a smart CDN/reverse proxy. They just updated it from being JS only to being able to run any Docker image. Cloudflare gives you a persistent key/value store and Fly provides a non-persistent Redis cache. You don’t have to move your entire app but there are plenty of use-cases where you can move more logic to the edge.

We’re moving the JS apps to just run on Deno containers. Deno is fabulous.

This is the most intriguing thing for me, perhaps second only to the fact that you guys are working with Rust. I have followed Deno since it was announced and it has been fascinating to watch it evolve. How much Deno code do you all have working in production right now?

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

#174
post #102

Earlier quoted context omitted.

How do you currently host your Docker container at edge nodes? (It's a facetious question: unless you're a $100B company you're not doing anything of the sort.)

Why would I care? I have That's not meant to be a snarky question, I genuinely don't understand what business problem that's going to be solved by saving at most 30 ms. Anything written in Rails/Django, talking to a DB, etc. is going to have request latency dominated by other parts of the stack.

We have some benchmarks comparing us to Heroku (on AWS) and the performance gains from faster networking alone are nothing to sneeze at: https://fly.io/blog/turboku/

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

#175
We've been using fly.io at Draftbit for the last couple of months and have nothing but amazing things to say about the platform, Kurt and the team!

I've gotten several friends to switch and they've all said the same thing. If you haven't given it a shot yet, there's a simple 1 click Heroku to Fly deployment you can use to give them a shot.

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

#176

Neat idea, but what about my database? Where does that live? Do you do anything to speed up latency from the edge to the database?

from another thread: 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!

You should also checkout something like FaunaDB.

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

#178
post #107

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

> I don't have a better solution though

Don't host in such a way that you're paying for traffic... Hetzner, OVH and Packet all have dedicated servers where you don't pay for the traffic, inbound or outbound.

Edit: judging by other comments here, it might seem like US zone of Fly.io is in fact hosted in Packet so they are probably themselves not paying for the traffic. Maybe they are using Hetzner for the EU zone (or OVH for that matter).

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

#179
post #138
post #137

So it’s google cloud run that scales to many servers?

(Cloud Run PM here) Cloud Run automatically scales your container image to thousands of container instances ("servers") if needed, maybe you mean "scales to many regions"?

FWIW, I love CloudRun and when I went to try and deploy Docker images in different places to see how we stacked up, it was the best of the big cloud offerings. I'm not sure any AWS PMs have ever even used Fargate ...

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

#180
Fly.io is the service I’ve been most excited to see make headway in a long time.

Pairing this with a global sql (cough cockroach cough*) is literally the app platform I’ve been dreaming about.

I would like to see more documentation around push based architectures. That is I want to build a system where a process pushes to the Redis in fly but is not running itself in fly. Basically something that may be unrouteable for pulls.

In any case congrats fly team!

Post reply on HN