michaeldwan

9 ms·

31.
by michaeldwan 6y ago
Our remote builders are just fly apps based on this image with an auth proxy in front. Works great https://github.com/superfly/rchab
32.
by michaeldwan 6y ago
Markdown + middleman. We use it for docs and landing pages in addition to the blog.
33.
by michaeldwan 6y ago
Fwiw we run as many services as we can on our own platform. Mission critical systems like our registry, api, redis servers, and much more are all running as fly apps in firecracker.
34.
by michaeldwan 6y ago
That's great to hear!
35.
by michaeldwan 6y ago
We're using Nomad to manage a large fleet of firecracker vms at fly.io. It's not as robust as k8s, but I think that's a feature. It's well documented, extensible, and predictable. Not a big community, but hashicorp folks
36.
by michaeldwan 7y ago
We're going to expand there as soon as we can
37.
by michaeldwan 7y ago
Not at the moment but it's certainly doable. Our CLI is written in go (github.com/superfly/flyctl) and could be ran as a go-plugin for terraform without rewriting the whole thing. I'd like that :)
38.
by michaeldwan 7y ago
Thanks for the kind words! Cockroach is awesome and it's something we'd like to offer someday. Until then checkout FaunaDB. Your push example is interesting. We don't have a way to connect to redis from outside fly, but you c
39.
by michaeldwan 7y ago
That's great to hear! Apps are allowed to burst over the limit if the host has free resources. We don't offer much visibility into metrics yet but we're working on it. All our metrics are going into prometheus with some aweso
40.
by michaeldwan 7y ago
Awesome to hear!
41.
by michaeldwan 7y ago
We're not running docker or making you run it. We simply use docker images (aka OCI image format https://github.com/opencontainers/image-spec ) as the packaging format for your application code and dependencies.
42.
by michaeldwan 7y ago
Thanks! We don't consider Zeit or Netlify competitors. We're a level lower than them -- you could actually run those things on top of fly! As you said, they're both going deep for JavaScript apps (and doing an awesome job at
43.
by michaeldwan 7y ago
from another thread: We're not solving db latency yet. A good place to start is aggressively caching at the edge. We offer an in-memory redis cache for this that can replicate commands globally. Beyond that you'd need read replica
44.
by michaeldwan 7y ago
We have some benchmarks comparing us to Heroku (on AWS) and the performance gains from faster networking alone are nothing to sneeze at: https://fly.io/blog/turboku/
45.
by michaeldwan 7y ago
We have some customers doing CPU heavy tasks like image and video processing, but we're not specifically optimizing for that right now. If there's demand we might offer better processors or GPUs for those workloads, or maybe even
46.
by michaeldwan 7y ago
Oh yes... I remember bitterly upgrading to a larger size just so >20 goroutines could use the same ~1mb of cached data.
47.
by michaeldwan 7y ago
Partially, and there's plenty of hosts that offer it. We're trying to make things like full stack Rails monoliths at the edge possible.
48.
by michaeldwan 7y ago
Middleman and a fantastic designer + writer! We've gotten so many comments about the docs, I wish we could open source something but it's tightly coupled to other things that aren't useful to anyone else.
49.
by michaeldwan 7y ago
Mostly because the path to here was not a straight one :) Our main Rails app does a bunch of things that can't run globally and it takes a long time to build while the customer facing app is a lightweight Rails app that consolidated se
50.
by michaeldwan 7y ago
There's a whole bunch of use cases people have today that don't require a database. Here's a few that I'm excited about: - image, video, audio processing near consumers - game or video chat servers running near the
51.
by michaeldwan 7y ago
I'm not jassmith87, but they're making a super slick app builder at glideapps.com and using fly for custom domains
52.
by michaeldwan 7y ago
That's something we're certainly thinking about, but we need to get compute right first!
53.
by michaeldwan 7y ago
We built something into our registry that squashes layers of an image into a compressed rootfs archive. Edge nodes map an image back to one of these files when launching an app. This cut launch time for large images in remote regions from
54.
by michaeldwan 7y ago
This is tricky since every app has different performance and budget constraints. We try to minimize footguns by starting with sensible defaults. Over time we'll provide more options so you can tune scaling and placement yourself. We&#x
55.
by michaeldwan 7y ago
We're on it!
56.
by michaeldwan 7y ago
Thanks for the kind words!
57.
by michaeldwan 7y ago
Yeah not yet. :sob: We're going to expand there and India as fast as we can.
58.
by michaeldwan 7y ago
That's correct, though we bill per second and scale back down when your app is over provisioned. Right now we always run 1 instance so your app responds right away after a period of inactivity. We might offer scaling to zero at some po
59.
by michaeldwan 7y ago
Glad to hear :) You're exactly right about the Heroku deploy. We convert your app's slug to a Docker image and launch the web process in it. DB & other dynos still run on Heroku. We don't have any hard connection limits o
60.
by michaeldwan 7y ago
This is exactly what we do! We have a Rails app exposing a graphql api for our cli and web app. The web app is a React SPA monster that we're replacing with another Rails app that runs at the edge and serves the customer UI, docs, mark

More ›