Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
mrkurt
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
8 ms
·
61.
▲
by
mrkurt
3y ago
This needs to support any ol' wireguard client. We use it in `flyctl` but people also use it to create gateways so they can, eg, peer with VPCs.
62.
▲
by
mrkurt
3y ago
(I am bias because I work on Fly.io) Fly Machines are more powerful than Google Cloud Run IMO. You can treat them like cloud run, or manage them directly and implement your own Serverless model. Our PaaS orchestration is implemented entirel
63.
▲
by
mrkurt
3y ago
We have some ideas but there's no clear answer yet. Probably people building hosting platforms. Maybe not obvious hosting platforms, but hosting platforms.
64.
▲
by
mrkurt
3y ago
Passthrough, yes.
65.
▲
by
mrkurt
3y ago
You might actually be better off building a gaming rig and using that. The datacenter GPUs are silly expensive, because this is how NVIDIA price discriminates. The consumer, game GPUs work really well and you can buy them for almost as chea
66.
▲
by
mrkurt
3y ago
The simple spoiler is that the GPU machines use Cloud Hypervisor, not Firecracker.
67.
▲
by
mrkurt
3y ago
Machines are both dumber and more powerful than you'd think. Scaling down means just exit(0) if you have the right restart policy set. So you can implement any kind of keep-warm logic you want.
68.
▲
by
mrkurt
3y ago
You control machine lifecycles. To scale down, you just set the appropriate restart policy, then exit(0). You can also opt to let our proxy stop machines for you, but the most granular option is to just do it in code. So yes, kind of. You j
69.
▲
by
mrkurt
3y ago
We charge from the time you boot a machine until it stops. There's no enforced minimum, but in general it's difficult to get much out of a machine in less than 5 seconds. For GPU machines, depending on data size for whatever is go
70.
▲
by
mrkurt
3y ago
They all need to make margins on top of aws/gcp expenses. Its just a knock on effect from such expensive public cloud egress.
71.
▲
by
mrkurt
3y ago
We actually have first class SQLite support on Fly.io with LiteFS. You should be able to run a Rails app for ~$5 per month in that config.
72.
▲
by
mrkurt
3y ago
Is this true? I assume there must be founders who won't start companies if they can't get acquired, but I'm not one of them. And I think my closest friends aren't either.
73.
▲
by
mrkurt
3y ago
I would love to hear your reservations. We've made some choices for simplicity that I expected us to have to engineer around, but a surprising number of them haven't been problems in practice. In short, I have reservations too.
74.
▲
by
mrkurt
3y ago
You're saying a single server failure is going to to cost your business half a million dollars? This was a server with local NVMe storage. The simplest thing to do would have been to just get rid of it, but we have quite a few free use
75.
▲
by
mrkurt
3y ago
This was a single physical server running multiple VMs using local NVMe storage. It impacted a small fraction of customers.
76.
▲
by
mrkurt
3y ago
I am skeptical that Hetzner or OVH or similar could get off the ground starting in 2023. There are a couple of things working against a boostrapped public cloud: First, you gotta buy expensive kit. And then hope you can make your money back
77.
▲
by
mrkurt
3y ago
Basically, LiteFS: https://github.com/superfly/litefs And then some load balancer cleverness that reroutes writes to a specific VM: https://fly.io/blog/globally-distributed-postgres/
78.
▲
by
mrkurt
3y ago
Roughly this, yes. It's easy to run boring apps close to your users. Thus, people buy computer time from us instead of a place that runs in one city.
79.
▲
by
mrkurt
3y ago
A 1GB Fly machine is ~$5.70/mo (we charge by the second, some months are better than others). Persistent volumes are $0.15/gb each. Not too far off, depending on how much data you have. However the platform has different tradeof
80.
▲
by
mrkurt
3y ago
I don't think we can build a company like this without a lot of money. We're to the point where we're making $10-25mm capital expenditures in one go. And we have to to optimize our own costs. Optimizing our own costs means
81.
▲
by
mrkurt
3y ago
Local NVMe makes this a much more fun project than it would have been 10 years ago.
82.
▲
by
mrkurt
3y ago
I don't want to sound flippant, because this is hard as fuck, but the profitability path for us is reasonably simple: have good unit margins, attract customers, help them grow. We have good unit economics. The riskiest, most terrifying
83.
▲
by
mrkurt
3y ago
This effect is bananas . The internet feels remarkably different in Sydney and Tokyo than it does in Chicago.
84.
▲
by
mrkurt
3y ago
We couldn't raise prices for VMs even if we wanted to. You can buy 'em from a million different places. It's pretty easy to move off, though. `fly launch` generates a Dockerfile you can run pretty much anywhere.
85.
▲
by
mrkurt
3y ago
Most of Heroku's revenue is from Postgres. They're arguably a managed Postgres provider with some app hosting tooling (this is not fair, but an interesting way to think about Heroku). We're not Heroku. We _like_ how amazingly
86.
▲
by
mrkurt
3y ago
They should, probably. We have partner-like customers who are paying actual hardware costs and then a platform fee for us to manage it. You can only build so many company margins on top of capital expenditures.
87.
▲
by
mrkurt
3y ago
I was planning an "Our incredible journey" post, but "We razed a bunch of money" is much better.
88.
▲
by
mrkurt
3y ago
The simple answer is: we sell something people want to pay for (VM time, network services, etc). We'll obviously want to improve our margins over time, but there's a market price for this stuff and we don't have pricing power
89.
▲
by
mrkurt
3y ago
We use Equinix Metal / Packet in some places, our own hardware + colo in others, and something close to colo/hardware in more.
90.
▲
by
mrkurt
3y ago
Oh, I guess that could sound snarky. I wasn't feeling snarky, though. We are the wrong place for a lot of people to work.
More ›