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

41–50 of 268 posts

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

#41

Post by optimiz3 »

mrkurt wrote: post #35
mayank wrote: post #28

Earlier quoted context omitted.

> 1) we own physical servers and 2) we're profitable 3) have big public companies as customers Ironically, these also make you a prime acquisition target (because the product idea rocks), which renders your long-term future unclear.

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.

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

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

#42

Post by ignoramous »

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.io is really a way to run Docker images on servers in different cities and a global router to connect users to the nearest avaible instance.

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? If so, is there a documentation around this? I'm asking because for my use-case, I'd rather have the app running in the next-nearest location and not the least-load location.

> The router terminates TLS when necessary and then hands the connection off to the best available Firecracker VM, which is frequently in a different city.

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

Out of curiosity, are these server-routers eBPF-based or dpdk or...?

> Networking took us a lot of time to get right.

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?

Thanks a lot.

[0] https://community.cloudflare.com/t/caveat-emptor-code-runs-i...

[1] https://cloudflare-test.judge.sh/

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

#43

Post by jeromegn »

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 to get there, though.

All in all, I would recommend Rust wholeheartedly. The ecosystem is growing and getting more mature every week. The community is very helpful in general, especially the tokio folks.

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

#44

Post by michaeldwan »

zomglings wrote: post #30

Is it already possible or do you guys plan to add support for attaching persistent storage to applications deployed with fly? I am building a search engine and this would let me derive your performance benefits using region-scoped databases and search indices.

That's awesome, your use case is perfect for region scoped persistent storage.

We're testing persistent storage privately with a few customers now and the results are exciting. My favorite is using minio as a private global s3 for caching.

What are you using for the index storage engine?

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

#45

Post by eloff »

yingw787 wrote: 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…

"I won't use anything from smaller or new companies or Google in case it goes away". That's silly, how is this the top comment? Are people that conservative in tech of all places? This is a docker runtime. If it goes away you'll be up and running again without delay on AWS or anywhere else, you just won't have the edge performance characteristics.

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

#46

Post by yingw787 »

mrkurt wrote: post #36
yingw787 wrote: post #25

Actually, one more question...do you guys scale compute and data layers separately, or are they tightly coupled within the same container? I was looking at containerized PostgreSQL on AWS because I want to colocate a job scheduling tool (pg_cron) with the database process, but RDS doesn't support that extension. Apparently (or at least I hope), ecs-cli compose supports docker volumes through EBS, which is the same ba…

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)

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

#47

Post by tarun_anand »

mrkurt wrote: post #36
yingw787 wrote: post #25

Actually, one more question...do you guys scale compute and data layers separately, or are they tightly coupled within the same container? I was looking at containerized PostgreSQL on AWS because I want to colocate a job scheduling tool (pg_cron) with the database process, but RDS doesn't support that extension. Apparently (or at least I hope), ecs-cli compose supports docker volumes through EBS, which is the same ba…

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.

But your most valuable customers will need to interact with an app server plus database for any real life use case. Can you share some applications where only placing the app server close to user works? Is the database back in Virginia?

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

#49

Post by yingw787 »

eloff wrote: post #45
yingw787 wrote: 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…

"I won't use anything from smaller or new companies or Google in case it goes away". That's silly, how is this the top comment? Are people that conservative in tech of all places? This is a docker runtime. If it goes away you'll be up and running again without delay on AWS or anywhere else, you just won't have the edge performance characteristics.

Yes, I'm very conservative. I'm in tech because I want to compound my achievements over time, and I can't do that if I fear the ground shifting underneath my feet. Hence Bezo's mantra "focus on the things that don't change". I hate O(N) efforts, I prefer O(N log N) efforts or better.

Enterprise workloads are far more conservative than I am, those guys spend decades running the same servers. It's why they can focus on sales and customer success and rake in money, which is what actually puts food on the table for their kids.

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

#50

Post by erohead »

optimiz3 wrote: post #41
mrkurt wrote: post #35

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.

> 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)
Post reply on HN