mrkurt

31 ms·

361.
by mrkurt 5y ago
No, the opposite actually. When the ad market fell apart we launched a paid subscriber program. It immediately turned us into an app that cared about a smaller number of high value users. Almost everything we wanted to add was for those fol
362.
by mrkurt 5y ago
Before we built Fly, I spent a huge amount of time trying to bend CDNs to my will. Fastly's surrogate keys are pretty good _if_ you define a good HTTP cache schema and if every request is worth caching. My general takeaway was that HTT
363.
by mrkurt 5y ago
You should email me. :D kurt at fly.io
364.
by mrkurt 5y ago
Rails view generation is shockingly slow. I would definitely cache partials, I just wouldn't run Redis to do it if I could help it! Rails is basically the worst case framework for our model, so we were excited when we got it working. Y
365.
by mrkurt 5y ago
It is a spicy take. I agree that Varnish and commodity CDNs are more efficient per pageview than hitting any kind of full stack app process. Most devs can probably ignore efficiency, though. Making things fast for users will take them a lon
366.
by mrkurt 5y ago
You do need the internal_port, you don't need `EXPOSE` though. Will you post your config file at https://community.fly.io so we can have a closer look?
367.
by mrkurt 5y ago
Stop making me feel old.
368.
by mrkurt 5y ago
You'll need [services] to accept public TCP traffic, just set `handlers = []` to turn off our TLS and HTTP layers. We do run a proxy so we definitely mess with your TCP traffic! You can enable PROXY protocol to get some of the original
369.
by mrkurt 5y ago
Yep. Anything you can build a Docker image for, but "fly launch" may just do the right thing for it.
370.
by mrkurt 5y ago
We added this yesterday! https://fly.io/docs/getting-started/dockerfile/ It's getting less non-obvious, I hope.
371.
by mrkurt 5y ago
Not many. I worked on Ars Technica back in the day, it's the most CDN-like workload you can imagine. We couldn't ship features we thought were valuable, though, because the CDN was in the way. CDNs have gotten better, and you can
372.
by mrkurt 5y ago
A few things here: 1. We pay basically the same prices for dedicated hardware you would. Hetzner is cheap, in part, because they run in a single facility and optimize for price. We run in 22 locations and optimize for "cheap enough for
373.
by mrkurt 5y ago
S3 or the equivalent is best, yes.
374.
by mrkurt 5y ago
This is probably a websockets bug that crops up during deploys – the connection breaks and reconnects keep getting sent to the now-gone VM for >60s. We're furiously rebuilding our service discovery plumbing because it's slow to
375.
by mrkurt 5y ago
Our Rails gem pins requests to the primary region until the data is replicated. We talk about this more here: https://fly.io/blog/globally-distributed-postgres/
376.
by mrkurt 5y ago
Most people need to do something on the gradient of "run in one city that's nearest my users" to "run in every city everywhere". We have excited single region users in Sydney, because the internet sucks for Australi
377.
by mrkurt 5y ago
This is why we don't say "edge". Most apps work best with 3-6 regions. Apps that benefit from ~20ms websocket round trips might use more.
378.
by mrkurt 5y ago
This is almost exactly Shopify's architecture. It's out of reach for 99.9% of devs. But really the answer is that AWS doesn't solve this for people. And AWS is the default hosting choice for most tech companies.
379.
by mrkurt 5y ago
The article you're responding to is exactly about Postgres. Here's Redis: https://fly.io/blog/last-mile-redis/ Here's a boring Rails app that uses Postgres: https://fly-global-rails.fly.d
380.
by mrkurt 5y ago
> It seems pretty clear cut to me that if your company hasn't been found guilty of discrimination in the past, then it's illegal for the company to institute "affirmative action." That's not what United Steelwork
381.
by mrkurt 5y ago
I forgot about the IP addresses, those are not cheap. But we own a bunch and can optimize that cost away really easily too. :)
382.
by mrkurt 5y ago
Ah I see what you're saying! You're basically describing our experience trying to run Discourse. Weirdly, naive, less complicated Rails apps work better multi-region on Fly than mature grownup Rails apps. We use sidekiq + Fly in a
383.
by mrkurt 5y ago
Yes there's a good chance for all of these! You can post on community.fly.io if you'd like and get a headstart. People have prebuilt Dockerfiles laying around for everything (and we have lost of Rust stuff). We use Dockerfiles kin
384.
by mrkurt 5y ago
That's all solved. We catch readonly errors from Postgres and issue the replay. Preemptively sending a POST to the primary region is an optimization, it works fine without doing that! Replication lag is handled too in the Ruby library
385.
by mrkurt 5y ago
Cloud Flare's model is to give you "unlimited" bandwidth with restrictions on how you can use it. If you do any kind of volume you quickly get a call from a sales person who wants to sell you enterprise. And then you end up p
386.
by mrkurt 5y ago
If you have Docker running locally, it does a local build and pushes to our registry. If you don't have docker running locally, it launches Docker on our infrastructure, sends it the context, and does a remote build. You can control th
387.
by mrkurt 5y ago
The nice thing about mapping peoples apps to overpowered hardware is that it flattens bursts. We need capacity for, say, 10% of apps to burst at any given time. The nice thing about spreading hardware around the world is that we have excess
388.
by mrkurt 5y ago
We don't bill for internal Postgres bandwidth anymore. Bandwidth in general is a good point though. No one _actually_ offers unlimited bandwidth. We haven't figured out how to be transparent about bandwidth costs AND check that bo
389.
by mrkurt 5y ago
I would start here, if you can get it running in Docker it's very easy to run on Fly: https://spring.io/guides/gs/spring-boot-docker/
390.
by mrkurt 5y ago
Ok this is a good and difficult question. For _our particular service_ this happens, but that's partially because the service is designed to scale to very large customers and the market has set a price for cloud computing resources. Co

More ›