- Mature CLI tool, easy to build into CI and/or API with JSON responses
- Docker based, so I can easily test my apps locally
- Well designed secrets management
- Well designed private networking if I need to log into running apps in any region
There are probably more, but those are the big ones I see from using Fly regularly
> I prefer https://fly.io - their dev experience is 10x better.
I really like Fly, but it’s not a straight comparison - Fly is a way to run OCI (“Docker”) images in a handful of locations across the world, with some helpful magicks to route users to the closest instance (provided you run them). Thus, the dev experience is… you’re building and running a container locally, just as you would in Cloud Run, Heroku or other services that run containers for you. That familiarity is nice (and certainly an intentional choice by Fly) but it’s hard to say it’s “theirs”.
Workers runs everywhere, simultaneously: all 200+ of their edge locations. They’re designed to be lightweight enough and don’t need “you” to scale them, or pick regions to deploy them into, but the trade-off is that the API & development workflow are more bespoke (a JS-based Service Worker like API). If I want to deploy something that can be as close to end-users as possible, or that can personalize responses from my origin or cache on-the-fly, I reach to Workers first.
tiffanyh|4 years ago
See my similarly related question in this thread below.
https://news.ycombinator.com/item?id=27750950
mikehostetler|4 years ago
- Mature CLI tool, easy to build into CI and/or API with JSON responses - Docker based, so I can easily test my apps locally - Well designed secrets management - Well designed private networking if I need to log into running apps in any region
There are probably more, but those are the big ones I see from using Fly regularly
elithrar|4 years ago
I really like Fly, but it’s not a straight comparison - Fly is a way to run OCI (“Docker”) images in a handful of locations across the world, with some helpful magicks to route users to the closest instance (provided you run them). Thus, the dev experience is… you’re building and running a container locally, just as you would in Cloud Run, Heroku or other services that run containers for you. That familiarity is nice (and certainly an intentional choice by Fly) but it’s hard to say it’s “theirs”.
Workers runs everywhere, simultaneously: all 200+ of their edge locations. They’re designed to be lightweight enough and don’t need “you” to scale them, or pick regions to deploy them into, but the trade-off is that the API & development workflow are more bespoke (a JS-based Service Worker like API). If I want to deploy something that can be as close to end-users as possible, or that can personalize responses from my origin or cache on-the-fly, I reach to Workers first.