Sadly, we have all seen these promises, "X makes Y much easier" but you cannot make complex things easy without removing lots of functionality.
Kubernetes for the basics is actually pretty easy despite what people say, I got a fairly simple cluster running with little pain but...it doesn't take long before you want multiple clusters, or vlan peering, or customising the DNS or.... and that is when it becomes complex.
What will fly.io do? Probably what everyone else does, starts simple, becomes popular and then caves in to the deluge of feature requests until they end up with an Azure/AWS/GCP clone. If it stays simple, lots of people will say that you will outgrow it quickly and need something else, if you increase functionality, you lose your USP of making infrastructure easy.
I think perhaps the abstractions are the problem, if you are abstracting at the same level as everyone else e.g. docker images, orchestration etc. then I don't understand how it can ever work differently.
To make my point, the very first comment below (above?) is about container format, a really fundamental thing that noobs are not likely to know about, they will just immediately have some kind of error.
You definitely can't make complex things simple just by removing features.
What we did, instead, was built low level primitives, then built opinionated PaaS-like magic on top of those.
If you're running a Phoenix app, `fly launch` gets you going, then `fly deploy` gets you updated.
If you want to skip the PaaS layer and do something more intense, you can use our Machines API (or use Terraform to power it) and run basically anything you want: https://fly.io/docs/reference/machines/
We are very, very different than k8s. In some ways, we're lower level with more powerful primitives.
We probably won't build an AWS clone. I don't think devs want that. I also don't think devs want a constrained PaaS that only works for specific kinds of apps.
I think want devs want is an easy way to deploy a boring apps right now, and underlying infrastructure they can use to solve bigger problems over time.
I'm a dev. That's what I want. I want something publicly visible that I can get running in the first sprint so I can show everyone what my idea is looking like as it progresses. I want setting up the DB and certificates to be easy. I want a static IP to point my domain to. I want it all to just work if I have the source code and I tell it to deploy. I want secrets to be included so I don't have to stand up Vault or something. I don't want to set up my own Jenkins. I don't want to deal with resizing volumes in k8s. I don't want to dick with networking rules/configurations that allow my frontend to talk to my backend and my backend to my DB.
I also don't want to set up my own log aggregator, grafana, and prometheus/alert manager, but for a quick "show everyone your app", I don't need those. I can add that harder crap later when the app shows promise and I actually need to debug performance.
> What will fly.io do? Probably what everyone else does, starts simple, becomes popular and then caves
No, mrkurt will not cave, I can guarantee you that. Fly will be a platform that says no to feature requests that don't make sense for their customer base.
I have no affiliation with Fly, other than I've used it on and off since the beginning of the platform's existence. They're a veteran team that knows how to build platforms. I definitely trust them to go in the right direction with their roadmap, and all my new projects go on Fly.
Have other people invested money in them? If that's the case, sooner or later they don't call the shots, but rather who owns the capital and wants it to grow.
> it doesn't take long before you want multiple clusters, or vlan peering, or customising the DNS
Then, Fly is not for such an application. Just not yet. I mean, we wouldn't buy a snowboard and complain we couldn't go skiing. Different tools.
The point really is, for a similar thing that which Fly is capable of (and other NewCloud services to an extent like railway.app, render.com, replit.com, convex.dev, workers.dev, deno.com, pages.dev, vercel.com, temporal.io etc), you're better off NOT using AWS/GCP/Azure. I certainly have found it to be true for whatever toy apps I build.
> Sadly, we have all seen these promises, "X makes Y much easier" but you cannot make complex things easy without removing lots of functionality.
There's certainly a limit, but it makes me so sad that developers see the current state of orchestration and say “welp, it's a complex problem, guess this is as good as it gets” (not you specifically, but it's a common sentiment on HN.)
Sure, there will always be use cases that require getting down to a lower level, but there's definitely space for reducing complexity for common use cases.
Yeah it's neat but idk who the target market for this is. I can run a custom-designed site with all sorts of features using WordPress.com or Shopify or Hubspot. Once I need a real platform and backend services, you'll need a team that can spin up Docker images in AWS or the like and the full gamut of DIY platform tools. Platforms like fly.io appeal to semi-mature orgs but they will either die or outgrow it pretty quickly.
It sounds like you’re commenting in general terms without having looked at what Fly.io is actually doing. Yes, choosing the right abstractions is the problem, and what makes Fly.io really interesting is that they chose different ones. It’s really well explained in their docs and blog posts.
Having to read through docs and blog posts to understand what unique abstractions doesn't help those asking. I've read through docs, blog posts, etc. It's for developers who don't want to setup and maintain an environment. Other providers offer this. You end up paying far more than a five dollar droplet in most cases and a lot more than the free Oracle tier offers but much less compared to big cloud like AWS. They offer a free tier and a community helping onboarding. The goal is ecosystem lock-in and they provide enough to win over a certain group in the middle. The fear is the freebies given today will be paid for by the lock-in effects tomorrow.
Spent last night migrating a Discord bot from Heroku to Fly as a result of the upcoming closure of the Heroku free dynos. Overall fairly painless, though I opted to provide my own images rather than use a source-to-image pipeline and discovered one little quirk: images require a Docker V2 formatted manifest. I use Buildah and Podman in my workflows which default to the OCI format. This was simple enough to solve once I figured it out, but I only found one or two forum posts on it and spent a lot of time trying to figure out why the deployment couldn't find an image that I manually pushed to registry.fly.io.
Yeah, I use Buildah for creating my images, so the environment variable or specifying commit --format docker would work. Before I did that I just re-pushed the image itself using the v2s2 format, so:
The NFS kernel module isn't installed, so you can't use EFS. (They suggest some 3rd party userland tool)
They expect you to set up VPN access with Wireguard for any connections to your containers. You can't just SCP your files to a volume. It's so much more hassle than connecting with kubectl cp or scp, especially if you're hoping to script things.
All that said, I'm happy to see competition in the "we'll run your docker image" space.
This all seems fair. Just a note: we don't generally expect our users to "set up" WireGuard --- we bake it into `flyctl`, our CLI, which automatically brings up WireGuard sessions as needed. A month or so ago I merged a PR to add sftp support to our SSH server; sftp probably works now with "native" WireGuard, and when I get unburied I'll work out an sftp client interface for `flyctl` itself.
It's a rough edge, to be sure! I just wouldn't want to leave it as "we think the status quo is the right way to handle getting files to and from instances".
Although I would say that cron isn’t a great solution for containerized apps on most platforms, it seems like scheduled processes need a rethink for todays infra.
We're building serverless scheduled processes, queues, and event-driven systems at https://www.inngest.com/. It's early days, and we agree — they've needed a refresh to adapt to modern practices.
We just released scheduled machines that will help with this. It's similar to the scheduler add-on in heroku and supports general intervals (hourly, daily, weekly, monthly). Feature announcement here -> https://community.fly.io/t/new-feature-scheduled-machines/73...
I've been using Fly for 2 years now. Overall I'm very happy and I recommend it to everyone.
If you just want to run a container in multiple regions with anycast, Fly is really the best option out there IMHO. Nothing comes close.
There are some rough edges for certain use cases but they keep polishing the service and the DX keeps getting better.
Personally the only features I'm missing today are:
- PG backups/snapshots. AFAIK these are coming in the form of virtual disk snapshots.
- Scale apps from zero to say 100 VMs like Cloud Run does. There's some autoscaling right now and the machines API, but still needs more polish. Specially for certain use cases like concurrent CPU heavy tasks (video encoding, etc). AFAIK some form of this is also coming in the next months.
Haven't used fly.io but strongly considering migrating over from Heroku and above is roughly what I would say is a good fit for Heroku so hopefully it's the same on fly.io
The thing is about all these tools is that starting out with a simple VPS is much more cost effective?
https://contabo.com has 4 cores for 5€ and you can scale up to 10 cores and 60 gb ram for 27€ a month.
And if you need dedicated cores 12 cores with 96GB is 130€ vs 8 dedicated cores with 64 GB ram for 550€
Choose a docker image and just docker-compose up your application.
If you outgrow that, you might aswell switch to kubernetes and aws/gcp/azure
If you don’t need edge compute (which you do if you have customers dispersed geographically) then what you say is true.
But if you do no amount of Kubernetes on the old school cloud providers is going to get you there. You will encounter the hard problems fly solves for.
One possibility is that they have fewer regions than something like AWS, so they can put their data centers somewhere where they get favorable electricity/cooling costs.
Readit News
Kubernetes for the basics is actually pretty easy despite what people say, I got a fairly simple cluster running with little pain but...it doesn't take long before you want multiple clusters, or vlan peering, or customising the DNS or.... and that is when it becomes complex.
What will fly.io do? Probably what everyone else does, starts simple, becomes popular and then caves in to the deluge of feature requests until they end up with an Azure/AWS/GCP clone. If it stays simple, lots of people will say that you will outgrow it quickly and need something else, if you increase functionality, you lose your USP of making infrastructure easy.
I think perhaps the abstractions are the problem, if you are abstracting at the same level as everyone else e.g. docker images, orchestration etc. then I don't understand how it can ever work differently.
To make my point, the very first comment below (above?) is about container format, a really fundamental thing that noobs are not likely to know about, they will just immediately have some kind of error.
What we did, instead, was built low level primitives, then built opinionated PaaS-like magic on top of those.
If you're running a Phoenix app, `fly launch` gets you going, then `fly deploy` gets you updated.
If you want to skip the PaaS layer and do something more intense, you can use our Machines API (or use Terraform to power it) and run basically anything you want: https://fly.io/docs/reference/machines/
We are very, very different than k8s. In some ways, we're lower level with more powerful primitives.
We probably won't build an AWS clone. I don't think devs want that. I also don't think devs want a constrained PaaS that only works for specific kinds of apps.
I think want devs want is an easy way to deploy a boring apps right now, and underlying infrastructure they can use to solve bigger problems over time.
I also don't want to set up my own log aggregator, grafana, and prometheus/alert manager, but for a quick "show everyone your app", I don't need those. I can add that harder crap later when the app shows promise and I actually need to debug performance.
No, mrkurt will not cave, I can guarantee you that. Fly will be a platform that says no to feature requests that don't make sense for their customer base.
I have no affiliation with Fly, other than I've used it on and off since the beginning of the platform's existence. They're a veteran team that knows how to build platforms. I definitely trust them to go in the right direction with their roadmap, and all my new projects go on Fly.
I concur.
Fly is not your typical startup with dreams of becoming the next big corp monster.
They are just a bunch of talented people with a vision having fun making cool stuff.
https://fly.io/docs/getting-started/multi-region-databases/
Then, Fly is not for such an application. Just not yet. I mean, we wouldn't buy a snowboard and complain we couldn't go skiing. Different tools.
The point really is, for a similar thing that which Fly is capable of (and other NewCloud services to an extent like railway.app, render.com, replit.com, convex.dev, workers.dev, deno.com, pages.dev, vercel.com, temporal.io etc), you're better off NOT using AWS/GCP/Azure. I certainly have found it to be true for whatever toy apps I build.
There's certainly a limit, but it makes me so sad that developers see the current state of orchestration and say “welp, it's a complex problem, guess this is as good as it gets” (not you specifically, but it's a common sentiment on HN.)
Sure, there will always be use cases that require getting down to a lower level, but there's definitely space for reducing complexity for common use cases.
The question is whether customers need or want that "functionality".
https://docs.podman.io/en/latest/markdown/podman-manifest-pu...
Wonder why they don't use OCI format.
Deleted Comment
Your server doesn't have a static IP for outgoing requests, so to use it with RDS, you can't just open up a port on the RDS side. (They want you to set up your own proxy) https://community.fly.io/t/set-get-outgoing-ip-address-for-w...
The NFS kernel module isn't installed, so you can't use EFS. (They suggest some 3rd party userland tool)
They expect you to set up VPN access with Wireguard for any connections to your containers. You can't just SCP your files to a volume. It's so much more hassle than connecting with kubectl cp or scp, especially if you're hoping to script things.
All that said, I'm happy to see competition in the "we'll run your docker image" space.
It's a rough edge, to be sure! I just wouldn't want to leave it as "we think the status quo is the right way to handle getting files to and from instances".
Deleted Comment
If you just want to run a container in multiple regions with anycast, Fly is really the best option out there IMHO. Nothing comes close.
There are some rough edges for certain use cases but they keep polishing the service and the DX keeps getting better.
Personally the only features I'm missing today are:
- PG backups/snapshots. AFAIK these are coming in the form of virtual disk snapshots.
- Scale apps from zero to say 100 VMs like Cloud Run does. There's some autoscaling right now and the machines API, but still needs more polish. Specially for certain use cases like concurrent CPU heavy tasks (video encoding, etc). AFAIK some form of this is also coming in the next months.
I am very skeptical of this claim.
Just curious about other's people definition, as I imagined Fly.io as a more self-served BaaS (mostly for web applications)
- startups, small teams, no devops.
- horizontally scalable monoliths.
- no complex infra needs.
Haven't used fly.io but strongly considering migrating over from Heroku and above is roughly what I would say is a good fit for Heroku so hopefully it's the same on fly.io
Choose a docker image and just docker-compose up your application.
If you outgrow that, you might aswell switch to kubernetes and aws/gcp/azure
But if you do no amount of Kubernetes on the old school cloud providers is going to get you there. You will encounter the hard problems fly solves for.
Unless data is geographically sharded as well, is there really a benefit? Collaborative apps perhaps?