michaeldwan

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.

That's great to hear!

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 are responsive on GitHub.

We're going to expand there as soon as we can

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 :)

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 could certainly boot up a tiny app on fly that acts as a proxy from external apps into the fly redis.

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 awesome dashboards in grafana that we can't wait to expose to customers.

Awesome to hear!

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.

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 it!) and we're focusing on being an awesome place to run full stack apps and exotic (non-http) servers.

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 replicas which will be possible once we launch persistent storage. That said, latency between data centers on the same continent is often less than I would have thought!

You should also checkout something like FaunaDB.

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/

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 spot pricing on idle nodes, but that's far off.

Oh yes... I remember bitterly upgrading to a larger size just so >20 goroutines could use the same ~1mb of cached data.

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.

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.

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 several static and single page react apps into one less gross place.

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 centroid of  people in a session
  - server side rendering of single page js apps
  - route users to regional data centers for compliance
  - graphql stitching / caching (we do this!)
  - pass through cache for s3, or just minio as a global s3 (we do this!)
  - buildkite / GitHub Action agents (we do this!)
  - tensorflow prediction / DDoS & bot detection
  - load balance between spot instances on AWS/GCP
  - TLS termination for custom domains
  - authentication proxy / api gateway (we do this!)
  - IoT stream processing near devices

CloudFlare Workers is a fantastic serverless function runtime, but we're a layer lower than that. You can actually build it on top of fly.

edit: formatting

I'm not jassmith87, but they're making a super slick app builder at glideapps.com and using fly for custom domains

That's something we're certainly thinking about, but we need to get compute right first!

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 tens of seconds to a few hundred ms. Much of that infrastructure is actually running on fly itself!

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're also happy to help if you need!

We're on it!

Thanks for the kind words!

Yeah not yet. :sob: We're going to expand there and India as fast as we can.

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 point too. You can also configure min/max count globally and per region.

It seems like no two apps have the same scaling needs, so if you have any questions or can't make something work let us know and we'll help!

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 on the redis cache. It's usually not an issue anyway since apps are often distributed across many regions and many redis servers.

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, marketing pages, and some other things. It's really pleasant. We love graphql.

Thanks for the feedback. The landing page is very much a work in progress!

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 replicas which will be possible once we launch persistent storage. That said, latency between data centers on the same continent is often less than I would have thought!