19 ms·

Fly.io: The reclaimer of Heroku's magic

528 points by sealeck 4y ago

st3fan 4y ago
For me the missing bit in Fly is scheduled tasks. I know how to solve this by spinning up an app that runs permanently as a scheduler, but basic cron-like scheduling should be part of the platform IMO. All other FaaS-like service do this.
- tptacek 4y ago
  I'd love to do this, if for no other reason than I hate working with cron. What would you use it for? What would the ideal version of this feature look like for you? What kind of apps would you be more easily able to ship? Is it mostly so you wouldn't need to keep a single tiny running VM sitting around running cron?
  - st3fan 4y ago
    Some apps are just that - a periodic task. Nothing more. Ideally a task project would have a git repo with a short fly.toml, a requirements.txt and a main.py. (In case of Python. I'm not familiar with using other languages on fly.io) I don't think it needs to be more complicated than that.
  - DizzyDoo 4y ago
    The sort of things I have had running on a schedule (using Celery[0] or something like it) are sending a set of emails at a certain time, running a report or generating the data for reports, even running a backup of some data. [0] - https://docs.celeryq.dev/en/stable/userguide/periodic-tasks.html https://docs.celeryq.dev/en/stable/userguide/periodic-tasks....
  - krn 4y ago
    > What would the ideal version of this feature look like for you? I think that Render solved "Cron as a Service" beautifully: https://render.com/docs/cronjobs https://render.com/docs/cronjobs
    - st3fan 4y ago
      I would use render but fly.io persistent storage is a killer feature. It is literally 100x simpler to just deal with files on a real file system than having to deal with remote object storage.
      - anurag 4y ago
        Render has persistent disks! https://render.com/docs/disks https://render.com/docs/disks. We need to expose them for cron jobs though.
  - joseph 4y ago
    I'd like to do any one-off job, not only scheduled ones; retrieving data and transforming or storing it, scraping a web page, running a database migration. My biggest annoyance with Fly is the assumption that everything is a long running application.
    - mrkurt 4y ago
      Don't tell anyone, but you can try "fly machines run" (currently only in a new, empty app). Then "fly machine start <id>" to start the thing back up after it exits. It's not released yet, though.
    - kevlened 4y ago
      I'm not sure how Fly handles one-off tasks behind the scenes, but we're building task queues (w/ cron) as a first class citizen at https://tasker.sh https://tasker.sh
mardix 4y ago
Heroku is getting hammered like crazy this week on HN
colesantiago 4y ago
- Bilal_io 4y ago
  Edge on Android with the built-in AdBlock Plus prevented all ads from showing up.
- sealeck 4y ago
  I mean you could just install an ad blocker.
- normie3000 4y ago
  No ads for me either
deleted 4y ago
[deleted]
normie3000 4y ago
How mature is fly.io?
- throwawaycuriou 4y ago
  Define mature
- mrkurt 4y ago
  We are DigitalOcean circa 2015 mature. Good enough for some very large customers, good enough for many developers, not some place I'd run pacemaker infrastructure.
  - indigodaddy 4y ago
    Does anyone run pacemaker on non-baremetal? Can you even? I’m aware you’re just using it as an analogy/example, but was just wondering..
    - antod 4y ago
      I did run some VRRP or CARP stuff (forget the specific tool/protocol - but that's kinda like pacemaker right?) in an immature OpenStack cloud once that didn't have a good LBaaS yet. It was a semi supported hack documented by the provider.
    - ecnahc515 4y ago
      FWIW, I'm pretty sure OP was referring to literal pacemakers, as in, the things that keep people's hearts beating.
  - sanjayio 4y ago
    Where would you feel comfortable running pacemaker infra? Half-joking here.
    - deleted 4y ago
      [deleted]
2c2c2c 4y ago
There's a lot of chat about fly.io on HN. possibly just because the founders and friends are posters here. Is there any in depth comparison between them and render.com ?
- atonse 4y ago
  I think it is because they are refreshingly open about their stack and people love their writing tone. And the architecture seems solid.
  - sanjayio 4y ago
    Agreed, really enjoyed their tone on explaining SQLite and litestream.
- mavbo 4y ago
  Not in-depth, but two things that have stood out to me in assessing Render vs Fly are Render's lack of Multi-region apps and release phase scripts for running migrations. Easy multi-region apps seem to be a main selling point of Fly. However, both of the features I mentioned are on Render's roadmap (Multi-region apps has been on their roadmap since 2019, so maybe not a priority?)
  - matthewcford 4y ago
    these were the reasons we chose fly in the end; very happy with it
- jchw 4y ago
  As an occasional third-party Fly “shill” of sorts, I mainly talk about Fly because I’ve really wanted almost exactly what Fly does for a long time now. I’d tried other things like Hyper, Fargate and Cloud Run, but they’ve mostly been disappointing in some regards, being cumbersome to use or get started with, unrealistically expensive, or simply being too slow or limited. Fly is none of that. It still has some stuff that’s lacking; resizing disks is probably the biggest thing missing; the proxying is surprisingly complete but UDP services are a little awkward; copying data in and out is somewhat tricky, you have to use SSH but over a wireguard tunnel with an ephemeral SSH key and on Windows it’s not particularly fun. (I don’t think SCP is supported either, which is fine, but still.) It remains exciting nonetheless because it scratches an itch that I don’t feel anyone else has really managed to; Netlify and Vercel and probably Cloudflare Pages does static sites very well, but Fly feels like, so far, the first PaaS to do any arbitrary service very well. The ability to throw Docker images into micro VMs with such ease and speed with this paradigm is truly liberating. edit: As a note, I have not tried Render. I am sure it is fine too. I found Fly first and it satisfies my needs well enough that I don’t feel it is necessary to keep searching, though I wouldn’t mind checking it out just to see what it has to offer.
config_yml 4y ago
Does fly.io have the same git push deploy magic?
- jchw 4y ago
  Kind of; flyctl deploy will “magically” build and deploy your app. They show how incredibly easy it is to throw this into GitHub Actions, which I’ve probably done about 8 times in the past week, and it seems to work about as well as you’d expect. (My only deviation from the example is that I limit the branches to deploy to just master.) To me, flyctl deploy is perhaps even better, because it is VCS agnostic and integrates with existing pipelines. I think it is fully worth it.
  - morajabi 4y ago
    I agree that it's perhaps even better. With Fly, I feel safe that whatever I want to do now or in the future, I can build on top of the building blocks for it—no matter if there's an "integration". For example, when Vercel added GitHub integration, you couldn't trigger it based on specific logic (tags, branch pattern match) and a bunch of limitation that they use them for up-selling (using GitHub Enterprise/Org requires a Pro account).
sergiomattei 4y ago
I don’t feel that way at all. Every time I’ve tried Fly (trust me I’ve wanted to love it), there’s always a rough edge or the service breaks for me. First time I tried it, the web panel wasn’t even loading. Second time, months later, everything was 500ing and I couldn’t find a way to SFTP into a disk (!!!). Total dealbreaker. This was easily done in Render.com with an even more magical experience. Deploy from a GitHub repo and I was live in minutes. Upload the files from local and done. I want to love Fly so much. I align with their mission. I love their first class Elixir support. But so far I’m not impressed. It looks to me like Render is seriously taking the PaaS crown at the moment, with innovation after innovation, affordable pricing and excellent user experience.
- jhardy54 4y ago
  Why do you need to SFTP into a disk?
  - sergiomattei 4y ago
    I was moving a Ghost blog from Render. Ghost is notorious for having a difficult time with hosting assets in S3, so it uses disks. I needed to move the Ghost assets directory for all the posts. This was a ten minute thing in Render. SOL in Fly.
    - indigodaddy 4y ago
      Can you not ssh into a fly instance and then pull?
      - sergiomattei 4y ago
        No. Flyctl SSH does not allow this functionality.
        tptacek 4y ago
        We definitely don't do SFTP! My general M.O. for moving files to running VMs is Magic Wormhole. But that's not optimal either. You've got a legit irritation and I'm glad you put it on our radar.
taylorlapeyre 4y ago
The main thing I want is pipelines - review apps, staging apps, and promotion to production, all integrated closely with GitHub, along with a slack integration that lets me do all of it in a public chatroom. Until another service has all of this, we’re sticking with Heroku.
- zoomzoom 4y ago
  We’re super early but if all of that running on top of your own cloud using tools like cloud run or fargate sounds interesting, check out www.withcoherence.com (I’m a cofounder).
- EqNoteqp 4y ago
  I get the intention with Slack. I’ve never understood, except for the geek cred, pushing work into chat services. Github is open to the team too. I hear complaints about chat distractions and see engineers create those distractions. I’m at a loss why we want to do that to ourselves? Nevermind it’s one more pipeline for messages to lost in. It’s needless complexity and configuration too.
  - bri3d 4y ago
    The main reason is to use a chat solution is as a unified ledger / single pane of glass. Silly as it is, there isn't really a better solution out there for "integrate all of my third-party deploy, CI, build, etc. status updates in real time, in one place." Sure, someone can click into GitHub, but if you use another service to deploy into, does GitHub pipe the status of that service into your dashboard? How about error logs and alerting, do they go there? If there's a customer incident, does the trust site status show up as well? On Slack and other chat solutions, it's possible to set up a #operations style single-pane-of-glass channel with deploy notifications, error alerting, and customer communication platforms all pushing to the same place. If an incident occurs, engineers, product, support, etc. can all collaborate around what's going on in real-time without needing to ask "hey has someone updated the trust site yet?" or click into 10 different tabs. It's honestly pretty good when it works well and really bad and noisy when it doesn't, but it has a place. Non-engineering are usually in Slack too, which really helps when support, product, or the field need quick answers to easy questions like "has this commit been deployed yet today?"
nehalem 4y ago
Being a small-scale Heroku user, I have a hard time deciding whether to stay with Heroku or move to render.com or fly.io. Before the latest incident, Heroku seemed to be frozen but stable. Now… I don't know. Are they even trying to bring back Github Connect? Fly.io seems cutting-edge but I feel I would not profit from their multi-region, close to the user infrastructure. So what are their tradeoffs? Render.com appears more complete (?) and cheaper. But they don't have the same elegant database backups or the pipeline with review apps.
- ushakov 4y ago
  i used both Render and Fly.io Render is more user-friendly and great for teams, but Fly.io is more flexible and has more advanced features
- ignoramous 4y ago
  Fly.io isn't as much cutting-edge as it is a rethink on what devex on Cloud should look like. It is a fantastic offering that despite its shortcomings is really a delight to use. I use it for toy projects (mostly stateless, or state stored elsewhere but not on Fly.io), but there are plenty who run pretty serious workloads. Give it a spin! You'd be surprised how butter-smooth all that cutting-edge is.
  - cxr 4y ago
    > [...] despite its shortcomings [...] What do you see as some of its shortcomings? Do e.g. semi-broken docs (or other instances of unclear/uncertain messaging) factor into your impression?
    - ignoramous 4y ago
      Docs, oh god yes. They're the anti-Stripe in this regard. And hard-to-debug deploy-time (and sometimes runtime / uptime) issues are a major sticking point. It is hard to know what or who's at fault without asking for it in the forums, since you can't stackoverflow much. Their support (granted it's free) is a bit of a hit and a miss; while it isn't clear what really is on their roadmap (or important) and what isn't (even though, they are more than transparent than other providers I've interacted with). These are but pains that come with adopting a nascent ecosystem, I suppose. I still persist with Fly because it is still simpler to build certain apps on it than on any other BigCloud (bar Cloudflare).
onphonenow 4y ago
I'm using fly.io lightly. One thing for me - fly.io is cool, does a lot of cool fancy things. However, the basic PaaS stack from Heroku gets a bit lost / not always fully there for me. For a while they didn't really talk about their container deploy story (AWS App Runner / AWS Fargate, AWS ECS). Digging in, it's all doable, but they do so many cool things it sometimes isn't obvious to me how the basics go. That's changed in last year (at least looking at the docs)? I also had some bobbles on UI in past. I don't need multi-region in my case, but I do want low latency for example. Easy to find this on aws (https://www.cloudping.info/ https://www.cloudping.info/) - a bit harder to get all regions with a ping endpoint on fly.io - I went looking, they have a demo app you can I think find what they see as closest region, but I wanted to roll my own cloudping.info style approach and it wasn't obvious how to do so. I'm getting about 8ms from my home computer to my closest AWS region. The basic story need for me is github commit -> goes to dev for review -> promote to production? I happen to use containers now (even if inefficient) because getting stuff "working" often is easier -> if it's working on the container on my machine, it'll work up in the cloud. That said, there is definitely I think a crop of AWS / Heroku competitors that are going to start to be competitive (think cloudflare on primitives, fly.io and render etc on PaaS style).
deleted 4y ago
[deleted]
the__alchemist 4y ago
> Heroku was catalytic to my career. It's been hard to watch the fall from grace. Don't get me wrong, Heroku still works, but it's obviously been in maintenance mode for years. Sounds like mission accomplished; the elusive 1.0.
brundolf 4y ago
The only thing I don't like is their usage-based pricing. On Heroku I could pay $7 a month and know I'd never be charged more than that. I'm sure when you're scaling a service it's fine - maybe even better - to do it on a sliding scale. But for a fire-and-forget blog site, I don't want to have to worry about stuff like that.
- natly 4y ago
  Just use a static hoster for a blog site (like netlify or even github pages).
  - ushakov 4y ago
    what if they want to use a CMS?
    - pkalinowski 4y ago
      https://forestry.io https://forestry.io could help
      - deleted 4y ago
        [deleted]
    - andrethegiant 4y ago
      https://www.netlifycms.org https://www.netlifycms.org
  - brundolf 4y ago
    I've got a small amount of dynamic content
    - skrtskrt 4y ago
      DigitalOcean App Platform has a $5/month flat rate for dynamic stuff on top of two static sites hosted for free... if something goes crazy and you end up using a wild amount of outbound data, it looks like the next jump up is only to $12
sergiotapia 4y ago
My experience with Fly.io has not been a good one. If I could sum it up, it would be that the dev ux needs a lot of work, and it seems like they are mostly focused on the fundamentals of the platform first. Following their guide you get postgres not spinning up and linking to your app correctly and you have to nuke your entire app. The billing UI is weird and feels cobbled together. I don't feel secure using Fly right now. But again, they are doing cutting edge shit and are probably focused on the underlying bedrock of the platform. They can always circle back to polish the dev ux. Right now we're on Render.com and it does absolutely everything we want with wonderful dev ux. In my mind it's a race: can fly catch up to render's UX before render can catch up to flys global mesh load balancing? We'll see who wins.
- mrkurt 4y ago
  It's very generous of you to assume we're focusing on underlying platform. It's true! But it's a difficult thing to notice when our service gave you papercuts. We've just now grown large enough to have people focus full time on the in browser UX. If you feel like fiddling around again in a few months, let me know and I can hook you up with some credits. :) The billing UI is definitely cobbled together. This is because I built it over a weekend and it's marginally better than "no billing UI". I have learned that if I'm building features, they probably aren't gonna be very good.
ushakov 4y ago
i'm running https://wikinewsfeed.org https://wikinewsfeed.org on fly.io very satisfied so far and would definitely deploy there next time! the killer feature i like the most is automatic prometheus metrics collection one thing i don't really like about fly.io is the fact that they charge money for free Let's Encrypt SSL certs
- datalopers 4y ago
  They aren’t charging for the certificate so much as they’re charging for TLS termination, infrastructure, DNS, caching, handling invalidations, etc. It’s also 10 free then $0.10/mo per certificate thereafter (or $2/mo for wildcard). They also donate 50% of their TLS fees to Let’s Encrypt. So, yes, some users will have have to pay for certificates, but it seems extremely reasonable to me.
  - ushakov 4y ago
    well, maybe but, my expectation as a PaaS customer in 2022 is that you shouldn't need to pay for a SSL cert the expectation is because nobody else charges for them anymore, not even their competitors
    - datalopers 4y ago
      Do they? I feel like you're just uncomfortable with line-item pricing and prefer flat all-in-one pricing. What are the other competitors that offer actual PaaS instead of static-site hosting? * Render.com charges $0.60 per custom domain after the first 25 * Heroku gives you "free" custom certificates once you're on a $7/mo minimum.
      - anurag 4y ago
        A clarification: every static site or full stack app can have up to 25 custom domains for free on Render. Most sites only have 2 (apex and www).
      - endorphine 4y ago
anon3949494 4y ago
After all the chatter this week, I've come to the conclusion that Heroku froze at the perfect time for my 4 person company. All of these so called "features" are exactly what we don't want or need. 1. Multi-region deployment only work if your database is globally distributed too. However, making your database globally distributed creates a set of new problems, most of which take time away from your core business. 2. File persistence is fine but not typically necessary. S3 works just fine. It's easy to forget that most companies are a handful of people or just solo devs. At the same time, most money comes from the enterprise, so products that reach sufficient traction tend to shift their focus to serving the needs of these larger clients. I'm really glad Heroku froze when it did. Markets always demand growth at all costs, and I find it incredibly refreshing that Heroku ended up staying in its lane. IMO it was and remains the best PaaS for indie devs and small teams.
- tomjakubowski 4y ago
  > Multi-region deployment only work if your database is globally distributed too. However, making your database globally distributed creates a set of new problems, most of which take time away from your core business. Guess what? fly.io offers a turnkey distributed/replicated Postgres for just this reason. You use an HTTP header to route writes to the region hosting your primary. https://fly.io/docs/getting-started/multi-region-databases/ https://fly.io/docs/getting-started/multi-region-databases/ You do still need to consider the possibility of read replicas being behind the primary when designing your application. If your design considers that from day 1, I think it takes less away from solving your business problems. Alternatively, you can also just ignore all the multi-region stuff and deploy to one place, as if it was old-school Heroku :-)
  - nickjj 4y ago
    > Guess what? fly.io offers a turnkey distributed/replicated Postgres for just this reason. You use an HTTP header to route writes to the region hosting your primary. Doesn't this take away a lot of the benefits of global distribution? For example if you pay Fly hundreds of dollars a month to distribute your small app in a few datacenters around the globe but your primary DB is in California then everyone from the EU is going to have about 150-200ms round trip latency every time you write to your DB because you can't get around the limitations of the speed of light. Now we're back to non-distributed latency times every time you want to write to the DB which is quite often in a lot of types of apps. If you want to cache mostly static read-only pages at the CDN level you can do this with a number of services. Fly has about 20 datacenters, hosting a small'ish web app that's distributed across them will be over $200 / month without counting extra storage or bandwidth just for the web app portion. Their pg pricing isn't clear but a fairly small cluster is $33.40 / month for 2GB of memory and 40GB of storage. Based on their pricing page it sounds like that's the cost for 1 datacenter, so if you wanted read-replicas in a bunch of other places it adds up. Before you know it you might be at $500 / month to host something that will have similar latency on DB writes as a $20 / month DigitalOcean server that you self manage, Fly also charges you $2 / month per Let's Encrypt wildcard cert where as that's free from Let's Encrypt directly.
chasd00 4y ago
if you're counting pennies just use dokku on a vps, there was even an article here on HN recently. By the time you outgrow it you'll have outgrown the vast majority of the new paas sites that are springing up trying to be the next Heroku and your choice of where to go next will be easier. In the meantime, you'll have saved all that effort on just picking where your app is hosted and, instead, spend it on actually delivering your app. crazy thought, i know.
dubswithus 4y ago
--delete
- detaro 4y ago
  As the article mentions, it doesn't force you to use docker.
newaccount2021 4y ago
pharmakom 4y ago
Can someone explain what fly.io actually is for someone with an AWS background?
- jjtheblunt 4y ago
  the website for fly.io is extremely well written in explaining fly.io in terms of AWS
  - ipaddr 4y ago
    So no? I went to the site and didn't see anything nor did a google search turn up anything
    - jjtheblunt 4y ago
      https://fly.io/blog/fly-io-is-hiring-rust-developers/ https://fly.io/blog/fly-io-is-hiring-rust-developers/
- tptacek 4y ago
  We run hardware, our own physical servers, in a bunch of regions around the world. We have an API (and a CLI) that will take a Docker container (or a Dockerfile, or a bunch of other things), turn it into a VM, and it run it on that hardware. That VM is given a routable Anycast IP address, so your users will automatically tend to hit the closest instances of your app. Hope that helps!
- jsmeaton 4y ago
  Having a go at writing the elevator pitch myself, since I think the others I've read have been overly technical. It's a platform as a service. It'll take your docker application (usually a web application) and run it on the internet. It'll also allow you to run it in many locations around the world transparently (using the same IP address / anycast) so that users closer to those locations will get better/lower latency. It's a CDN for your application. (There's more to it than this, but as far as elevator pitches go, sufficient?)
- 4y ago
Shadonototra 4y ago
Fly.io is backed by YCombinator In order to increase transparency on Hacker News, it would be nice it the title was changed to include the fact that's it's backed by YCombinator https://www.ycombinator.com/companies/fly-io https://www.ycombinator.com/companies/fly-io -- I personally don't think it's better than Heroku, you have much less features, Heroku is much cheaper + they have an unbeatable free tier
- heartbreak 4y ago
  Just FYI https://www.ycombinator.com/companies/heroku https://www.ycombinator.com/companies/heroku
  - morajabi 4y ago
    Hah!
  - Shadonototra 4y ago
    Exactly, ask yourself why you keep hear about them over here, that'll answser part of the reason why they are moving away from it and are looking for a "reset" with a new "brand" The exodus
- dang 4y ago
  The OP isn't associated with YC and we haven't touched the post - this is all organic. Given that, I don't see how it would add transparency to put "YC" in the title. Also, I think if we start doing that to blog titles, people will complain about the opposite sort of shenanigan.
mountainriver 4y ago
daxfohl 4y ago
Heroku was magic for hosting college projects of 2010's complexity. The failure wasn't in the prohibitive cost at scale (though that factor didn't help); it was that for most real-world stuff we need IaaS, not PaaS. That has become more and more evident over the last ten years. I think if fly succeeds, they need to figure out edge IaaS, and not put all their eggs into edge PaaS. And I hope they do! I'm curious what a successful edge IaaS looks like!
- mrkurt 4y ago
  This is pretty much what I believe. This isn't HN frontpage worthy, but one of the things I'm most excited about is people running production CockroachDB clusters on Fly.io. It is still a little more difficult to use the underlying infrastructure than it should be, but we're getting close.
  - daxfohl 4y ago
    Neat, I'd say that is absolutely HN frontpage worthy!
    - daxfohl 4y ago
      And disclosure, I used to be on Azure Front Door team and was the lead for Azure Edge Zones development. I really wanted to do something like fly with that. But it turned out that too many people wanted too many different things. Some needed GPU (some Nvidia, some AMD), some FPGA, some general compute. Surprisingly few cared about Functions (our Lambda-like service), or even Web Apps (our Heroku). SQL Server was a big request; CosmosDB was not. Remote Desktop was another big one. They also wanted availability zones within the edge zone itself. And even if latency was tolerable to the nearest region, we had to put almost all our infra services local too because everything needed to continue working if there's a network outage. And the extra annoying thing that shouldn't have to be annoying -- everybody wanted ipv4. So it ended up hardly making sense to deploy anything less than like 80 racks per site, at which point it's basically a small region minus a few small pieces. Then there's just the risk that the people who wanted whatever special GPU or SSD combination would quit wanting them and they'd just sit there unused indefinitely after that. Or stockouts when demand rose due to a conference or whatever that would tarnish the brand. And of course nobody wanted to pay more than like 10% markup. They were more amenable to long term contracts though. It was just hard to figure out the right use case and make it profitable. Seemed like what customers really wanted out of them were nearby replacements for pieces of their own datacenter. It was exactly the opposite direction of where I was hoping things would go, which was something between fly and cloudflare workers. Not sure what they're doing now; I left about 18 months ago.
hthrowaway5 4y ago
At one point (a very long time ago now) it was declared that Dogwood was the future and as a result Go would be the language of choice at Heroku and Erlang would be no more. Trouble is that Erlang ran all the important Cedar code (it might still today) and the Erlang engineers didn't particularly like the news that Erlang code was essentially deprecated so they left and nobody knew how to maintain the stack. This definitely wasn't the only problem we had but it was a big one. What do fellow Herokai think? Was Dogwood a fool's errand? Or did we just not get enough staff to build it properly?
- ditsuke 4y ago
  Sorry I couldn't find a reference, what is dogwood?
  - xena 4y ago
    The next phase after Cedar. It was mostly a "Go 2" style mythical benchmark that they compromised on for private spaces but was never really able to meet.
  - krallja 4y ago
    It’s mentioned in the article.
  - glenngillen 4y ago
    Heroku named all of their stacks after an alliterated color + tree convention: - Argent Aspen - Badious Bamboo - Celadon Cedar I can’t remember what to color name for the Dogwood stack was meant to be, we mostly only ever referred to them by the tree name and dropped the color. Suffice to say that Dogwood was meant to be the 4th major evolution of what Heroku was.
  - m12k 4y ago
    Second paragraph in the article
- makeitdouble 4y ago
  Have seen similar transitions in different companies, and while I can't say anything about Heroku, it is often not the target technology or architecture that matters. For instance I've seen PHP -> nodejs transition while moving to micrservices, and while the ideas made sense on paper: - It didn't come from the engineers at large. Most weren't phased by the prospect and the main engine for the change was the top architects and the engineering management. - target architecture and language were very popular, and easy to hire. Incidentally salaries would be cheaper for same level of experience engineers. Predictidbly a ton of the existing engineers left and new blood came in, and it was mostly according to plan from what I gathered. Some of the "old folks" stayed at a premium once they were the only ones left with enough knowledge, but they got relagated in side "experts" roles and the product as a whole saw a big change in philosophy (I think mentally what was seen as the "core" also became "legacy" in everyone's mind as engineers moved away)
jedisct1 4y ago
Koyeb https://www.koyeb.com https://www.koyeb.com also feels magical.
kbrisso 4y ago
Using Fly.io it was pretty easy to to spin up an app.. I wish it used Docker Up/Compose files though. I'm not a Docker expert but being able to use those files seems like it would be easier to deploy apps. Please correct my ignorance if this isn't so.
quickthrower2 4y ago
Fly.io is a reclaimer. Also see: Vercel, Digital Ocean, Dokku, Netlify, Firebase, Engine Yard, OpenShift, Appfleet, Github Pages, Render, AWS Amplify. Heroku made it easier to deploy, but now it feels a tad bit bit more frictional than other services, including fly.io and these mentioned above. It is probably a bit outdated in that regard.
- tootie 4y ago
  We use a tool called squash.io. It's geared more for instant QA environment than production workloads, but it has the advantage of being super simple. It just listens for feature branch commits and grabs the docker-compose file and runs it. Funny enough, before we signed up we also considered Heroku since we had a relationship with Salesforce and I was familiar with their product. After an intro call, they never followed up. Guess that was a sign.
jamie_ca 4y ago
The one thing I'm really missing after looking at a number of hosts (Fly and Render being top of list otherwise) is a free database tier. For a toy app, 10k db rows (across all tables) from Heroku was enough to get the app running and have a public URL to share, and I miss those days. I'm working on a fresh Rails7 toy app to try out some new features, and my current thinking is to use sqlite, and add an initializer early in the stack to migrate+seed the db if it's missing. If it's ephemeral that's fine, I just want some baseline data to interact with the app at a distance beyond localhost.
- arkadiyt 4y ago
  Fly's free resource allowance includes Postgres
- jshen 4y ago
  Render has a free DB tier
  - alskdjflaskjdhf 4y ago
    Render's free DB tier isn't really usable when the data gets nuked after 90 days. Really strange decision IMO.
    - anurag 4y ago
      It's a temporary decision until we can build multi-tenant Postgres instances which will be perpetually free.
    - jshen 4y ago
      Good point. I haven’t used it because I use other free DB offerings. CockroachDB and cosmos DB both have free tiers.
oxff 4y ago
- xena 4y ago
  Author here. I am not being paid to say this. If you don't trust me, I'm sure one of the fly.io people will chime in to confirm this. I haven't accepted paid sponsorship and everything I write on my website is my own opinion and not the opinion of my employer. Of course, believe what you want. I am only words on a screen. I can't tell you want to think about things.
quantumwoke 4y ago
Any plans for fly.io to support Java soon? It is a blocker for me at my company.
- tptacek 4y ago
  How do you mean, "support Java"? You should be able to deploy JVM apps here no problem.
  - gwd 4y ago
    Presumably he means support for automatic container creation, such as seems to be possible (for example) with golang: https://fly.io/docs/getting-started/golang/ https://fly.io/docs/getting-started/golang/
- iampims 4y ago
  If you use Docker, any language should work.
qwerki 4y ago
chanux 4y ago
I could relate to the comment on Redis. The only things I can see missing are automated Redis hosting by the platform. There have been so many times I wanted some simple key value store which I do not have to bother about setting up and taking care of. Something like "ambient Redis". It's OK not to have crazy scaling promises. You just enable an API (maybe for a small fee) and just use it. If and when you get big enough you switch to a setup you bother about setting up and taking care of. Am I making sense to anyone?
- manigandham 4y ago
  Anything can be a key/value store and there are dozens of managed databases with serverless pricing and public/HTTP access so you can use it anywhere with acceptable latency.
- ignoramous 4y ago
  Fly did have a built-in redis cache (albeit multi-tenant / shared) and for the life of me I can't figure out why they'd deprecate it (though, it still works): https://community.fly.io/t/debugging-a-failing-image-without-a-deployment/1545/4 https://community.fly.io/t/debugging-a-failing-image-without... and https://community.fly.io/t/please-bring-redis-back/1563 https://community.fly.io/t/please-bring-redis-back/1563 If anything, I'd prefer they moved their PaaS more towards serverless and managed offerings than towards IaaS.
  - beninsydney 4y ago
    On their forums they say they envision some other company handling Postgres too. Personally I would prefer they handle the databases, redis etc because that way the services you need can be provisioned right alongside your app servers otherwise it undermines the value of having edge servers near your users. Heroku could get away with 3rd parties being responsible for the database software because using AWS it was easy for other companies to be in the same region or zone. https://community.fly.io/t/can-we-get-an-update-on-managed-db-options-with-fly-io/5183 https://community.fly.io/t/can-we-get-an-update-on-managed-d...
yewenjie 4y ago
I like Fly.io but I wish it offered something with Nix in the build process like Railway has recently introduced. https://github.com/railwayapp/nixpacks https://github.com/railwayapp/nixpacks
- tptacek 4y ago
  It looks like these just generate OCI containers; that's all we need at Fly.io to take your container, so you might be able to just use these. (We've been working for a couple months on Nix, especially for Rails apps, but I don't have status to report).
neya 4y ago
> I wouldn't straight out recommend fly.io. See, part of Heroku's value proposition was their excellent support. I had asked fly.io to delete my account since there wasn't a provision to delete it from their interface and they never bothered to reply and put me in some kind of shadow ban from re-registering with my email. I mean if this is how you're going to treat your customers, then good luck! I'm yet to try out railway.app and..looks interesting to say the least.
- traspler 4y ago
  Same thing happened to me with Lime (the bike and scooter „rental“ company) after they kept charging my old CC even after deleting and adding a new one, which creeped me out as I would hope a delete action on a payment method actually means delete. Instead of deleting my account they banned me so I could never register again.
manigandham 4y ago
Fly has a nice DX but unfortunately the platform still has major issues with reliability and networking. There are often problems with deploys leading to stuck and unreachable instances or other networking issues. It's probably exacerbated by the new user growth but the slick deploy workflow can't override having an app that works. Render and others are interesting but K8S is still fundamentally better considering all the DX progress there making it pretty easy to get a container running in a cluster.
- nik736 4y ago
  What exactly makes K8s better?
  - sascha_sl 4y ago
    Definitely not the developer experience. But as it is often mentioend, as companies and apps grow, so do their requirements and the need for flexibility. I can't think of a more flexible deployment target that handles a lot of the PaaS concerns than Kubernetes, warts and all. Fly is surprisingly great, volumes + containers is very close to universal for a PaaS, but it certainly can't cover everything that is running in my workplace's kubernetes.
  - manigandham 4y ago
    It's basically the platform to build platforms like these (and some of them already run on it). K8S offers the same primitives and more, with progressive complexity as you need it. You can deploy a single container with a 1-line command or an entire PaaS subsystem. It's also more portable than any single platform and you can run it on a few VPS instances or your own bare metal. I've also found it far more reliable than all these PaaS services that have their own issues with no visibility. K8S experience is also more valuable and useful in future projects and there are plenty of nice DX tooling to make deploys easy if that's the blocker.
    - kasey_junk 4y ago
      I’d be very surprised if any edge compute systems run on (a single) K8s cluster. In nearly all cases you’d run at least a cluster per region. K8s also provides no functionality for per region routing or networking between clusters. That is to say, for most of what fly gives you there is no K8s equivalent.
jillesvangurp 4y ago
I don't get this obsession with running a lot of vendor specific tooling on a laptop. Don't people use CI/CD? The only place that will ever deploy anything to anywhere is CI in my setups. And only after the tests pass. I see this over and over again where the first step of using something supposedly user friendly is to install a lot of command line cruft on your snow flake laptop. It only goes downhill from there. Great for amateurs but usually left as an exercise for the reader to beat some sense into bad practices like deploying things from a laptop. IMHO it should start from the other end and actually provide you with a sane CI/CD pipeline out of the box. Google cloud run does this right. You just give it a repository url and it sets up the rest. I used that two years ago and I was up and running in about 2 minutes. Every commit to master went live. CI/CD out of the box. No magical incantations on the command-line. Just develop as you do normally. Zero fuss.
onebot 4y ago
Is fly.io based on erlang?
davidhariri 4y ago
I just switched my hobby apps over to Fly and it is as good as people say it is. As simple or simpler than Heroku in many areas.
70jS8h5L 4y ago
I really wish more of these PaaS solutions would offer UK regions - it's a big issue for us compliance-wise and means we can't use a lot of them. Render.com seems to be one solution - and we're currently using Cloud66 with our own AWS instances as a solution, although I would prefer something lower-effort, like Heroku has historically been.
brunooliv 4y ago
How are rates for small apps? I've read the pricing table in the website and it seems pretty generous, so, for a small poc style app, is this limit enough?

528 points by sealeck 4y ago

For me the missing bit in Fly is scheduled tasks. I know how to solve this by spinning up an app that runs permanently as a scheduler, but basic cron-like scheduling should be part of the platform IMO. All other FaaS-like service do this.

tptacek 4y ago
I'd love to do this, if for no other reason than I hate working with cron. What would you use it for? What would the ideal version of this feature look like for you? What kind of apps would you be more easily able to ship? Is it mostly so you wouldn't need to keep a single tiny running VM sitting around running cron?
- st3fan 4y ago
  Some apps are just that - a periodic task. Nothing more. Ideally a task project would have a git repo with a short fly.toml, a requirements.txt and a main.py. (In case of Python. I'm not familiar with using other languages on fly.io) I don't think it needs to be more complicated than that.
- DizzyDoo 4y ago
  The sort of things I have had running on a schedule (using Celery[0] or something like it) are sending a set of emails at a certain time, running a report or generating the data for reports, even running a backup of some data. [0] - https://docs.celeryq.dev/en/stable/userguide/periodic-tasks.html https://docs.celeryq.dev/en/stable/userguide/periodic-tasks....
- krn 4y ago
  > What would the ideal version of this feature look like for you? I think that Render solved "Cron as a Service" beautifully: https://render.com/docs/cronjobs https://render.com/docs/cronjobs
  - st3fan 4y ago
    I would use render but fly.io persistent storage is a killer feature. It is literally 100x simpler to just deal with files on a real file system than having to deal with remote object storage.
    - anurag 4y ago
      Render has persistent disks! https://render.com/docs/disks https://render.com/docs/disks. We need to expose them for cron jobs though.
- joseph 4y ago
  I'd like to do any one-off job, not only scheduled ones; retrieving data and transforming or storing it, scraping a web page, running a database migration. My biggest annoyance with Fly is the assumption that everything is a long running application.
  - mrkurt 4y ago
    Don't tell anyone, but you can try "fly machines run" (currently only in a new, empty app). Then "fly machine start <id>" to start the thing back up after it exits. It's not released yet, though.
  - kevlened 4y ago
    I'm not sure how Fly handles one-off tasks behind the scenes, but we're building task queues (w/ cron) as a first class citizen at https://tasker.sh https://tasker.sh

mardix 4y ago

Heroku is getting hammered like crazy this week on HN

colesantiago 4y ago

Bilal_io 4y ago
Edge on Android with the built-in AdBlock Plus prevented all ads from showing up.
sealeck 4y ago
I mean you could just install an ad blocker.
normie3000 4y ago
No ads for me either

deleted 4y ago

[deleted]

normie3000 4y ago

How mature is fly.io?

throwawaycuriou 4y ago
Define mature
mrkurt 4y ago
We are DigitalOcean circa 2015 mature. Good enough for some very large customers, good enough for many developers, not some place I'd run pacemaker infrastructure.
- indigodaddy 4y ago
  Does anyone run pacemaker on non-baremetal? Can you even? I’m aware you’re just using it as an analogy/example, but was just wondering..
  - antod 4y ago
    I did run some VRRP or CARP stuff (forget the specific tool/protocol - but that's kinda like pacemaker right?) in an immature OpenStack cloud once that didn't have a good LBaaS yet. It was a semi supported hack documented by the provider.
  - ecnahc515 4y ago
    FWIW, I'm pretty sure OP was referring to literal pacemakers, as in, the things that keep people's hearts beating.
- sanjayio 4y ago
  Where would you feel comfortable running pacemaker infra? Half-joking here.
  - deleted 4y ago
    [deleted]

2c2c2c 4y ago

There's a lot of chat about fly.io on HN. possibly just because the founders and friends are posters here. Is there any in depth comparison between them and render.com ?

atonse 4y ago
I think it is because they are refreshingly open about their stack and people love their writing tone. And the architecture seems solid.
- sanjayio 4y ago
  Agreed, really enjoyed their tone on explaining SQLite and litestream.
mavbo 4y ago
Not in-depth, but two things that have stood out to me in assessing Render vs Fly are Render's lack of Multi-region apps and release phase scripts for running migrations. Easy multi-region apps seem to be a main selling point of Fly. However, both of the features I mentioned are on Render's roadmap (Multi-region apps has been on their roadmap since 2019, so maybe not a priority?)
- matthewcford 4y ago
  these were the reasons we chose fly in the end; very happy with it
jchw 4y ago
As an occasional third-party Fly “shill” of sorts, I mainly talk about Fly because I’ve really wanted almost exactly what Fly does for a long time now. I’d tried other things like Hyper, Fargate and Cloud Run, but they’ve mostly been disappointing in some regards, being cumbersome to use or get started with, unrealistically expensive, or simply being too slow or limited. Fly is none of that. It still has some stuff that’s lacking; resizing disks is probably the biggest thing missing; the proxying is surprisingly complete but UDP services are a little awkward; copying data in and out is somewhat tricky, you have to use SSH but over a wireguard tunnel with an ephemeral SSH key and on Windows it’s not particularly fun. (I don’t think SCP is supported either, which is fine, but still.) It remains exciting nonetheless because it scratches an itch that I don’t feel anyone else has really managed to; Netlify and Vercel and probably Cloudflare Pages does static sites very well, but Fly feels like, so far, the first PaaS to do any arbitrary service very well. The ability to throw Docker images into micro VMs with such ease and speed with this paradigm is truly liberating. edit: As a note, I have not tried Render. I am sure it is fine too. I found Fly first and it satisfies my needs well enough that I don’t feel it is necessary to keep searching, though I wouldn’t mind checking it out just to see what it has to offer.

config_yml 4y ago

Does fly.io have the same git push deploy magic?

jchw 4y ago
Kind of; flyctl deploy will “magically” build and deploy your app. They show how incredibly easy it is to throw this into GitHub Actions, which I’ve probably done about 8 times in the past week, and it seems to work about as well as you’d expect. (My only deviation from the example is that I limit the branches to deploy to just master.) To me, flyctl deploy is perhaps even better, because it is VCS agnostic and integrates with existing pipelines. I think it is fully worth it.
- morajabi 4y ago
  I agree that it's perhaps even better. With Fly, I feel safe that whatever I want to do now or in the future, I can build on top of the building blocks for it—no matter if there's an "integration". For example, when Vercel added GitHub integration, you couldn't trigger it based on specific logic (tags, branch pattern match) and a bunch of limitation that they use them for up-selling (using GitHub Enterprise/Org requires a Pro account).

sergiomattei 4y ago

I don’t feel that way at all. Every time I’ve tried Fly (trust me I’ve wanted to love it), there’s always a rough edge or the service breaks for me. First time I tried it, the web panel wasn’t even loading. Second time, months later, everything was 500ing and I couldn’t find a way to SFTP into a disk (!!!). Total dealbreaker. This was easily done in Render.com with an even more magical experience. Deploy from a GitHub repo and I was live in minutes. Upload the files from local and done. I want to love Fly so much. I align with their mission. I love their first class Elixir support. But so far I’m not impressed. It looks to me like Render is seriously taking the PaaS crown at the moment, with innovation after innovation, affordable pricing and excellent user experience.

jhardy54 4y ago
Why do you need to SFTP into a disk?
- sergiomattei 4y ago
  I was moving a Ghost blog from Render. Ghost is notorious for having a difficult time with hosting assets in S3, so it uses disks. I needed to move the Ghost assets directory for all the posts. This was a ten minute thing in Render. SOL in Fly.
  - indigodaddy 4y ago
    Can you not ssh into a fly instance and then pull?
    - sergiomattei 4y ago
      No. Flyctl SSH does not allow this functionality.
      - tptacek 4y ago
        We definitely don't do SFTP! My general M.O. for moving files to running VMs is Magic Wormhole. But that's not optimal either. You've got a legit irritation and I'm glad you put it on our radar.

taylorlapeyre 4y ago

The main thing I want is pipelines - review apps, staging apps, and promotion to production, all integrated closely with GitHub, along with a slack integration that lets me do all of it in a public chatroom. Until another service has all of this, we’re sticking with Heroku.

zoomzoom 4y ago
We’re super early but if all of that running on top of your own cloud using tools like cloud run or fargate sounds interesting, check out www.withcoherence.com (I’m a cofounder).
EqNoteqp 4y ago
I get the intention with Slack. I’ve never understood, except for the geek cred, pushing work into chat services. Github is open to the team too. I hear complaints about chat distractions and see engineers create those distractions. I’m at a loss why we want to do that to ourselves? Nevermind it’s one more pipeline for messages to lost in. It’s needless complexity and configuration too.
- bri3d 4y ago
  The main reason is to use a chat solution is as a unified ledger / single pane of glass. Silly as it is, there isn't really a better solution out there for "integrate all of my third-party deploy, CI, build, etc. status updates in real time, in one place." Sure, someone can click into GitHub, but if you use another service to deploy into, does GitHub pipe the status of that service into your dashboard? How about error logs and alerting, do they go there? If there's a customer incident, does the trust site status show up as well? On Slack and other chat solutions, it's possible to set up a #operations style single-pane-of-glass channel with deploy notifications, error alerting, and customer communication platforms all pushing to the same place. If an incident occurs, engineers, product, support, etc. can all collaborate around what's going on in real-time without needing to ask "hey has someone updated the trust site yet?" or click into 10 different tabs. It's honestly pretty good when it works well and really bad and noisy when it doesn't, but it has a place. Non-engineering are usually in Slack too, which really helps when support, product, or the field need quick answers to easy questions like "has this commit been deployed yet today?"

nehalem 4y ago

Being a small-scale Heroku user, I have a hard time deciding whether to stay with Heroku or move to render.com or fly.io. Before the latest incident, Heroku seemed to be frozen but stable. Now… I don't know. Are they even trying to bring back Github Connect? Fly.io seems cutting-edge but I feel I would not profit from their multi-region, close to the user infrastructure. So what are their tradeoffs? Render.com appears more complete (?) and cheaper. But they don't have the same elegant database backups or the pipeline with review apps.

ushakov 4y ago
i used both Render and Fly.io Render is more user-friendly and great for teams, but Fly.io is more flexible and has more advanced features
ignoramous 4y ago
Fly.io isn't as much cutting-edge as it is a rethink on what devex on Cloud should look like. It is a fantastic offering that despite its shortcomings is really a delight to use. I use it for toy projects (mostly stateless, or state stored elsewhere but not on Fly.io), but there are plenty who run pretty serious workloads. Give it a spin! You'd be surprised how butter-smooth all that cutting-edge is.
- cxr 4y ago
  > [...] despite its shortcomings [...] What do you see as some of its shortcomings? Do e.g. semi-broken docs (or other instances of unclear/uncertain messaging) factor into your impression?
  - ignoramous 4y ago
    Docs, oh god yes. They're the anti-Stripe in this regard. And hard-to-debug deploy-time (and sometimes runtime / uptime) issues are a major sticking point. It is hard to know what or who's at fault without asking for it in the forums, since you can't stackoverflow much. Their support (granted it's free) is a bit of a hit and a miss; while it isn't clear what really is on their roadmap (or important) and what isn't (even though, they are more than transparent than other providers I've interacted with). These are but pains that come with adopting a nascent ecosystem, I suppose. I still persist with Fly because it is still simpler to build certain apps on it than on any other BigCloud (bar Cloudflare).

onphonenow 4y ago

I'm using fly.io lightly. One thing for me - fly.io is cool, does a lot of cool fancy things. However, the basic PaaS stack from Heroku gets a bit lost / not always fully there for me. For a while they didn't really talk about their container deploy story (AWS App Runner / AWS Fargate, AWS ECS). Digging in, it's all doable, but they do so many cool things it sometimes isn't obvious to me how the basics go. That's changed in last year (at least looking at the docs)? I also had some bobbles on UI in past. I don't need multi-region in my case, but I do want low latency for example. Easy to find this on aws (https://www.cloudping.info/ https://www.cloudping.info/) - a bit harder to get all regions with a ping endpoint on fly.io - I went looking, they have a demo app you can I think find what they see as closest region, but I wanted to roll my own cloudping.info style approach and it wasn't obvious how to do so. I'm getting about 8ms from my home computer to my closest AWS region. The basic story need for me is github commit -> goes to dev for review -> promote to production? I happen to use containers now (even if inefficient) because getting stuff "working" often is easier -> if it's working on the container on my machine, it'll work up in the cloud. That said, there is definitely I think a crop of AWS / Heroku competitors that are going to start to be competitive (think cloudflare on primitives, fly.io and render etc on PaaS style).

deleted 4y ago

[deleted]

the__alchemist 4y ago

> Heroku was catalytic to my career. It's been hard to watch the fall from grace. Don't get me wrong, Heroku still works, but it's obviously been in maintenance mode for years. Sounds like mission accomplished; the elusive 1.0.

brundolf 4y ago

The only thing I don't like is their usage-based pricing. On Heroku I could pay $7 a month and know I'd never be charged more than that. I'm sure when you're scaling a service it's fine - maybe even better - to do it on a sliding scale. But for a fire-and-forget blog site, I don't want to have to worry about stuff like that.

natly 4y ago
Just use a static hoster for a blog site (like netlify or even github pages).
- ushakov 4y ago
  what if they want to use a CMS?
  - pkalinowski 4y ago
    https://forestry.io https://forestry.io could help
    - deleted 4y ago
      [deleted]
  - andrethegiant 4y ago
    https://www.netlifycms.org https://www.netlifycms.org
- brundolf 4y ago
  I've got a small amount of dynamic content
  - skrtskrt 4y ago
    DigitalOcean App Platform has a $5/month flat rate for dynamic stuff on top of two static sites hosted for free... if something goes crazy and you end up using a wild amount of outbound data, it looks like the next jump up is only to $12

sergiotapia 4y ago

My experience with Fly.io has not been a good one. If I could sum it up, it would be that the dev ux needs a lot of work, and it seems like they are mostly focused on the fundamentals of the platform first. Following their guide you get postgres not spinning up and linking to your app correctly and you have to nuke your entire app. The billing UI is weird and feels cobbled together. I don't feel secure using Fly right now. But again, they are doing cutting edge shit and are probably focused on the underlying bedrock of the platform. They can always circle back to polish the dev ux. Right now we're on Render.com and it does absolutely everything we want with wonderful dev ux. In my mind it's a race: can fly catch up to render's UX before render can catch up to flys global mesh load balancing? We'll see who wins.

mrkurt 4y ago
It's very generous of you to assume we're focusing on underlying platform. It's true! But it's a difficult thing to notice when our service gave you papercuts. We've just now grown large enough to have people focus full time on the in browser UX. If you feel like fiddling around again in a few months, let me know and I can hook you up with some credits. :) The billing UI is definitely cobbled together. This is because I built it over a weekend and it's marginally better than "no billing UI". I have learned that if I'm building features, they probably aren't gonna be very good.

ushakov 4y ago

i'm running https://wikinewsfeed.org https://wikinewsfeed.org on fly.io very satisfied so far and would definitely deploy there next time! the killer feature i like the most is automatic prometheus metrics collection one thing i don't really like about fly.io is the fact that they charge money for free Let's Encrypt SSL certs

datalopers 4y ago
They aren’t charging for the certificate so much as they’re charging for TLS termination, infrastructure, DNS, caching, handling invalidations, etc. It’s also 10 free then $0.10/mo per certificate thereafter (or $2/mo for wildcard). They also donate 50% of their TLS fees to Let’s Encrypt. So, yes, some users will have have to pay for certificates, but it seems extremely reasonable to me.
- ushakov 4y ago
  well, maybe but, my expectation as a PaaS customer in 2022 is that you shouldn't need to pay for a SSL cert the expectation is because nobody else charges for them anymore, not even their competitors
  - datalopers 4y ago
    Do they? I feel like you're just uncomfortable with line-item pricing and prefer flat all-in-one pricing. What are the other competitors that offer actual PaaS instead of static-site hosting? * Render.com charges $0.60 per custom domain after the first 25 * Heroku gives you "free" custom certificates once you're on a $7/mo minimum.
    - anurag 4y ago
      A clarification: every static site or full stack app can have up to 25 custom domains for free on Render. Most sites only have 2 (apex and www).
    - endorphine 4y ago

anon3949494 4y ago

After all the chatter this week, I've come to the conclusion that Heroku froze at the perfect time for my 4 person company. All of these so called "features" are exactly what we don't want or need. 1. Multi-region deployment only work if your database is globally distributed too. However, making your database globally distributed creates a set of new problems, most of which take time away from your core business. 2. File persistence is fine but not typically necessary. S3 works just fine. It's easy to forget that most companies are a handful of people or just solo devs. At the same time, most money comes from the enterprise, so products that reach sufficient traction tend to shift their focus to serving the needs of these larger clients. I'm really glad Heroku froze when it did. Markets always demand growth at all costs, and I find it incredibly refreshing that Heroku ended up staying in its lane. IMO it was and remains the best PaaS for indie devs and small teams.

tomjakubowski 4y ago
> Multi-region deployment only work if your database is globally distributed too. However, making your database globally distributed creates a set of new problems, most of which take time away from your core business. Guess what? fly.io offers a turnkey distributed/replicated Postgres for just this reason. You use an HTTP header to route writes to the region hosting your primary. https://fly.io/docs/getting-started/multi-region-databases/ https://fly.io/docs/getting-started/multi-region-databases/ You do still need to consider the possibility of read replicas being behind the primary when designing your application. If your design considers that from day 1, I think it takes less away from solving your business problems. Alternatively, you can also just ignore all the multi-region stuff and deploy to one place, as if it was old-school Heroku :-)
- nickjj 4y ago
  > Guess what? fly.io offers a turnkey distributed/replicated Postgres for just this reason. You use an HTTP header to route writes to the region hosting your primary. Doesn't this take away a lot of the benefits of global distribution? For example if you pay Fly hundreds of dollars a month to distribute your small app in a few datacenters around the globe but your primary DB is in California then everyone from the EU is going to have about 150-200ms round trip latency every time you write to your DB because you can't get around the limitations of the speed of light. Now we're back to non-distributed latency times every time you want to write to the DB which is quite often in a lot of types of apps. If you want to cache mostly static read-only pages at the CDN level you can do this with a number of services. Fly has about 20 datacenters, hosting a small'ish web app that's distributed across them will be over $200 / month without counting extra storage or bandwidth just for the web app portion. Their pg pricing isn't clear but a fairly small cluster is $33.40 / month for 2GB of memory and 40GB of storage. Based on their pricing page it sounds like that's the cost for 1 datacenter, so if you wanted read-replicas in a bunch of other places it adds up. Before you know it you might be at $500 / month to host something that will have similar latency on DB writes as a $20 / month DigitalOcean server that you self manage, Fly also charges you $2 / month per Let's Encrypt wildcard cert where as that's free from Let's Encrypt directly.

chasd00 4y ago

if you're counting pennies just use dokku on a vps, there was even an article here on HN recently. By the time you outgrow it you'll have outgrown the vast majority of the new paas sites that are springing up trying to be the next Heroku and your choice of where to go next will be easier. In the meantime, you'll have saved all that effort on just picking where your app is hosted and, instead, spend it on actually delivering your app. crazy thought, i know.

dubswithus 4y ago

--delete

detaro 4y ago
As the article mentions, it doesn't force you to use docker.

newaccount2021 4y ago

pharmakom 4y ago

Can someone explain what fly.io actually is for someone with an AWS background?

jjtheblunt 4y ago
the website for fly.io is extremely well written in explaining fly.io in terms of AWS
- ipaddr 4y ago
  So no? I went to the site and didn't see anything nor did a google search turn up anything
  - jjtheblunt 4y ago
    https://fly.io/blog/fly-io-is-hiring-rust-developers/ https://fly.io/blog/fly-io-is-hiring-rust-developers/
tptacek 4y ago
We run hardware, our own physical servers, in a bunch of regions around the world. We have an API (and a CLI) that will take a Docker container (or a Dockerfile, or a bunch of other things), turn it into a VM, and it run it on that hardware. That VM is given a routable Anycast IP address, so your users will automatically tend to hit the closest instances of your app. Hope that helps!
jsmeaton 4y ago
Having a go at writing the elevator pitch myself, since I think the others I've read have been overly technical. It's a platform as a service. It'll take your docker application (usually a web application) and run it on the internet. It'll also allow you to run it in many locations around the world transparently (using the same IP address / anycast) so that users closer to those locations will get better/lower latency. It's a CDN for your application. (There's more to it than this, but as far as elevator pitches go, sufficient?)
4y ago

Shadonototra 4y ago

Fly.io is backed by YCombinator In order to increase transparency on Hacker News, it would be nice it the title was changed to include the fact that's it's backed by YCombinator https://www.ycombinator.com/companies/fly-io https://www.ycombinator.com/companies/fly-io -- I personally don't think it's better than Heroku, you have much less features, Heroku is much cheaper + they have an unbeatable free tier

heartbreak 4y ago
Just FYI https://www.ycombinator.com/companies/heroku https://www.ycombinator.com/companies/heroku
- morajabi 4y ago
  Hah!
- Shadonototra 4y ago
  Exactly, ask yourself why you keep hear about them over here, that'll answser part of the reason why they are moving away from it and are looking for a "reset" with a new "brand" The exodus
dang 4y ago
The OP isn't associated with YC and we haven't touched the post - this is all organic. Given that, I don't see how it would add transparency to put "YC" in the title. Also, I think if we start doing that to blog titles, people will complain about the opposite sort of shenanigan.

mountainriver 4y ago

daxfohl 4y ago

Heroku was magic for hosting college projects of 2010's complexity. The failure wasn't in the prohibitive cost at scale (though that factor didn't help); it was that for most real-world stuff we need IaaS, not PaaS. That has become more and more evident over the last ten years. I think if fly succeeds, they need to figure out edge IaaS, and not put all their eggs into edge PaaS. And I hope they do! I'm curious what a successful edge IaaS looks like!

mrkurt 4y ago
This is pretty much what I believe. This isn't HN frontpage worthy, but one of the things I'm most excited about is people running production CockroachDB clusters on Fly.io. It is still a little more difficult to use the underlying infrastructure than it should be, but we're getting close.
- daxfohl 4y ago
  Neat, I'd say that is absolutely HN frontpage worthy!
  - daxfohl 4y ago
    And disclosure, I used to be on Azure Front Door team and was the lead for Azure Edge Zones development. I really wanted to do something like fly with that. But it turned out that too many people wanted too many different things. Some needed GPU (some Nvidia, some AMD), some FPGA, some general compute. Surprisingly few cared about Functions (our Lambda-like service), or even Web Apps (our Heroku). SQL Server was a big request; CosmosDB was not. Remote Desktop was another big one. They also wanted availability zones within the edge zone itself. And even if latency was tolerable to the nearest region, we had to put almost all our infra services local too because everything needed to continue working if there's a network outage. And the extra annoying thing that shouldn't have to be annoying -- everybody wanted ipv4. So it ended up hardly making sense to deploy anything less than like 80 racks per site, at which point it's basically a small region minus a few small pieces. Then there's just the risk that the people who wanted whatever special GPU or SSD combination would quit wanting them and they'd just sit there unused indefinitely after that. Or stockouts when demand rose due to a conference or whatever that would tarnish the brand. And of course nobody wanted to pay more than like 10% markup. They were more amenable to long term contracts though. It was just hard to figure out the right use case and make it profitable. Seemed like what customers really wanted out of them were nearby replacements for pieces of their own datacenter. It was exactly the opposite direction of where I was hoping things would go, which was something between fly and cloudflare workers. Not sure what they're doing now; I left about 18 months ago.

hthrowaway5 4y ago

At one point (a very long time ago now) it was declared that Dogwood was the future and as a result Go would be the language of choice at Heroku and Erlang would be no more. Trouble is that Erlang ran all the important Cedar code (it might still today) and the Erlang engineers didn't particularly like the news that Erlang code was essentially deprecated so they left and nobody knew how to maintain the stack. This definitely wasn't the only problem we had but it was a big one. What do fellow Herokai think? Was Dogwood a fool's errand? Or did we just not get enough staff to build it properly?

ditsuke 4y ago
Sorry I couldn't find a reference, what is dogwood?
- xena 4y ago
  The next phase after Cedar. It was mostly a "Go 2" style mythical benchmark that they compromised on for private spaces but was never really able to meet.
- krallja 4y ago
  It’s mentioned in the article.
- glenngillen 4y ago
  Heroku named all of their stacks after an alliterated color + tree convention: - Argent Aspen - Badious Bamboo - Celadon Cedar I can’t remember what to color name for the Dogwood stack was meant to be, we mostly only ever referred to them by the tree name and dropped the color. Suffice to say that Dogwood was meant to be the 4th major evolution of what Heroku was.
- m12k 4y ago
  Second paragraph in the article
makeitdouble 4y ago
Have seen similar transitions in different companies, and while I can't say anything about Heroku, it is often not the target technology or architecture that matters. For instance I've seen PHP -> nodejs transition while moving to micrservices, and while the ideas made sense on paper: - It didn't come from the engineers at large. Most weren't phased by the prospect and the main engine for the change was the top architects and the engineering management. - target architecture and language were very popular, and easy to hire. Incidentally salaries would be cheaper for same level of experience engineers. Predictidbly a ton of the existing engineers left and new blood came in, and it was mostly according to plan from what I gathered. Some of the "old folks" stayed at a premium once they were the only ones left with enough knowledge, but they got relagated in side "experts" roles and the product as a whole saw a big change in philosophy (I think mentally what was seen as the "core" also became "legacy" in everyone's mind as engineers moved away)

jedisct1 4y ago

Koyeb https://www.koyeb.com https://www.koyeb.com also feels magical.

kbrisso 4y ago

Using Fly.io it was pretty easy to to spin up an app.. I wish it used Docker Up/Compose files though. I'm not a Docker expert but being able to use those files seems like it would be easier to deploy apps. Please correct my ignorance if this isn't so.

quickthrower2 4y ago

Fly.io is a reclaimer. Also see: Vercel, Digital Ocean, Dokku, Netlify, Firebase, Engine Yard, OpenShift, Appfleet, Github Pages, Render, AWS Amplify. Heroku made it easier to deploy, but now it feels a tad bit bit more frictional than other services, including fly.io and these mentioned above. It is probably a bit outdated in that regard.

tootie 4y ago
We use a tool called squash.io. It's geared more for instant QA environment than production workloads, but it has the advantage of being super simple. It just listens for feature branch commits and grabs the docker-compose file and runs it. Funny enough, before we signed up we also considered Heroku since we had a relationship with Salesforce and I was familiar with their product. After an intro call, they never followed up. Guess that was a sign.

jamie_ca 4y ago

The one thing I'm really missing after looking at a number of hosts (Fly and Render being top of list otherwise) is a free database tier. For a toy app, 10k db rows (across all tables) from Heroku was enough to get the app running and have a public URL to share, and I miss those days. I'm working on a fresh Rails7 toy app to try out some new features, and my current thinking is to use sqlite, and add an initializer early in the stack to migrate+seed the db if it's missing. If it's ephemeral that's fine, I just want some baseline data to interact with the app at a distance beyond localhost.

arkadiyt 4y ago
Fly's free resource allowance includes Postgres
jshen 4y ago
Render has a free DB tier
- alskdjflaskjdhf 4y ago
  Render's free DB tier isn't really usable when the data gets nuked after 90 days. Really strange decision IMO.
  - anurag 4y ago
    It's a temporary decision until we can build multi-tenant Postgres instances which will be perpetually free.
  - jshen 4y ago
    Good point. I haven’t used it because I use other free DB offerings. CockroachDB and cosmos DB both have free tiers.

oxff 4y ago

xena 4y ago
Author here. I am not being paid to say this. If you don't trust me, I'm sure one of the fly.io people will chime in to confirm this. I haven't accepted paid sponsorship and everything I write on my website is my own opinion and not the opinion of my employer. Of course, believe what you want. I am only words on a screen. I can't tell you want to think about things.

quantumwoke 4y ago

Any plans for fly.io to support Java soon? It is a blocker for me at my company.

tptacek 4y ago
How do you mean, "support Java"? You should be able to deploy JVM apps here no problem.
- gwd 4y ago
  Presumably he means support for automatic container creation, such as seems to be possible (for example) with golang: https://fly.io/docs/getting-started/golang/ https://fly.io/docs/getting-started/golang/
iampims 4y ago
If you use Docker, any language should work.

qwerki 4y ago

chanux 4y ago

I could relate to the comment on Redis. The only things I can see missing are automated Redis hosting by the platform. There have been so many times I wanted some simple key value store which I do not have to bother about setting up and taking care of. Something like "ambient Redis". It's OK not to have crazy scaling promises. You just enable an API (maybe for a small fee) and just use it. If and when you get big enough you switch to a setup you bother about setting up and taking care of. Am I making sense to anyone?

manigandham 4y ago
Anything can be a key/value store and there are dozens of managed databases with serverless pricing and public/HTTP access so you can use it anywhere with acceptable latency.
ignoramous 4y ago
Fly did have a built-in redis cache (albeit multi-tenant / shared) and for the life of me I can't figure out why they'd deprecate it (though, it still works): https://community.fly.io/t/debugging-a-failing-image-without-a-deployment/1545/4 https://community.fly.io/t/debugging-a-failing-image-without... and https://community.fly.io/t/please-bring-redis-back/1563 https://community.fly.io/t/please-bring-redis-back/1563 If anything, I'd prefer they moved their PaaS more towards serverless and managed offerings than towards IaaS.
- beninsydney 4y ago
  On their forums they say they envision some other company handling Postgres too. Personally I would prefer they handle the databases, redis etc because that way the services you need can be provisioned right alongside your app servers otherwise it undermines the value of having edge servers near your users. Heroku could get away with 3rd parties being responsible for the database software because using AWS it was easy for other companies to be in the same region or zone. https://community.fly.io/t/can-we-get-an-update-on-managed-db-options-with-fly-io/5183 https://community.fly.io/t/can-we-get-an-update-on-managed-d...

yewenjie 4y ago

I like Fly.io but I wish it offered something with Nix in the build process like Railway has recently introduced. https://github.com/railwayapp/nixpacks https://github.com/railwayapp/nixpacks

tptacek 4y ago
It looks like these just generate OCI containers; that's all we need at Fly.io to take your container, so you might be able to just use these. (We've been working for a couple months on Nix, especially for Rails apps, but I don't have status to report).

neya 4y ago

> I wouldn't straight out recommend fly.io. See, part of Heroku's value proposition was their excellent support. I had asked fly.io to delete my account since there wasn't a provision to delete it from their interface and they never bothered to reply and put me in some kind of shadow ban from re-registering with my email. I mean if this is how you're going to treat your customers, then good luck! I'm yet to try out railway.app and..looks interesting to say the least.

traspler 4y ago
Same thing happened to me with Lime (the bike and scooter „rental“ company) after they kept charging my old CC even after deleting and adding a new one, which creeped me out as I would hope a delete action on a payment method actually means delete. Instead of deleting my account they banned me so I could never register again.

manigandham 4y ago

Fly has a nice DX but unfortunately the platform still has major issues with reliability and networking. There are often problems with deploys leading to stuck and unreachable instances or other networking issues. It's probably exacerbated by the new user growth but the slick deploy workflow can't override having an app that works. Render and others are interesting but K8S is still fundamentally better considering all the DX progress there making it pretty easy to get a container running in a cluster.

nik736 4y ago
What exactly makes K8s better?
- sascha_sl 4y ago
  Definitely not the developer experience. But as it is often mentioend, as companies and apps grow, so do their requirements and the need for flexibility. I can't think of a more flexible deployment target that handles a lot of the PaaS concerns than Kubernetes, warts and all. Fly is surprisingly great, volumes + containers is very close to universal for a PaaS, but it certainly can't cover everything that is running in my workplace's kubernetes.
- manigandham 4y ago
  It's basically the platform to build platforms like these (and some of them already run on it). K8S offers the same primitives and more, with progressive complexity as you need it. You can deploy a single container with a 1-line command or an entire PaaS subsystem. It's also more portable than any single platform and you can run it on a few VPS instances or your own bare metal. I've also found it far more reliable than all these PaaS services that have their own issues with no visibility. K8S experience is also more valuable and useful in future projects and there are plenty of nice DX tooling to make deploys easy if that's the blocker.
  - kasey_junk 4y ago
    I’d be very surprised if any edge compute systems run on (a single) K8s cluster. In nearly all cases you’d run at least a cluster per region. K8s also provides no functionality for per region routing or networking between clusters. That is to say, for most of what fly gives you there is no K8s equivalent.

jillesvangurp 4y ago

I don't get this obsession with running a lot of vendor specific tooling on a laptop. Don't people use CI/CD? The only place that will ever deploy anything to anywhere is CI in my setups. And only after the tests pass. I see this over and over again where the first step of using something supposedly user friendly is to install a lot of command line cruft on your snow flake laptop. It only goes downhill from there. Great for amateurs but usually left as an exercise for the reader to beat some sense into bad practices like deploying things from a laptop. IMHO it should start from the other end and actually provide you with a sane CI/CD pipeline out of the box. Google cloud run does this right. You just give it a repository url and it sets up the rest. I used that two years ago and I was up and running in about 2 minutes. Every commit to master went live. CI/CD out of the box. No magical incantations on the command-line. Just develop as you do normally. Zero fuss.

onebot 4y ago

Is fly.io based on erlang?

davidhariri 4y ago

I just switched my hobby apps over to Fly and it is as good as people say it is. As simple or simpler than Heroku in many areas.

70jS8h5L 4y ago

I really wish more of these PaaS solutions would offer UK regions - it's a big issue for us compliance-wise and means we can't use a lot of them. Render.com seems to be one solution - and we're currently using Cloud66 with our own AWS instances as a solution, although I would prefer something lower-effort, like Heroku has historically been.

brunooliv 4y ago

How are rates for small apps? I've read the pricing table in the website and it seems pretty generous, so, for a small poc style app, is this limit enough?