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

71–80 of 268 posts

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

#71

Post by LunaSea »

yingw787 wrote: post #56
LunaSea wrote: post #54

Earlier quoted context omitted.

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.

https://www.interxion.com/sites/default/files/2020-01/paris-...

I'm guessing it's likely that this solution was adopted to quickly expand to a lot of countries due to data location and privacy questions being raised.

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

#72

Post by mayank »

erohead wrote: post #50
optimiz3 wrote: post #41

Earlier quoted context omitted.

> I was at a company that got acquired before. It was so awful. I'd rather just work on this forever than get absorbed by a big company. How do your investors feel about this / what's your exit plan?

We feel great about Fly.io :) (I am their group partner at YC)

Could you elaborate? :) Because otherwise, you're possibly sending the same message as what I alluded to (i.e., we feel great because we're expecting a big exit).

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

#73

Post by mrkurt »

ThePhysicist wrote: post #61

Who do you peer with in Europe? I see in the US you use Packet ( https://www.packet.com/ ) but I couldn't find any information about the EU, or do you focus on the US market for now? We're also a LIR and want to build an anycast network (we anonymize streaming data), any helpful resources you can share on this? Cool product btw! I think this will be a very interesting area in the coming years, the fact that you offer…

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 into the same ~16 regions, expanding past those can be difficult and even more expensive. That's what we're working on now.

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

#74

Post by kentonv »

ignoramous wrote: post #42

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

Hey, I'm the tech lead of Workers. I don't want to intrude too much on this thread, but just wanted to say: we don't do any special load-balancing for Workers requests; they are treated the same as any other Cloudflare request. We use Anycast routing (where all our datacenters advertise the same IP addresses), which has a lot of benefits, but occasionally produces weird routes. Often this relates to specific ISPs having unusual routing logic that, for whatever reason, doesn't choose the shortest route. We put a lot of effort into tracking these down and fixing them (if the ISP is willing to cooperate). We do sometimes re-route a fraction of traffic away from an overloaded datacenter by having it stop advertising some IPs, but if the internet is working as it should, that traffic should end up going to the next-closest datacenter, not around the world. When you see requests going around the world, feel free to file a support request and tell us about your ISP so we can try to track down the problem and fix it.

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

#75

Post by ThePhysicist »

mrkurt wrote: post #73
ThePhysicist wrote: post #61

Who do you peer with in Europe? I see in the US you use Packet ( https://www.packet.com/ ) but I couldn't find any information about the EU, or do you focus on the US market for now? We're also a LIR and want to build an anycast network (we anonymize streaming data), any helpful resources you can share on this? Cool product btw! I think this will be a very interesting area in the coming years, the fact that you offer…

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…

Cool, thanks! I know Vultr but I'm looking for a second provider to fulfill the multi-homing requirement. And yes it's expensive and I think it's a valuable service to developers you're offering!

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

#76

Post by chrisjarvis »

Hi, this is a very cool product and I am planning a project that I think could use it.

The question I have tho: How do you take advantage of the gains from this if you still need one master strictly consistent db for writes?

Would a system design pattern to take advantage of fly.io be to have read only replicas on each geographic deploy or to only have region specific persistance? Apologies if this was already answered I read thru everything I saw. Thanks!

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

#77

Post by mrkurt »

chrisjarvis wrote: post #76

Hi, this is a very cool product and I am planning a project that I think could use it. The question I have tho: How do you take advantage of the gains from this if you still need one master strictly consistent db for writes? Would a system design pattern to take advantage of fly.io be to have read only replicas on each geographic deploy or to only have region specific persistance? Apologies if this was already answer…

The "simplest" gains come from adding an in memory cache, we include Redis for this and some apps work really well just leaving the DB where it is, caching aggressively, and running close to users: https://fly.io/docs/redis/

Read only replicas are a great first step for most applications. I'd probably do caching first, then replicas (which are kind of like caching).

Region specific persistence is one way to improve write latency, and I think the simplest for most apps. We've experimented with CockroachDB for this (it keeps ranges of rows where they're most busy), and you can actually deploy MongoDB this way.

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

#78

Post by michaeldwan »

mnutt wrote: post #67

I vaguely remember that fly.io used to have a platform based on v8 isolates, I’m guessing the new platform is a bit of a pivot? I’m curious, was it just to support more platforms, or we’re there technical challenges with isolates?

It's a bit of a pivot but still in the same space. Here's a few reasons why we landed on this:

- Our JS apps require customers to write new code to solve problems. That’s a tough sell for companies with existing code they need to make fast.

- The more people used JS apps the more unexpected things they wanted to do. Like tensorflow at the edge, audio and video encoding, game servers, etc. No way we could support any of that without moving down the stack.

- Reimplementing the service worker api was a slog we didn’t want to continue. Deno is fantastic and we’d rather just run those apps than compete with it

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

#79

Post by chrisjarvis »

mrkurt wrote: post #77
chrisjarvis wrote: post #76

Hi, this is a very cool product and I am planning a project that I think could use it. The question I have tho: How do you take advantage of the gains from this if you still need one master strictly consistent db for writes? Would a system design pattern to take advantage of fly.io be to have read only replicas on each geographic deploy or to only have region specific persistance? Apologies if this was already answer…

The "simplest" gains come from adding an in memory cache, we include Redis for this and some apps work really well just leaving the DB where it is, caching aggressively, and running close to users: https://fly.io/docs/redis/ Read only replicas are a great first step for most applications. I'd probably do caching first, then replicas (which are kind of like caching). Region specific persistence is one way to improve w…

Thanks that totally makes sense! I look forward to playing around with this.

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

#80

Post by dathinab »

> 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/companies where the max caps are more important then availability.

I heard of more then one project which mad some mistake them self wrt. some code generating request in their client. Or had some other reason why they had insane usage spikes, causing them to basically go bankrupt in a mater of a view hours. Not even days. (Through one project got lucked out as if I remember correctly Amazone bailed them out to prevent bad press).

IMHO for the majority of server application availability is important but only up to a certain cost. After which unavailability for some time is better, even if you lose some customers. (Yes, like always there are exceptions).

Post reply on HN