mrkurt

15 ms·

151.
by mrkurt 4y ago
There's no bailout. SVB is dead. People are pushing for depositors to get their money back. Which is, I think, reasonable. Putting your company money in a bank account should be safe. We should regulate banks like SVB to make it more s
152.
by mrkurt 4y ago
SVB was the place investors told companies to put money. SVB was also somewhat difficult to work with, they created a tremendous amount of pressure to do all your banking with them. And SVB didn't have products that would help you maxi
153.
by mrkurt 4y ago
If this was just Roku money, I doubt there would be an uproar. This hit a lot of very small startups with, like, $2mm and 14 months to live. These are not sophisticated companies.
154.
by mrkurt 4y ago
This is an excellent description.
155.
by mrkurt 4y ago
Yeah, basically that. One of the servers in our Vault cluster failed and prevented Vault agents from receiving secrets. For Nomad apps, this showed up as "allocation failures" and failed deploys. Machine based apps took an abnorma
156.
by mrkurt 4y ago
This is, indeed, the exciting part. As Heroku fans, we never really felt like it needed a replacement. And if it did, it seemed like Render was the natural Heroku v.next. One thing we've noticed, though, is that people do actually want
157.
by mrkurt 4y ago
Oh my god that's a great callback.
158.
by mrkurt 4y ago
I feel this. I hope you get over the hump and your job gets fun. We've had flashes, at least, but I do think what we're doing (and probably what you're doing) require some irrational behavior.
159.
by mrkurt 4y ago
Yes we think they pair well together too. I believe the ball is in your court though. ;)
160.
by mrkurt 4y ago
We don't autoscale apps by default, you have to opt in to that. Many apps don't need or want that functionality.
161.
by mrkurt 4y ago
I am so confused about what you're describing here. Apps get static IPs, at no point would you need to make a DNS change to route traffic to a new instance. VMs can definitely fail silently. When apps fail, we're not very good at
162.
by mrkurt 4y ago
The costs of the VMs scale linearly. The bigger they get, the more additional capacity we need to be able to launch on demand ones. It's not just RAM, though, our physical servers have a consistent ratio of RAM/CPU/disk avail
163.
by mrkurt 4y ago
We don't suddenly charge people. We charge per VM you have running. Setting these up is intentionally manual. You can opt in to autoscaling, which will create new VMs for you, but you have to set that up after you've deployed your
164.
by mrkurt 4y ago
You'll notice that the ones they feature most are IPOs. Which isn't the same as getting acquired. I'm not opposed to an IPO, I am opposed to get subsumed by a larger company.
165.
by mrkurt 4y ago
We aren't super interested in selling. I want to work on Fly forever and selling is a quick way to end that. But I also don't think you can build a from-scratch cloud without VC money. It's very expensive.
166.
by mrkurt 4y ago
These deploy issues are all kinds of ulcer inducing. They're not strictly Nomad's fault (we're holding it wrong), but the complexity of flyctl -> nomad -> global hosts makes it difficult to bubble errors back up to you.
167.
by mrkurt 4y ago
No, we don't flag accounts as high risk based on email domain.
168.
by mrkurt 4y ago
It'll definitely be better in a year. It sounds like you hit some of our capacity issues. In a year we'll either be ahead of those, or not growing anymore due to ongoing capacity issues. I'm hoping for the former. The SSH and
169.
by mrkurt 4y ago
We don't charge credit cards to try and remove the fraud flag. We do a preauth, which is immediately canceled. Sometimes this looks like a charge.
170.
by mrkurt 4y ago
Well Nomad certainly isn't at fault for our docs. Volume provisioning issues have been a game of whackamole, largely as the result of scaling pains. We've grown like 4x in the last 3 months (thanks, Heroku) and it's put a str
171.
by mrkurt 4y ago
The TLS cert renewal was a big failure on our part. I know that's, like, a one strike and you're out problem, but we've improved that part of our stack substantially. It should be much more resilient. Redis/Postgres time
172.
by mrkurt 4y ago
Will you email your app details to support (cc me too, if you want). If you're app is 502ing, it's unrelated to yesterday's outage.
173.
by mrkurt 4y ago
We built Fly.io to treat chronic NIH syndrome.
174.
by mrkurt 4y ago
The newest buildkit shipped a regression. This broke the Docker go client and containerd's pull functionality. It has been a mess: https://community.fly.io/t/deploying-to-fly-via-github-actio...
175.
by mrkurt 4y ago
thank you.
176.
by mrkurt 4y ago
I read "quantify" a little ambiguously, possibly because I'm projecting. For me, it's enough to be able to explain the potential customer value. And this often happens after the fact. We actually try to get people here t
177.
by mrkurt 4y ago
> I, for one, find it's important that the team can always quantify how every feature adds value to customers. Are you me?
178.
by mrkurt 4y ago
Yes. In my experience, it's substantial. 200 servers in colo == maybe 1 failure every 6 months. 200 EC2 instances, one per month. These are different things, though. If you're using AWS, you would build to account for this.
179.
by mrkurt 4y ago
Faster disks, no control plane to fail, simpler network, etc. This isn't bias speaking, I work on Fly.io, our VMs are less reliable than EC2 VMs. AWS's pitch is that all the extra complexity in their infrastructure benefits you. S
180.
by mrkurt 4y ago
Only if they sell into the market. Almost no one who vertically integrates competes in the market they just shook. You can't get Amazon to ship things for you, so they don't compete with Fedex and UPS. You can't by an M1 chip

More ›