Live data from Hacker News

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

news.ycombinator.com

101–110 of 268 posts

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

#101
post #73

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…

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 how mature the product is.

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

#102

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

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

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

#103
post #84

If one API request makes on average 5-10 round trips to the database, and the database is in Virginia, this only makes the problem (much) worse. How do you solve this problem for this use case?

You should solve this by making one request to a db api layer (use GraphQL!) And have that layer do the back and forth with the db, from right next to it.

Holding transactions open for long distance round trips is going to get you into trouble in a myriad of ways. It does not scale.

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

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

I would think it would be better to have a bunch of servers in a single datacenter if low-latency between them is important. Fly.io sounds great for the case where you're willing to sacrifice low-latency between your own servers to get them to have low-latency with your users.

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

#105

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

> Takes "the cloud is expensive" to a whole other level.

What do you mean by this? It seems pretty much on par with the expensive cloud pricing of the big players.

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

#106
post #97
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…

Agreed, that one sentence line is perfect and not fully clear on the website. A lot of these cloud services keep it quite vague for some reason, which I somewhat understand for the whole 'CTO marketing'. But the early adopters will appreciate it and they are who matter the most early on.

I wish more marketing sites just had a description like the one in the root comment, usually I have to read a bunch of docs before I get a grasp on what a product does when they introduce them on HN, if I could just read a description like this I could either look at more info or ignore it if I don't care about it.

Instead, I'm trying to make sense of APIs to figure out what a product called Floozbobble.io does and it turns out that it's SaaS for making SaaS product factory factories, and I don't care about that, but then some other product called Dizmeple.cloud comes out that makes it easier for me to manage my database deployments, which I do care about, and I can't tell I would want it because it has no fucking description!

When did we start to prefer these crap marketing sites that take 12,000 spins on my scroll wheel to get through and still don't tell you anything?

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

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

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

#108
post #84

If one API request makes on average 5-10 round trips to the database, and the database is in Virginia, this only makes the problem (much) worse. How do you solve this problem for this use case?

You should solve this by making one request to a db api layer (use GraphQL!) And have that layer do the back and forth with the db, from right next to it. Holding transactions open for long distance round trips is going to get you into trouble in a myriad of ways. It does not scale.

This is exactly what we do! We have a Rails app exposing a graphql api for our cli and web app. The web app is a React SPA monster that we're replacing with another Rails app that runs at the edge and serves the customer UI, docs, marketing pages, and some other things. It's really pleasant. We love graphql.

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

#109
post #96
post #64

What problem does it solve? Because latency is currently not an issue with all the regions from current cloud providers from my perspective. And for all static stuff you can use a CDN that has pop all arround the world / cities. Not sure I understand the use case of a single Docker image in a city outside of your entire backend services, especially the DB. If your Docker image talks to something else on AWS / GCP for…

This basically bumps the amount of behavior you can stuff into the edge by several orders of magnitude. Previously, Lambda@Edge will like, maybe validate a JWT. Now, you can put like half your app in there. It sounds like a tiny incremental change but it's big enough that it simply redefines what's even possible in a POP.

I'm interested, what is now possible with this? Is it high bandwidth VR sort of stuff?

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

#110

We've been using fly.io for a month now. They are amazing. The service is great, the team is great, and most importantly our apps have seen a dramatic performance uplift by leveraging fly. A++ would use again. Full disclosure: I am another YC founder. Fly did not ask me or encourage me to post this in any way.

What kind of apps are you using it for? How much data do you have to move to the edge?
Post reply on HN