Live data from Hacker News

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

news.ycombinator.com

51–60 of 268 posts

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

#51
post #36

Earlier quoted context omitted.

Right now we're best suited for app servers, databases won't (yet) run very well on fly.io. We are trying really hard to focus on what we have because it's so valuable but we love DBs so much we might end up trying to "solve" them soon.

Fair enough! I signed up, looking forward to DBs on Fly.io! (Also I got permission denied when attempting to curl the script when writing to /usr/local/bin, I needed sudo. I'm on Ubuntu 19.10 Eoan Ermine. Not sure whether security implications for `curl | sh` outweigh convenience, but I trust you guys and my connection. :P)

Heh curl to sudo slippery slope :P

The script is just picking the binary for your OS/arch and putting in PATH. We have instructions for doing it yourself here https://fly.io/docs/getting-started/installing-flyctl/#comma...

Or you can download straight from github: https://github.com/superfly/flyctl/releases

Hopefully we can get on snap soon!

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

#53

Had a look at the network pricing. I wouldn't host anything there. Takes "the cloud is expensive" to a whole other level.

I usually balk at pricing tables too, but real world has shown to be different. One of our big customers saved $130K/mo by switching to us!

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

#54
post #7

Honestly, while I'd love to try this out, I'm afraid of committing to a solution that might not be around long-term, which for me at least overrides concerns of peace of mind and ease of use, and I'm doing a hobby project at the moment. I'm using bare AWS at the moment because a) they gave me $5k in credits for YC SUS, b) they own the physical servers, and c) I can trust that they'll be around a long time, so I'd rat…

Depending on the region your infrastructure is located in, AWS doesn't own the datacenter.

For example in the Paris (eu-west-3) region, their availability zones are operated on hardware owned and managed by Telehouse, Interxion and Equinix.

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

#55

I like the idea of an edge service that is accessible to everyone. The list of cities looks pretty random to me. In particular I am not seeing anything in the Northeast, New York, etc. In upstate I already have 30ms latency to AWS and Azure in Ohio without terrible tail latency.

There's one in the Newark area: `ewr Parsippany, NJ (US)` from https://fly.io/docs/regions/

Are these airport names? Just clicked for me. Is this typical across the industry? I think I remember Rackspace also using ord and iad...

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

#56
post #54
post #7

Honestly, while I'd love to try this out, I'm afraid of committing to a solution that might not be around long-term, which for me at least overrides concerns of peace of mind and ease of use, and I'm doing a hobby project at the moment. I'm using bare AWS at the moment because a) they gave me $5k in credits for YC SUS, b) they own the physical servers, and c) I can trust that they'll be around a long time, so I'd rat…

Depending on the region your infrastructure is located in, AWS doesn't own the datacenter. For example in the Paris (eu-west-3) region, their availability zones are operated on hardware owned and managed by Telehouse, Interxion and Equinix.

Huh, interesting, I didn't know this. Thanks so much for sharing! Do you have a link? I searched and found all three companies, but I only see links to AWS Direct Connect and hybrid cloud solutions.

I just assumed if they're creating their own chips, they're probably creating their own servers, datacenters, networks, etc. but I guess I shouldn't jump to conclusions.

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

#58

Congratulations on the launch! I've been following fly.io ever since I stumbled on it 2 years ago. A few questions, if I may: > We run a mesh Wireguard network for backhaul, so in flight data is encrypted all the way into a user application. This is the same kind of network infrastructure the good content delivery networks use. Does it mean the backhaul is private and not tunneling through the public internet? > fly.…

> Does it mean the backhaul is private and not tunneling through the public internet?

Backhaul runs only through the encrypted tunnel. The Wireguard connection itself _can_ go over the public internet, but the data within the tunnel is encrypted and never exposed.

> I use Cloudflare Workers and I find that at times they load-balance the traffic away from the nearest location [0][1] to some location half-way around the world adding up to 8x to the usual latency we'd rather not have. I understand the point of not running an app in all locations esp for low traffic or cold apps, but do you also "load-balance" away the traffic to data-centers with higher capacity?

This is actually a few different problems. Anycast can be confusing and sometimes you'll see weird internet routes, we've seen people from Michigan get routed to Tokyo for some reason. This is especially bad when you have hundreds of locations announcing an IP block.

Server capacity is a slightly different issue. We put apps where we see the most "users" (based on connection volumes). If we get a spike that fills up a region and can't put your app there, we'll put it in the next nearest region, which I think is what you want!

CDNs are notorious for forcing traffic to their cheapest locations, which they can do because they're pretty opaque. We probably couldn't get away with that even if we wanted to.

> Frequently? Are these server-routers running in more locations than data centers that run apps?

We run routers + apps in all the regions we're in, but it's somewhat common to see apps with VMs in, say, 3 regions. This happens when they don't get enough traffic to run in every region (based on the scaling settings), or occasionally when they have _so much_ traffic in a few regions all their VMs get migrated there.

> Interesting, and if you're okay sharing more-- is it that the anycast setup and routing that took time, or figuring out networking wrt the app/containers?

Anycast was a giant pain to get going right, then Wireguard + backhaul were tricky (we use a tool called autowire to maintain wireguard settings across all the servers). The actual container networking was pretty simple since we started with ipv6. When you have more IP addresses than atoms in the universe you can be a little inefficient with them. :)

(Also I owe you an email, I will absolutely respond to you and I'm sorry it's taken so long)

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

#59

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…

Glad to hear you all are doing great with Rust! :D
Post reply on HN