Live data from Hacker News

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

news.ycombinator.com

261–268 of 268 posts

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

#261
post #97

Earlier quoted context omitted.

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

when companies decided it was too hard to run data driven marketing programs?

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

#262
Meta Comment: Why are such posts (to HN users) written in grey text on a matching background? So hard to read, and I'm not even color blind. Please make it normal black text, ffs; there is no reason for this abysmal color scheme. Every time I open one of these posts, my initial impression is that it has been downvoted into oblivion, because that is what the color represents.

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

#263

This is awesome work. What I'd like to see is some support for higher-level structures, i.e. autoscaling, stateful sets, service to service communication, persistent volumes, etc.

I would like to see that too. Hopefully we can keep working on fly.io and ultimately do all those things.

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

#264

Hey all! I had the chance to see everyone from Fly.io at Hack Arizona -- they gave a presentation before the hackathon began. That presentation displayed the worst work/life balance I think I've ever seen. Every trope was there: "we're not coworkers, we're family", "our developers love to work, they do it out of love", virtue signaling, etc, etc. The whole shebang. Just my two cents, but I really feel that this is a…

I don't know if that makes a company to avoid, but that's certainly a good point of awareness to raise.

It is an unrelated company.

https://news.ycombinator.com/item?id=22626922

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

#265

Hey all! I had the chance to see everyone from Fly.io at Hack Arizona -- they gave a presentation before the hackathon began. That presentation displayed the worst work/life balance I think I've ever seen. Every trope was there: "we're not coworkers, we're family", "our developers love to work, they do it out of love", virtue signaling, etc, etc. The whole shebang. Just my two cents, but I really feel that this is a…

This is about an unrelated company. See downthread: https://news.ycombinator.com/item?id=22626922

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

#266
post #253
post #247

Earlier quoted context omitted.

I discovered it when looking into runtimes for my Bachelor's thesis. So far it's serving me quite well, especially after they reworked the Sentry file system abstraction (when I started file access was horribly slow). Networking works very well although they reimplemented it themselves. It also allows me to do base image layering using Overlay since I only keep binaries/source code/assets after a successful build.

Overlay is a nice feature, we had to give that up with Firecracker. We pre-optimize filesystems instead, tgz them, and then cache them in various regions. Boot times are _insanely_ good, which we like, although a lot of apps (especially node apps) are slow to start.

> ...which we like, although a lot of apps (especially node apps) are slow to start.

Surprising since NodeJS routinely comes up as the fastest runtime in Lambda benchmarks, especially for cold-starts: https://levelup.gitconnected.com/aws-lambda-cold-start-langu...

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

#267
post #66

Earlier quoted context omitted.

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?

You are mostly right, there are a surprising number of problems that don't need much database interaction. Lots of image generation, video workloads, game servers, etc. One of the things we want to do, though, is make "boring" apps really fast. My heuristic for this is "can you put a Rails app on fly.io without a rewrite?". Many of these applications add a caching layer. Normally if someone wants to make a Rails app…

I've seen https://macrometa.co take a stab at an edge database, but their guarantees (consistency / correctness) don't really infuse any sort of confidence in me [0]. https://yugabyte.com is another global scale database that competes squarely with cockroach-db, though I haven't used either.

Cloudflare Workers KV has the simplest model, with a central-db that transparently and eventually only replicates read-only, hot-data specific to a DC but writes continue to incur heavy penalty in terms of operations-per-second, cost, and latency.

In our production setup, we back Workers KV with a single-region, source-of-truth DynamoDB [1] and employ DynamoDB Streams to push data to Workers KV [2], that is,

Writes (control-plane): clients -> (graphql) DynamoDB -> Streams -> Workers KV

Reads (data-plane): clients -> Workers KV

Reads (control-plane): clients -> (graphql) DynamoDB

[0] https://news.ycombinator.com/item?id=19307122

[1] We really should switch to QLDB once it supports Triggers.

[2] We do so mainly because we do not to be locked-down to Workers KV, especially at its very nascent stage.

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

#268
post #66

Earlier quoted context omitted.

You are mostly right, there are a surprising number of problems that don't need much database interaction. Lots of image generation, video workloads, game servers, etc. One of the things we want to do, though, is make "boring" apps really fast. My heuristic for this is "can you put a Rails app on fly.io without a rewrite?". Many of these applications add a caching layer. Normally if someone wants to make a Rails app…

I've seen https://macrometa.co take a stab at an edge database, but their guarantees (consistency / correctness) don't really infuse any sort of confidence in me [0]. https://yugabyte.com is another global scale database that competes squarely with cockroach-db, though I haven't used either. Cloudflare Workers KV has the simplest model, with a central-db that transparently and eventually only replicates read-only, ho…

Hi Ignoramus - founder and CEO of Macrometa here - regret that our first attempt at explaining our consistency model caused confusion last year. Here's a link to the research paper that describes our architecture and consistency model.

https://bit.ly/HPTS-Macrometa

We got accepted in High Performance Transaction systems last year for the innovations around CRDTs for strong eventual consistency (SEC) with low read and write latencies.

Im trying to figure out how to provide a simple light weight way for fly.io users to use our global DB in their apps. It would allow a full stack to run at the edge with the compute on fly.io and the data on Macrometa either directly on fly.io or a nearby PoP (same city). Will update

Post reply on HN