mrkurt

40 ms·

511.
by mrkurt 5y ago
This is super interesting and I have an immediate feature request. If we could use this to coordinate travel we'd be all over it. We're geographically disbursed and getting people together in the same city is valuable, but a pain.
512.
by mrkurt 5y ago
How did you track your time? I kind of love this idea but time tracking is a pain in the ass. Seems like maybe you could use "day" or "half day" granularity?
513.
by mrkurt 5y ago
Isolated VM is a decent way to use lower level v8, but replicating "fetch" and the other CF workers primitives is a big chunk of work: https://github.com/laverdet/isolated-vm Deno is the best OSS out there fo
514.
by mrkurt 5y ago
That's our answer, yes. Read replicas and we redirect requests that need writes to a "primary" region: https://fly.io/blog/globally-distributed-postgres/ We tried cross region database calls for HTT
515.
by mrkurt 5y ago
They confuse the heck out of me too. The world of VM CPU pricing is bonkers.
516.
by mrkurt 5y ago
Oh we're _working_ on it, but we have a ways to go. I can imagine `fly launch` just working for all Elixir apps someday, right now you have to write a Dockerfile. People seem to like our guide but I don't want to suggest it's
517.
by mrkurt 5y ago
vCPU can mean entirely different things between providers, which sometimes makes it hard to compare prices. In general, we treat "vCPU" as a single hardware threads, which is pretty common. Our hosts use Epyc CPUs with two threads
518.
by mrkurt 5y ago
Kata containers are QEMU based, so they use similar KVM virtualization as firecracker. QEMU is larger in scope than Firecracker, though, so you can (among other things) expose GPUs and other devices to the QEMU based containers. We picked F
519.
by mrkurt 5y ago
Firecracker and katacontainers (and other KVM based "containers") are valuable for multiple tenants that don't trust each other. They are less helpful if you trust what you're running. In fact, a Fly Firecracker VM is no
520.
by mrkurt 5y ago
If nothing else, we hope to make Fly.io a great place to deploy Elixir side projects. :)
521.
by mrkurt 5y ago
It's not a stupid question. The simplest is to look for a "business lawyer" and then ask them about their experiences with businesses like yours But also, don't overestimate what a lawyer is going to do. They're not
522.
by mrkurt 5y ago
Fly.io | SREs | Remote | Full-time Fly.io takes container images and converts them into fleets of Firecracker VMs, running on our own hardware around the world. It's easy on Fly to run applications close to users, no matter where they
523.
by mrkurt 5y ago
We don't have a firm roadmap for future regions, but Seoul is high up on my wish list. Our infrastructure is all dedicated hosts, mostly running in Equinix facilities (we buy a lot of servers from what used to be packet.com). New regio
524.
by mrkurt 5y ago
Stale replicas are a "stop serving requests from a particular region" problem. We pretty aggressively monitor these and consider things broken if replication is lagged more than about 10s. One thing about running thousands of DB c
525.
by mrkurt 5y ago
It does, and we need to update our docs with this. We buffer up to 1mb of request data to be possibly replayed. We can set that arbitrarily high, it just seemed like a reasonable starting point.
526.
by mrkurt 5y ago
Oh yes, that is a fair point. I'm specifically talking about the type of requests that always take 500ms. Almost every HTTP request from Australia to the US takes ~500ms. This is meant to decrease the unfixable latency, it's proba
527.
by mrkurt 5y ago
I definitely like writing the story parts, and the actual replay header is about halfway down. So you're right about that. But it really does result in globally distributed postgres.
528.
by mrkurt 5y ago
We should have definitely linked to these docs, I appreciate you asking and it sounds like you all managed to figure everything out though: https://fly.io/docs/getting-started/multi-region-databases/
529.
by mrkurt 5y ago
You got it. We can give people a library that catches Postgres readonly errors and make it a reasonably standard experience. We can't ensure that peoples' apps have good write hygiene. We _can_, though, educate people and tell the
530.
by mrkurt 5y ago
So far, yes they're ok with that. We can also optimize most of that number away, down to <10ms for almost every app. They're ok with it because a (valuable) write request that's 10% slower typically comes after a read requ
531.
by mrkurt 5y ago
simonw was referencing the replay overhead number. His request hits Los Angeles first, the rails app in lax says "go to Sydney", and the request gets replayed in syd. The entire request to Sydney for me (from Chicago) takes 516ms,
532.
by mrkurt 5y ago
We are at the stage where attracting developers and scaring suits is probably good. I'd have a hard time calling something I was partially responsible for elegant, though, so this might just be our self deprecating nature rearing its h
533.
by mrkurt 5y ago
It's true! We designed this specifically because it works with GraphQL. The exception->replay works by default, and it's easy to send early replay command on GraphQL mutations.
534.
by mrkurt 5y ago
INSERT, DELETE, UPDATE will all fail in the readonly regions. This is normal for Postgres read replicas, we're not doing anything special here. What we're doing works identically to a vanilla HTTP based app. Requests that modify t
535.
by mrkurt 5y ago
I, too, do jerky things sometimes. ;)
536.
by mrkurt 5y ago
It will always be hard. Consistency + latency is a huge problem. We can give _most_ developers the benefit of globally distributed postgres without causing consistency issues, though. Read replicas are simple to think about and reasonably e
537.
by mrkurt 5y ago
We're talking about a different level of "easy" I think. Easy: asking devs add a gem to their app. Hard: asking them to write migration code of any kind, much less understand tablespaces and replica placement. You're ad
538.
by mrkurt 5y ago
HTTP is cheap! Latency is expensive, but all our HTTP shenanigans happen between our proxy and user VMs. We're not inflicting multiple requests on slow clients at a ski resort.
539.
by mrkurt 5y ago
We tried running something like pgpool's split write setup, where the app or a proxy in front of the DB knows where to send transactions: https://www.pgpool.net/docs/latest/en/html/runtime-config-lo.
540.
by mrkurt 5y ago
This is a good way to do it. Catching errors lets us reliably ship a library that makes this work for almost everyone, but it's not right for all apps: https://github.com/soupedup/fly-rails/blob/main&#x2F

More ›