12 ms·

From Go on EC2 to Fly.io

346 points by nalgeon 4y ago

jensneuse 4y ago
[flagged]
zcmack 4y ago
don't know much about fly.io, but i would have definitely deployed my go binary + caddy w/config in a container, rather than setup a systemd service on the host. just me?
pritambarhate 4y ago
Only if Fly.io would focus on giving proper managed PostgreSQL and MySQL as service, they would be default choice for hosting many applications.
- davedx 4y ago
  Yes, I feel this. I have a production app running in Fly with their Postgres offering. It would be good if it was fully managed
- danjac 4y ago
  This is what put me off even trying them out. In 2023 managed DBs should be table stakes for a PAAS.
itake 4y ago
My main complaint about flyio is instability, which you won't notice in your first couple weeks. A couple of times per mo, redis (and occasionally postgres) times out. My TLS cert did not renew, resulting in 8 hours of downtime. You get what you pay for.
- CGamesPlay 4y ago
  I got lucky and hit all of these problems in my first few hours of trying Fly (much to their detriment, unfortunately). I wanted to love it, but I encountered nothing but bugs when I played with it over a weekend a month or so ago. Internal DNS worked for one but not the other of my nodes; Dashboard accepted my credit card but didn't actually upgrade my plan; SSH console would hang, requiring killing the client process with SIGKILL; my builder hung with a Dockerfile that was literally just "FROM ubuntu" and "apt update"; this failure resulted in `flyctl machines list` hanging and `flyctl machines kill` hanging. Maybe it was just a bad weekend at Fly, but their status page was all green, too. So many problems between me and even giving fly a serious try. Unfortunate, but maybe in a year it will be better.
  - mrkurt 4y ago
    It'll definitely be better in a year. It sounds like you hit some of our capacity issues. In a year we'll either be ahead of those, or not growing anymore due to ongoing capacity issues. I'm hoping for the former. The SSH and Builder issues are interesting. Those sound like something related to our wireguard stack.
- benhoyt 4y ago
  Yeah, that would certainly have slowed me down too if I'd experienced that. I haven't had any of these issues. Fingers crossed! And hopefully they're working on stability.
- selcuka 4y ago
  My account got marked as "high possibility of fraud", even though I validated my email and added a credit card they even charged. The error message said that I had to contact support@fly.io but that address only accepts email from paid subscriptions. With no way to evaluate the service, I opted to delete my account.
  - omeletdufromage 4y ago
    Exactly what happened to me as well. In my case, I was (fortunately?) messaged by someone from Fly.io after asking around the community forum how to remedy the issue. I think the person I talked to was inferring that the system got tripped because I was using my own domain for my email address. It's since been corrected, and I still have a handful of services running with them, but getting started with the platform definitely was a rougher experience than I was expecting it to be.
    - lloydatkinson 4y ago
      So they will regard any large company using their service as fraud? Insane
      - wasmitnetzen 4y ago
        Large company? Literally every company I ever worked for, the smallest one were 5 people, had their own domain for emails. And they were not all in IT.
        lloydatkinson 4y ago
        So we agree its insane to cut off every company with a domain? Good.
        ceejayoz 4y ago
        That would be insane, yes. It isn’t the case, though. I signed up with my own domain just fine.
- ZephyrBlu 4y ago
  My main gripe is the wild variation in response time. My server response time seemed to vary from <100ms to >300ms for the same operation.
  - re-thc 4y ago
    Is this due to the network i.e. you get routed to a different server or due to CPU sharing?
    - achempion 4y ago
      isn't the whole selling point of fly is edge servers which supposed to reduce latency
      - re-thc 4y ago
        Sure, but what's edge? The world is big. Can't have servers everywhere (ok, maybe Cloudflare is close). It's possible due to routing decisions that you get sent to a "different edge" at different times.
        marcinzm 4y ago
        So what's the point then? 250ms is enough to literally send traffic to the other side of the world. So why bother with edges if you can just have a single server where most of your customers are and get the same latencies?
    - ZephyrBlu 4y ago
      I thought it could have been because of a shared CPU at first as well, but I upgraded to dedicated CPUs and it didn't make a difference. I don't know whether this is a platform issue with Fly or something else, but it was kind of annoying to have such a high variation with seemingly no way to fix it.
  - ignoramous 4y ago
    fwiw, for non-html workloads we serve (nodejs) with shared-cpu (several 100 requests per second), the latencies (p50, p75) remain consistent.
- quickthrower2 4y ago
  Venture funded stuff like this should be fast, good, cheap, pick 3! Until they need to make a profit or shut down.
  - deleted 4y ago
    [deleted]
- butterfly771 4y ago
  After I have experienced several fly.io render railway northflank platforms, I think the problem with fly.io is that the web console is not fully functional, too dependent on CLI and the response time of the application is unstable. The problem with render is that it is too slow to build, north is similar to railway, and the experience is good. But although the north console is very comprehensive, it is too complicated and dazzling. By contrast, the interface of railway is very simple and comprehensive, and UX is great. (found by wappalyzer analysis that it is based on nextjs,very nice)
  - eschatology 4y ago
    I tried railway and northflank. Really like the UI northflank has; I think anyone familiar with Kubernetes should feel right at home. I also agree with the sentiment that railway ui is simpler.
  - fyzix 4y ago
    I get up to 20secs of downtime when redeploying on railway... I was using the sample golang repo from fly : https://github.com/fly-apps/go-example https://github.com/fly-apps/go-example That's just unacceptible imo.
    - fyzix 4y ago
      More context: The UI shows that the service is available but when I visit the live url, I get a 404. What I think is happening is that the UI shows the status of the underlying container and there is some fault with the reverse proxy they are using to expose the container to the internet. Fly.io doesn't have this issue but I am leery of all the complaints here.
    - ndneighbor 4y ago
      Hey there fyzix! Angelo here, Support Engineer from Railway. I was here procrastinating from work when I saw this comment. The downtime you see is our proxy taking time to cutover- however, we have https://docs.railway.app/deploy/healthchecks https://docs.railway.app/deploy/healthchecks that will only cutover once we have a 200 from your API. This way we can keep your old deploy live and serving requests if and only if it's live. Theres more we can do to make it magical, but this should help in the meantime.
- jamil7 4y ago
  There’s an edge case in which you can lose access to your account as well when switching from github to email login with the same email. It’s an edge case but quite a bad one.
- callahad 4y ago
  Yep. Fly isn't fully baked. Deployed a service earlier this month and got bitten in a few ways: - It took several hours to get a 1 GB disk provisioned (their API would time out and I'd get left with an allocated but unusable disk that couldn't be deleted without deleting the entire app it was attached to.) The Fly forums have numerous reports of the same issue, going back months, across multiple data centers. All resolved with the moral equivalent of "oops, try again later?" - The fly.toml reference is incomplete and internally inconsistent, documenting keys which are not valid, while omitting valid keys that appear elsewhere in the docs. - Volume snapshots are retained for either 5 or 7 days, depending on which of the multiple conflicting docs pages you believe. - I wanted to let them know about that last one, so I emailed the address listed at https://fly.io/docs/about/support/ https://fly.io/docs/about/support/, only to get an autoresponse saying that they don't read that mailbox and that I should pound sand unless I'm already paying them to read my emails. Reading between the lines of their recent blog posts, it seems like a lot of the infrastructure pains are pinned on Nomad, with the hope that moving to Fly Machines / Apps V2 will obviate a lot of those issues. I hope they're right, because what they're trying to deliver is exactly what I want.
  - mrkurt 4y ago
    Well Nomad certainly isn't at fault for our docs. Volume provisioning issues have been a game of whackamole, largely as the result of scaling pains. We've grown like 4x in the last 3 months (thanks, Heroku) and it's put a strain on pretty much everything.
- incangold 4y ago
  Echo this, and I _did_ notice it in my first two weeks. 3 separate issues prevented me deploying. One was my fault, but hard to diagnose because error messages contain no useful information. The other two were the platform falling over, with the support forum having no resolution but plenty of other people in the same boat. Lots to love about fly. The latency is noticeably better than anything I’ve used except cloudflare. Prices are good. Hopefully they’ll get the growing pains sorted and we’ll have another contender.
  - mrkurt 4y ago
    These deploy issues are all kinds of ulcer inducing. They're not strictly Nomad's fault (we're holding it wrong), but the complexity of flyctl -> nomad -> global hosts makes it difficult to bubble errors back up to you. If you end up trying again, give the machines based apps a shot. It's much simpler infrastructure: https://community.fly.io/t/fly-apps-on-machine-prerelease/10219 https://community.fly.io/t/fly-apps-on-machine-prerelease/10...
- mrkurt 4y ago
  The TLS cert renewal was a big failure on our part. I know that's, like, a one strike and you're out problem, but we've improved that part of our stack substantially. It should be much more resilient. Redis/Postgres timeouts sound like they might be a problem we can help with, though. Both those services work through a load balancer with a TCP idle timeout. If you get timeouts after a period of inactivity, it's usually a simple config tweak to have a driver handle that seamlessly. The timeout issues surprised me, more drivers than we expected can't handle a DB connection timing out when it's idle.
- Existenceblinks 4y ago
  I had (a couple years ago) some weird websocket throttle or debouncing characteristic. I tried to construct an evidence, but it's quite hassle so I just ignored it. I think they are too engineering culture. Target is devs, sure, but they could use some product guys.
- itbeho 4y ago
  I'd spend some time reading community.fly.io before committing to it. I recently helped a startup that has been on fly.io and there was a lot of frustration about things not working. it was very frustrating to see un-answered problems reported, fly.io down for what seemed to be many users, the same time seeing a fly.io co-founder arguing about politics all day long here on HN...
  - butterfly771 4y ago
    In fact, when you enter the fly.io console, you will feel that this is an unfinished construction site, especially when you start to deploy a new app, and the frame text icons in the options are simply truncated, which feels rough.
Reubend 4y ago
Maybe I'm missing something, but 500 qps for serving static files seems supremely unimpressive. Fair play about it being more fun, or saving some money from AWS, but I am not convinced that this setup is a good achievement in terms of performance.
- zinodaur 4y ago
  He mentioned one of the pages was querying a db
- benhoyt 4y ago
  Only 1 out of 4 URLs in the test was static. The others are rendered HTML templates (using Go's html/template -- I'll update the article to make that clearer), and one page does two SQL queries. Note that my load test wasn't to see how much I could squeeze out of this, but to determine that it's "more than good enough" for this use case. The typical qps I get from real customers on the site is about 0.5 qps, so I think I'm good. :-)
zackees 4y ago
I skipped over fly.io because I don't want to run a command to deploy an update to an app. I much prefer Render.com and DigitalOcean's setup where you select a repo and then it takes care of the rest with auto update on git push. This seems like a trivial thing to add. If I wanted to use a domain specific configuration file then that's always an option, later.
- seth123456 4y ago
  Fly did send an email linking to one of their articles on how to set it up for github maybe a few hours after the initial setup. I think it took me like 5 minutes to setup deploy on git push to main (or your deploy branch)
- benhoyt 4y ago
  They don't really need to add anything, because you can just use a GitHub Action that run "flyctl deploy". Here is Fly.io's guide to the 15 lines of YAML you can use to do that: https://fly.io/docs/app-guides/continuous-deployment-with-github-actions/ https://fly.io/docs/app-guides/continuous-deployment-with-gi...
  - MarkSweep 4y ago
    If any Fly.io people are reading: this page has Git merge conflicts in it currently. Search for <<< on the page.
  - yencabulator 4y ago
    What's really needed for this to be good is API tokens scoped to something significantly less than "anything my account can do". Fly devs have confirmed this is in the works, think macaroons. The only defense here is that Fly isn't the only party being incredibly sloppy with their API keys. Cloudflare is just as bad.
- mtlynch 4y ago
  >I much prefer Render.com and DigitalOcean's setup where you select a repo and then it takes care of the rest with auto update on git push. Doesn't that force you to use your hosting provider as your CI provider? I've always avoided the automatic "deploy on git push" solutions because I want to keep my CI provider uncoupled from my hosting provider. That way, I can switch hosts without having to rewrite all my CI code.
zebracanevra 4y ago
I'm really happy with using docker and compose for everything. You really can't beat how well it works on a single host. Worrying about having to configure systemd? "restart: always" in compose. Caddy updates? Caddy provides an up to date docker image. You can't get around caddy's config, but tbh, you do it once, and then you're done. It's way better than nginx. Deploying a new version of your go application is just "docker compose up -d".
- margorczynski 4y ago
  Any issues with persistence, like using Postgres? I heard that can be quite funky. Just wondering about having a "native" NGINX reverse-proxy + multiple apps ran via docker-compose on my VPN, seems the most hassle free. Currently using it for integration tests and it works great. Did you maybe consider k8s, maybe as a learning experience?
fhd2 4y ago
I'm pretty happy with fly.io, except for one thing: I moved over two apps from Heroku, lured by the free tier. But you do have to enter your credit card details whether or not you intend to pay. And then they do charge me a few bucks per month for an almost completely unused app. It's probably all in line with the ToS and everything, but I find it a bit shady that I have to investigate this, rather than having a free offering that doesn't suddenly charge me.
- chubot 4y ago
  Hm do they itemize the charges? what are they for?
  - fhd2 4y ago
    CPU - I would assume it's not a mistake, maybe if I dig some more I can figure out how to keep within the allowance, but on Heroku I never had to deal with this kind of thing for free apps.
    - brundolf 4y ago
      I agree, as an individual user I much prefer to be locked in to a fixed rate. And not just for the free tier- I don't want surprises even if I'm already paying As a company with a cushion, hosting a profitable app, it might be worth doing the usage-based pricing to try and save some money. But the risk is just not worth it for smaller projects
- selcuka 4y ago
  It's not a free offering; there is a free allowance. If you exceed that you get charged: - Up to 3 shared-cpu-1x 256mb VMs - 3GB persistent volume storage (total) - 160GB outbound data transfer If you spin up, say, 4 VMs you will pay for it.
  - fhd2 4y ago
    I probably have to fiddle with the settings to stay within 3 CPUs, but since it was heavily recommended as an alternative to Heroku's free tier, I'm a bit disappointed I have to. Maybe they never intended to be recommended for that, don't know.
ddtaylor 4y ago
> It might be “quite trivial”, but it’s still too much work for lazy developers, let alone non-technical people. I don't think you have to be "lazy" to take advantage of the value proposition of saving time or complexity. I think Dropbox and similar are successful because they have put a higher emphasis on their target audiences time than other competitors in the past.
herpderperator 4y ago
The author doesn't seem to explain the before and after cost difference. It used to be $9, and now it's what? Is the 10 cents talking about the AWS S3 pricing or the Fly.io pricing?
- re-thc 4y ago
  The author saved $9 from the change.
- benhoyt 4y ago
  Sorry if that wasn't clear. This was meant to answer it: > Fly.io looked more geeky and command line-oriented, which suited me, and their prices are also ridiculously low: free for up to three small virtual machines (I only need two), and $2/month for small VMs after that. Their free allowance allows up to 3 small VMs and 3 GB of permanent volume space. I'm under that (2 VMs and 2 x 1GB volumes) so I get both my apps for free, and I could add one more. Even if I had to pay the regular rates they charge after the allowance, it'd be only $4.18 per month. In any case, I was paying AWS $9/mo, now I'm paying Fly.io $0/mo, so that's what I saved.
nathants 4y ago
cool transition and fun writeup! for low, intermittent traffic sites, go on lambda might be a better comparison: https://github.com/nathants/libaws/tree/master/examples/simple/go/api https://github.com/nathants/libaws/tree/master/examples/simp...
qwertqwerttt 4y ago
[flagged]
qwertqwerttt 4y ago
[flagged]
fulafel 4y ago
How is the privacy and compliance in Fly.io vs EC2 if I build an app serving European users? Edit: apparently you can select the region, and you can possibly get a pre made DPA document template.
- senden9 4y ago
  Yes. You get a Data Processing Agreement (DPA) for free. That is what you need in the EU for GDPR purposes. Customers with HIPAA compliance needs may need an Business Associate Agreement (BAA). That BBA thing is only included in paid plans.
qwertqwerttt 4y ago
[flagged]
qwertqwerttt 4y ago
[flagged]
qwertqwerttt 4y ago
[flagged]
darthrupert 4y ago
Good for them. Looking superficially at the application they're talking about, it's also possible that a more cloudy implementation of said software would have lowered the costs also on AWS side. Like using lambda functions instead of EC2.
bilinguliar 4y ago
What stops me from using such platforms is the risk that one day for any reason my account can be suspended and I will have to migrate my apps and data. Do you have a strategy for that situation? Your old Ansible branch hopefully is still there and compatible with your recent production code changes. And your sqlite DB is replicated to an external storage and your data is reachable even if you have lost control over “your” PaaS account.
- biorach 4y ago
  > What stops me from using such platforms is the risk that one day for any reason my account can be suspended and I will have to migrate my apps and data. You have found a hosting provider where this is not a risk?
  - Noughmad 4y ago
    If you're on AWS or GCP or Azure, and they terminate your account, and you use only the "standard" services (raw instances, k8s, database, redis, queues, email, etc.) it's generally relatively easy to migrate to one of the other two. Fly is different enough that moving to or from it takes much more time and effort.
    - bilinguliar 4y ago
      Yes, this is my approach, as long as you stick to standard interfaces, you can migrate rather quickly. Your level of abstraction may vary. I stick to VMs after realising how much overhead I had with the cloud as a one-person shop. Teams can interface with k8s which is also standard nowadays, taking you can spawn a cluster fast.
    - nicoburns 4y ago
      > Fly is different enough that moving to or from it takes much more time and effort. It is? Fly seems to be only docker containers. You can't get much more standard than that these days!
    - biorach 4y ago
lenkite 4y ago
Why should HTML files be embedded within the Go binary bloating its size ? And then needing to fiddle and hack around with Go's embedded FileServer to support basic HTTP caching is painful. Is there no facility for a CDN in fly.io ?
- berkle4455 4y ago
  Yeah fly does static/cdn content just fine
- dgb23 4y ago
  I assume there is. But that’s not the point I think. The point of embedding is similar to making a jar from an ops perspective. You “bundle” everything into one thing and you deploy that thing as single binary/archive. Less moving parts, less complexity. Secondly, providing etags/modified headers for serving static assets is not a hack. It’s just not built-in. But it’s perfectly fine to serve those directly from your app server with the appropriate headers, so proxies can serve them directly. In fact I would ask the reverse: why use a CDN when you can use canonical features for deployment (Go embedd, Java jar etc) and serving (HTTP cache headers)? Personally I wouldn’t necessarily use a 3rd party library for this but to each his own.
  - dj_mc_merlin 4y ago
    > why use a CDN when you can use canonical features for deployment (Go embedd, Java jar etc) and serving (HTTP cache headers)? * different work profiles (streaming large amounts of compressed data vs small JSON requests/replies) means that different software is more optimal for each -- an application thread usually is a lot more powerful and does a lot more (and thus is slower in the general case) than an nginx thread * you're using your own compute on your own dime to do what your service provider is probably offering to do for cheaper * bloats the image size -- there is a productivity difference between working with a 150MB image and a 1GB one (debugging, easily diffing changes) Admittedly, these aren't problems for a one man startup or a very low traffic website, but these things do eventually matter as your system grows in size.
byhemechi 4y ago
Fly actually has rudimentary static file hosting: you can use a [[statics]] block in fly.toml and any exact filename match (no index.html etc) will be served directly from the router. I'm not sure this would end up being useful for OP's exact usecase, i'm pretty sure it doesn't set etags. https://fly.io/docs/reference/configuration/#the-statics-sections https://fly.io/docs/reference/configuration/#the-statics-sec...
jokethrowaway 4y ago
The only good thing about EC2 is reliability. You can get equivalent hardware for much cheaper elsewhere and save way more than 9$. Add some load balancing across cheap hosts and you can achieve good reliability. I run things on Digital Ocean, hetzner, ovh, linode, fly: they all cause downtime from time to time. I have clients on azure / Aws / Google and it's a much rarer occurrence. Fly is definitely among the unreliable ones, so you're paying for a simplified deployment / ops experience here - the heroku model. Even at that, configuration is not the easiest and there are gotchas you need to know. Documentation is also pretty sparse and the example images were stale. Getting a build to work was a huge pain. The free offering is nice, but I'm not recommending it for production.
- re-thc 4y ago
  EC2 has Graviton for now, which is "exclusive". Graviton 3 can be nice if you can make it work with your workload.
is_taken 4y ago
One could consider using https://github.com/caarlos0/env https://github.com/caarlos0/env instead of the hand-woven env var handling.
FpUser 4y ago
I currently rent AMD 16 core server with 128GB RAM and 2x2TB NVME drives for around $100 / month from Hetzner. Price for equivalent hardware on Fly (without mentioning drives) is $1,126 / month.
- maeln 4y ago
  Well yes of course. But then you have to manage everything yourself. The whole purpose of fly.io, heroku, raleway, etc, is that you don't have to care (much) about ops & sec. Handling it yourself (or hiring someone to do it) can cost way more than 1000$/m. When you grow big enough it might not be worth it anymore, but for smaller project, it can be really useful. And for the record, at the moment, I host most of my service on my own server.
  - nurettin 4y ago
    This response would have made more sense if fly.io provided fully managed db services.
- vincentkriek 4y ago
  But what would it cost to run what you are actually using?
- re-thc 4y ago
  There's no anycast support and the ability to have servers around the world.
ngrilly 4y ago
Great post! Not sure why giftyweddings.com needs to serve static files with an ETag in the HTTP response header: a hash of the file content is already included in the URL, which means it will invalidated when the content changes, just based on the path, regardless of the ETag.
- benhoyt 4y ago
  Yeah, this is a good point. I've previously just used the "hash in the URL" approach as it seemed more obvious than ETag. I asked Ben Johnson why his hashfs library uses both, and he said "Yeah, that's a good point. I can't remember why I added both. I suppose some proxies may use ETag? I dunno."
  - ngrilly 4y ago
    Haha. Fair enough. Thanks :)
icemelt8 4y ago
[dead]
pearjuice 4y ago
The only problem I have with Fly is that it is VC backed. It's receiving a lot of developer love now, but wonder what happens when it eventually gets acquired by a behemoth in a few years and the same fate as Heroku is bestowed upon it.
- mrkurt 4y ago
  We aren't super interested in selling. I want to work on Fly forever and selling is a quick way to end that. But I also don't think you can build a from-scratch cloud without VC money. It's very expensive.
  - pearjuice 4y ago
    Appreciate the honesty and transparency but sadly VC isn't chasing the profits from being a cloud- or app-server-provider. Looking at the profiles of the VCs which participated in funding rounds, most of them are exit-oriented. A16z's portfolio proudly opens with "exits". Intel Capital is also very proud of their ~50% IPO or acquisition stat. Hopefully you can work on Fly forever but history has learned that probably won't be the case - and that's not judgemental.
    - mrkurt 4y ago
      You'll notice that the ones they feature most are IPOs. Which isn't the same as getting acquired. I'm not opposed to an IPO, I am opposed to get subsumed by a larger company.
  - eatonphil 4y ago
    > But I also don't think you can build a from-scratch cloud without VC money. It's very expensive. Linode did it 20 years ago (somehow). Dunno if there's a more recent example though. :)
CharlesMHend 4y ago
[flagged]
ilrwbwrkhv 4y ago
Why not just use digital ocean or hetzner?
- senden9 4y ago
  Do you mean VPS's (virtual private servers)? Because there you need to take care of the maintainance of the OS, system upgrades, initial setup, etc. With a system like Fly.io you just push your app and the OS is abstracted away from you. That is exactly what the article is about.
  - ilrwbwrkhv 4y ago
    How hard is it to do apt update && apt upgrade -y every once in a while?
usrusr 4y ago
So what's the state of the company behind fly.io? Because if it happens to be going through some stage of VC fueled bought growth, all talk about price comparison isn't worth the air exhaled for speaking.
conaclos 4y ago
Could someone help me I understand What is makinh fly.io different from regular cloud service?
- regulation_d 4y ago
  Depends what you mean by "regular cloud service", but broadly Fly.io and Heroku are examples of Platform-As-A-Service, versus AWS, GCP, Azure, and Digital Ocean which are more Infrastructure-As-A-Service. https://www.redhat.com/en/topics/cloud-computing/iaas-vs-paas-vs-saas https://www.redhat.com/en/topics/cloud-computing/iaas-vs-paa...
krishadi 4y ago
Compared to Code + Docker + AWS Copilot CLI, am I going to see a 10x improvement in my workflow?
sebslomski 4y ago
I wish I could say I love fly.io, but it really is not ready yet for production. A few months back we migrated a non essential production app to fly.io and we've had 3 major downtimes since where we didn't knew at all what was going on. One thing from heroku in 2021 should have been learned here: Communicate before your clients learn about the issue. Communicate open. I hope they improve in the next year
8organicbits 4y ago
I enjoyed this article, but I'm noticing more and more that everything I read about fly is either a fun/low cost side project, or it's a (very impressive) article about fly.io internals. There's very clearly a capable tech team, but I'm confused about their target market. What customer success stories am I missing?
- swyx 4y ago
  i dont work at fly but i do work in devrel and this is pretty common. its basically a joint result of the fact that most content marketing is either about lowering the barriers of adoption and telling an impressive technical story for recruiting and sales; and that most big companies require a lot of hoop jumping to post official case studies; and that fly is still a newish paradigm that most companies haven't yet adopted. i have no doubt they'll come along if fly continues owning mindshare at this level. when its obvious on HN but not yet obvious on the marketing sites you just have to wait a couple years (with some exceptions to the rule, e.g. people often bring up the failure of light table which got significant HN pull and seems to have died out https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=light%20table&sort=byPopularity&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...)
  - recuter 4y ago
    Insightful > i have no doubt they'll come along if fly continues owning mindshare at this level. when its obvious on HN but not yet obvious on the marketing sites you just have to wait a couple years Seems like an accurate observation. Now please elaborate as to why? And how does one shorten this? I am unskilled at devrel and wish to benefit from your experience further. Cheers. :)
    - itake 4y ago
      I think they’re copying digital ocean’s strategy. DO had great tutorials on hosting applications 3-5 years ago. This brought in SEO and social credibility.
    - swyx 4y ago
revskill 4y ago
In a long time till now, Heroku still doesn't support mounting volumes. Is volume mounting the hardest problem in cloud computing ? All buzzwords till now is scammy in the sense that, it doesn't make any sense when you can't cache your data in your local file system.
- simonw 4y ago
  "Is volume mounting the hardest problem in cloud computing ?" It kind of is. If you don't provide a mutable filesystem, you get a whole bunch of benefits: Need to scale to handle more traffic? Start another instance and add it to the load balancer. App crashes for any reason at all (including a hardware failure)? Fire up a fresh instance on another physical server and load balance there instead. Want to provide zero-downtime deployments? Start a new instance running with the new code, switch the load balancer over to serving from that instead, then shut down the old instance. Each of these becomes a LOT more complicated if you offer read-write volume support.
- Existenceblinks 4y ago
  This. DO app platform doesn't support mounting their volume either (wait for 3 years now, and probably won't happen forever). I wonder how render.com make it like it's trivial while the others just assume you wanted a block storage .. nope.
thegeomaster 4y ago
I looked at Fly.io pricing, and boy that's expensive. $558/mo for a virtual machine with 8 dedicated CPU cores and 64GB of RAM. I pay ~$120/mo for a Zen 2 12-core dedicated server with 128GB of RAM. It just doesn't make sense to migrate anything that needs some chunkier resources.
- nielsole 4y ago
  fly.io dedicated cores probably are vCPU aka Hyperthreads anyways. So the gap is even wider.
- ilyt 4y ago
  Cloud pricing is always terrible compared to "just a fucking machine somewhere in a rack" or even more traditional VM providers.
  - thegeomaster 4y ago
    Right, but they add quite a bit of margin from what I see. Correct me if this comparison is not fair: Fly.io, 8 vCPUs, 32GB RAM (dedicated-cpu-8x): $398/mo AWS, 8 vCPUs, 32GB RAM (t3.2xlarge, us-east-2): $240/mo So, 65% more expensive. Quite steep.
    - OJFord 4y ago
      PaaS is also always more expensive than IaaS (which as GP said is always more expensive than I not-aaS). They're charging you more for the convenience of `flyctl region add lhr` or whatever it is vs figuring out the routing & VPCs for example in AWS yourself. It's not all roses though, I find the docs a bit lacking (good on networking - bad on security & storage) and the price of that convenience (aside from literal price) is that it is limiting - as soon as you think 'well I just want a very simple firewall/security group wall' or 'what's the equivalent of allowing only this x to y with an IAM policy', nope, can't do it.
      - thegeomaster 4y ago
lopatin 4y ago
Say I want to write an app, deploy it, and never think about it again. What's the easiest way to do this? Fly.io? AWS Lambda?
- nprateem 4y ago
  Google Cloud Run is very easy.
- the__alchemist 4y ago
  If it's a web app, Heroku is a smooth experience; it lets you deploy by pushing a git repo.
- bordercontrol 4y ago
  Hetzner Ubuntu Server, a good firewall configuration and automated backups. I can't think of anything easier. I tried a lot of stuff, but this just works. For internal applications I basically block all traffic outside of our office network, activate auto updates for the OS and just stick to one version of the app for as long as I can. Edit: and only one app per server. Also only the Hetzner Cloud offering with managed backups and managed firewall.
  - fauigerzigerk 4y ago
    How does this meet the condition "write an app, deploy it, and never think about it again"? As I'm reading it, your setup is the exact opposite of that.
    - bordercontrol 4y ago
      Why do you think you need to touch them after deployment? You just pay the monthly bill. The thing is you can't just deploy and rest usually as there are often security concerns, your provider could run out of service, various system failures which require a restore of an healthy state or similiar. Even if you serve just static files, there could be the need to adjust your DNS, because the provider changed after 5 years something, or some other provider-related configuration. You really want to care for all those things at your frist deploy if you don't want to care for them long-term. The Hetzner firewall makes frequent security app updates mostly unnecessary, Ubuntu auto updates care for the security of the OS, the backups make recovery easy, if Hetzner goes out of service, you can restore your system wherever you want as it is just an Ubuntu server, by keeping only one app per server you also reduce the complexity of the system, separate the systems, so that failure can't spread. Managing a server is nowadays with offerings like Hetzner the easiest way to run apps which just need to work and don't need to scale to exponentially over time. Why add anything on top of it? It's done really within 5 minutes if you know what you do. If you need something which scales and doesn't require file storage / databases, then I'd go for the provider-agnostic Serverless framework. If you need storage and/or databases then it really depends, as Serverless gets costly at these things and more complex and there are more provider-lock-ins. Containers may make mor sense in such cases. At our company we use these two systems to reduce maintaining basically to zero.
YuukiRey 4y ago
I do the same except I use Litestream (litestream.io/) for backing up SQLite. So far using fly.io was nothing but pleasant and allowed me to stop paying ~5EUR for a Digital Ocean droplet.
robertwt7 4y ago
Fly.io is so good, i really like it. Started using it to host my backends for hobby project while all my FE are at vercel. The free version keeps my project running and it is very generous as well! Because of all their generous free tier, I'm willing to pay more for my personal projects and literally host everything at fly lol.
stpedgwdgfhgdd 4y ago
Tip: Use cloudflare R2 for images and backups Saves you traffic costs
ihti_ 4y ago
Fly.io is excellent for testing, small personal projects, and similar, but it's NOT for production!!! Instances can silently fail anytime, and sometimes there are no easy ways to recover. Once I had to go through the process of updating domain DNS to point to the new instance.
- shp0ngle 4y ago
  That’s what I get from reading all these comments here.
- Existenceblinks 4y ago
  I was about to demo my app to someone and quite shock that my app was down. Though, it's super easy to restart with a single fly command.
- mrkurt 4y ago
  I am so confused about what you're describing here. Apps get static IPs, at no point would you need to make a DNS change to route traffic to a new instance. VMs can definitely fail silently. When apps fail, we're not very good at notifying you of what's going on. I'm hoping that improves this year.
  - ihti_ 4y ago
    My domain DNS records were pointed to the Fly app IP. When the app silently died, and support wasn't able to help they suggested me to launch a new app which meant new IP for DNS.
chromatin 4y ago
Very interesting. I have a question regarding the change from a external periodic process (author mentions two: backup database, and send post-wedding email to couple) to goroutine: - if fly.io ever needs to scale your app up to > 1 instance, won't couples receive duplicate emails? (similarly, any other background process like database backup would be run in multiplicity)
- mrkurt 4y ago
  We don't autoscale apps by default, you have to opt in to that. Many apps don't need or want that functionality.
pictur 4y ago
I understand that such sites are paid to avoid maintenance. But if the scale is not too big by renting a vps, I think it is always more logical to set up your own system. Unless of course you want to get your hands dirty.
aziis98 4y ago
I'm litteraly using that same function func getEnvOrDefault(name, defaultValue string) string { value, ok := os.LookupEnv(name) if !ok { value = defaultValue } return value } for some of my projects
- hu3 4y ago
  Curious, is this coincidence related to GitHub Copilot?
- benhoyt 4y ago
  Heh, that's funny. I distinctly remember typing it in from scratch just the other day (no Copilot), and I guess it's short enough it sorta writes itself: the function name is kind of obvious, the name of "defaultValue" is necessary because "default" is a keyword, and so on. I normally do early returns, so it's somewhat surprising I wrote "value = defaultValue" instead of "return defaultValue", but whatever.
alexpotato 4y ago
There are stories from the late 1800s/early 1900s of people creating private mail delivery services as competition to the US Postal Service. There is even a story of the Federal government forcing these companies to make sure that the letters had postage even though they were NOT being delivered by the USPS. Customers would actually pay a premium over the postage to the private company because the overall experience with private company was better than the USPS. I am wondering if something similar is going to happen with AWS: more and more private companies will charge a premium for services built on top of AWS (and therefore reliable) but much easier to use. (I imagine this is probably already happening and I'm sure HN folks will point out examples). PS In the end, these private mail companies were deemed illegal and went out of business.
- samtc 4y ago
  Fly.io is not built on top of AWS. see https://fly.io/docs/reference/regions/ https://fly.io/docs/reference/regions/
  - onekorg 4y ago
    Not sure if still the case, but remember watching a talk (around 2021) where they mentioned they were using different providers. Among them AWS for some regions.
FrostAlot 4y ago
I had the same experience with them. Very simple to deploy when I moved over from Heroku. Was up and running within a couple of hours and only used UI to deploy.

346 points by nalgeon 4y ago

[flagged]

don't know much about fly.io, but i would have definitely deployed my go binary + caddy w/config in a container, rather than setup a systemd service on the host. just me?

pritambarhate 4y ago

Only if Fly.io would focus on giving proper managed PostgreSQL and MySQL as service, they would be default choice for hosting many applications.

davedx 4y ago
Yes, I feel this. I have a production app running in Fly with their Postgres offering. It would be good if it was fully managed
danjac 4y ago
This is what put me off even trying them out. In 2023 managed DBs should be table stakes for a PAAS.

itake 4y ago

My main complaint about flyio is instability, which you won't notice in your first couple weeks. A couple of times per mo, redis (and occasionally postgres) times out. My TLS cert did not renew, resulting in 8 hours of downtime. You get what you pay for.

CGamesPlay 4y ago
I got lucky and hit all of these problems in my first few hours of trying Fly (much to their detriment, unfortunately). I wanted to love it, but I encountered nothing but bugs when I played with it over a weekend a month or so ago. Internal DNS worked for one but not the other of my nodes; Dashboard accepted my credit card but didn't actually upgrade my plan; SSH console would hang, requiring killing the client process with SIGKILL; my builder hung with a Dockerfile that was literally just "FROM ubuntu" and "apt update"; this failure resulted in `flyctl machines list` hanging and `flyctl machines kill` hanging. Maybe it was just a bad weekend at Fly, but their status page was all green, too. So many problems between me and even giving fly a serious try. Unfortunate, but maybe in a year it will be better.
- mrkurt 4y ago
  It'll definitely be better in a year. It sounds like you hit some of our capacity issues. In a year we'll either be ahead of those, or not growing anymore due to ongoing capacity issues. I'm hoping for the former. The SSH and Builder issues are interesting. Those sound like something related to our wireguard stack.
benhoyt 4y ago
Yeah, that would certainly have slowed me down too if I'd experienced that. I haven't had any of these issues. Fingers crossed! And hopefully they're working on stability.
selcuka 4y ago
My account got marked as "high possibility of fraud", even though I validated my email and added a credit card they even charged. The error message said that I had to contact support@fly.io but that address only accepts email from paid subscriptions. With no way to evaluate the service, I opted to delete my account.
- omeletdufromage 4y ago
  Exactly what happened to me as well. In my case, I was (fortunately?) messaged by someone from Fly.io after asking around the community forum how to remedy the issue. I think the person I talked to was inferring that the system got tripped because I was using my own domain for my email address. It's since been corrected, and I still have a handful of services running with them, but getting started with the platform definitely was a rougher experience than I was expecting it to be.
  - lloydatkinson 4y ago
    So they will regard any large company using their service as fraud? Insane
    - wasmitnetzen 4y ago
      Large company? Literally every company I ever worked for, the smallest one were 5 people, had their own domain for emails. And they were not all in IT.
      - lloydatkinson 4y ago
        So we agree its insane to cut off every company with a domain? Good.
        ceejayoz 4y ago
        That would be insane, yes. It isn’t the case, though. I signed up with my own domain just fine.
ZephyrBlu 4y ago
My main gripe is the wild variation in response time. My server response time seemed to vary from <100ms to >300ms for the same operation.
- re-thc 4y ago
  Is this due to the network i.e. you get routed to a different server or due to CPU sharing?
  - achempion 4y ago
    isn't the whole selling point of fly is edge servers which supposed to reduce latency
    - re-thc 4y ago
      Sure, but what's edge? The world is big. Can't have servers everywhere (ok, maybe Cloudflare is close). It's possible due to routing decisions that you get sent to a "different edge" at different times.
      - marcinzm 4y ago
        So what's the point then? 250ms is enough to literally send traffic to the other side of the world. So why bother with edges if you can just have a single server where most of your customers are and get the same latencies?
  - ZephyrBlu 4y ago
    I thought it could have been because of a shared CPU at first as well, but I upgraded to dedicated CPUs and it didn't make a difference. I don't know whether this is a platform issue with Fly or something else, but it was kind of annoying to have such a high variation with seemingly no way to fix it.
- ignoramous 4y ago
  fwiw, for non-html workloads we serve (nodejs) with shared-cpu (several 100 requests per second), the latencies (p50, p75) remain consistent.
quickthrower2 4y ago
Venture funded stuff like this should be fast, good, cheap, pick 3! Until they need to make a profit or shut down.
- deleted 4y ago
  [deleted]
butterfly771 4y ago
After I have experienced several fly.io render railway northflank platforms, I think the problem with fly.io is that the web console is not fully functional, too dependent on CLI and the response time of the application is unstable. The problem with render is that it is too slow to build, north is similar to railway, and the experience is good. But although the north console is very comprehensive, it is too complicated and dazzling. By contrast, the interface of railway is very simple and comprehensive, and UX is great. (found by wappalyzer analysis that it is based on nextjs,very nice)
- eschatology 4y ago
  I tried railway and northflank. Really like the UI northflank has; I think anyone familiar with Kubernetes should feel right at home. I also agree with the sentiment that railway ui is simpler.
- fyzix 4y ago
  I get up to 20secs of downtime when redeploying on railway... I was using the sample golang repo from fly : https://github.com/fly-apps/go-example https://github.com/fly-apps/go-example That's just unacceptible imo.
  - fyzix 4y ago
    More context: The UI shows that the service is available but when I visit the live url, I get a 404. What I think is happening is that the UI shows the status of the underlying container and there is some fault with the reverse proxy they are using to expose the container to the internet. Fly.io doesn't have this issue but I am leery of all the complaints here.
  - ndneighbor 4y ago
    Hey there fyzix! Angelo here, Support Engineer from Railway. I was here procrastinating from work when I saw this comment. The downtime you see is our proxy taking time to cutover- however, we have https://docs.railway.app/deploy/healthchecks https://docs.railway.app/deploy/healthchecks that will only cutover once we have a 200 from your API. This way we can keep your old deploy live and serving requests if and only if it's live. Theres more we can do to make it magical, but this should help in the meantime.
jamil7 4y ago
There’s an edge case in which you can lose access to your account as well when switching from github to email login with the same email. It’s an edge case but quite a bad one.
callahad 4y ago
Yep. Fly isn't fully baked. Deployed a service earlier this month and got bitten in a few ways: - It took several hours to get a 1 GB disk provisioned (their API would time out and I'd get left with an allocated but unusable disk that couldn't be deleted without deleting the entire app it was attached to.) The Fly forums have numerous reports of the same issue, going back months, across multiple data centers. All resolved with the moral equivalent of "oops, try again later?" - The fly.toml reference is incomplete and internally inconsistent, documenting keys which are not valid, while omitting valid keys that appear elsewhere in the docs. - Volume snapshots are retained for either 5 or 7 days, depending on which of the multiple conflicting docs pages you believe. - I wanted to let them know about that last one, so I emailed the address listed at https://fly.io/docs/about/support/ https://fly.io/docs/about/support/, only to get an autoresponse saying that they don't read that mailbox and that I should pound sand unless I'm already paying them to read my emails. Reading between the lines of their recent blog posts, it seems like a lot of the infrastructure pains are pinned on Nomad, with the hope that moving to Fly Machines / Apps V2 will obviate a lot of those issues. I hope they're right, because what they're trying to deliver is exactly what I want.
- mrkurt 4y ago
  Well Nomad certainly isn't at fault for our docs. Volume provisioning issues have been a game of whackamole, largely as the result of scaling pains. We've grown like 4x in the last 3 months (thanks, Heroku) and it's put a strain on pretty much everything.
incangold 4y ago
Echo this, and I _did_ notice it in my first two weeks. 3 separate issues prevented me deploying. One was my fault, but hard to diagnose because error messages contain no useful information. The other two were the platform falling over, with the support forum having no resolution but plenty of other people in the same boat. Lots to love about fly. The latency is noticeably better than anything I’ve used except cloudflare. Prices are good. Hopefully they’ll get the growing pains sorted and we’ll have another contender.
- mrkurt 4y ago
  These deploy issues are all kinds of ulcer inducing. They're not strictly Nomad's fault (we're holding it wrong), but the complexity of flyctl -> nomad -> global hosts makes it difficult to bubble errors back up to you. If you end up trying again, give the machines based apps a shot. It's much simpler infrastructure: https://community.fly.io/t/fly-apps-on-machine-prerelease/10219 https://community.fly.io/t/fly-apps-on-machine-prerelease/10...
mrkurt 4y ago
The TLS cert renewal was a big failure on our part. I know that's, like, a one strike and you're out problem, but we've improved that part of our stack substantially. It should be much more resilient. Redis/Postgres timeouts sound like they might be a problem we can help with, though. Both those services work through a load balancer with a TCP idle timeout. If you get timeouts after a period of inactivity, it's usually a simple config tweak to have a driver handle that seamlessly. The timeout issues surprised me, more drivers than we expected can't handle a DB connection timing out when it's idle.
Existenceblinks 4y ago
I had (a couple years ago) some weird websocket throttle or debouncing characteristic. I tried to construct an evidence, but it's quite hassle so I just ignored it. I think they are too engineering culture. Target is devs, sure, but they could use some product guys.
itbeho 4y ago
I'd spend some time reading community.fly.io before committing to it. I recently helped a startup that has been on fly.io and there was a lot of frustration about things not working. it was very frustrating to see un-answered problems reported, fly.io down for what seemed to be many users, the same time seeing a fly.io co-founder arguing about politics all day long here on HN...
- butterfly771 4y ago
  In fact, when you enter the fly.io console, you will feel that this is an unfinished construction site, especially when you start to deploy a new app, and the frame text icons in the options are simply truncated, which feels rough.

Reubend 4y ago

Maybe I'm missing something, but 500 qps for serving static files seems supremely unimpressive. Fair play about it being more fun, or saving some money from AWS, but I am not convinced that this setup is a good achievement in terms of performance.

zinodaur 4y ago
He mentioned one of the pages was querying a db
benhoyt 4y ago
Only 1 out of 4 URLs in the test was static. The others are rendered HTML templates (using Go's html/template -- I'll update the article to make that clearer), and one page does two SQL queries. Note that my load test wasn't to see how much I could squeeze out of this, but to determine that it's "more than good enough" for this use case. The typical qps I get from real customers on the site is about 0.5 qps, so I think I'm good. :-)

zackees 4y ago

I skipped over fly.io because I don't want to run a command to deploy an update to an app. I much prefer Render.com and DigitalOcean's setup where you select a repo and then it takes care of the rest with auto update on git push. This seems like a trivial thing to add. If I wanted to use a domain specific configuration file then that's always an option, later.

seth123456 4y ago
Fly did send an email linking to one of their articles on how to set it up for github maybe a few hours after the initial setup. I think it took me like 5 minutes to setup deploy on git push to main (or your deploy branch)
benhoyt 4y ago
They don't really need to add anything, because you can just use a GitHub Action that run "flyctl deploy". Here is Fly.io's guide to the 15 lines of YAML you can use to do that: https://fly.io/docs/app-guides/continuous-deployment-with-github-actions/ https://fly.io/docs/app-guides/continuous-deployment-with-gi...
- MarkSweep 4y ago
  If any Fly.io people are reading: this page has Git merge conflicts in it currently. Search for <<< on the page.
- yencabulator 4y ago
  What's really needed for this to be good is API tokens scoped to something significantly less than "anything my account can do". Fly devs have confirmed this is in the works, think macaroons. The only defense here is that Fly isn't the only party being incredibly sloppy with their API keys. Cloudflare is just as bad.
mtlynch 4y ago
>I much prefer Render.com and DigitalOcean's setup where you select a repo and then it takes care of the rest with auto update on git push. Doesn't that force you to use your hosting provider as your CI provider? I've always avoided the automatic "deploy on git push" solutions because I want to keep my CI provider uncoupled from my hosting provider. That way, I can switch hosts without having to rewrite all my CI code.

zebracanevra 4y ago

I'm really happy with using docker and compose for everything. You really can't beat how well it works on a single host. Worrying about having to configure systemd? "restart: always" in compose. Caddy updates? Caddy provides an up to date docker image. You can't get around caddy's config, but tbh, you do it once, and then you're done. It's way better than nginx. Deploying a new version of your go application is just "docker compose up -d".

margorczynski 4y ago
Any issues with persistence, like using Postgres? I heard that can be quite funky. Just wondering about having a "native" NGINX reverse-proxy + multiple apps ran via docker-compose on my VPN, seems the most hassle free. Currently using it for integration tests and it works great. Did you maybe consider k8s, maybe as a learning experience?

fhd2 4y ago

I'm pretty happy with fly.io, except for one thing: I moved over two apps from Heroku, lured by the free tier. But you do have to enter your credit card details whether or not you intend to pay. And then they do charge me a few bucks per month for an almost completely unused app. It's probably all in line with the ToS and everything, but I find it a bit shady that I have to investigate this, rather than having a free offering that doesn't suddenly charge me.

chubot 4y ago
Hm do they itemize the charges? what are they for?
- fhd2 4y ago
  CPU - I would assume it's not a mistake, maybe if I dig some more I can figure out how to keep within the allowance, but on Heroku I never had to deal with this kind of thing for free apps.
  - brundolf 4y ago
    I agree, as an individual user I much prefer to be locked in to a fixed rate. And not just for the free tier- I don't want surprises even if I'm already paying As a company with a cushion, hosting a profitable app, it might be worth doing the usage-based pricing to try and save some money. But the risk is just not worth it for smaller projects
selcuka 4y ago
It's not a free offering; there is a free allowance. If you exceed that you get charged: - Up to 3 shared-cpu-1x 256mb VMs - 3GB persistent volume storage (total) - 160GB outbound data transfer If you spin up, say, 4 VMs you will pay for it.
- fhd2 4y ago
  I probably have to fiddle with the settings to stay within 3 CPUs, but since it was heavily recommended as an alternative to Heroku's free tier, I'm a bit disappointed I have to. Maybe they never intended to be recommended for that, don't know.

ddtaylor 4y ago

> It might be “quite trivial”, but it’s still too much work for lazy developers, let alone non-technical people. I don't think you have to be "lazy" to take advantage of the value proposition of saving time or complexity. I think Dropbox and similar are successful because they have put a higher emphasis on their target audiences time than other competitors in the past.

herpderperator 4y ago

The author doesn't seem to explain the before and after cost difference. It used to be $9, and now it's what? Is the 10 cents talking about the AWS S3 pricing or the Fly.io pricing?

re-thc 4y ago
The author saved $9 from the change.
benhoyt 4y ago
Sorry if that wasn't clear. This was meant to answer it: > Fly.io looked more geeky and command line-oriented, which suited me, and their prices are also ridiculously low: free for up to three small virtual machines (I only need two), and $2/month for small VMs after that. Their free allowance allows up to 3 small VMs and 3 GB of permanent volume space. I'm under that (2 VMs and 2 x 1GB volumes) so I get both my apps for free, and I could add one more. Even if I had to pay the regular rates they charge after the allowance, it'd be only $4.18 per month. In any case, I was paying AWS $9/mo, now I'm paying Fly.io $0/mo, so that's what I saved.

nathants 4y ago

cool transition and fun writeup! for low, intermittent traffic sites, go on lambda might be a better comparison: https://github.com/nathants/libaws/tree/master/examples/simple/go/api https://github.com/nathants/libaws/tree/master/examples/simp...

qwertqwerttt 4y ago

[flagged]

qwertqwerttt 4y ago

[flagged]

fulafel 4y ago

How is the privacy and compliance in Fly.io vs EC2 if I build an app serving European users? Edit: apparently you can select the region, and you can possibly get a pre made DPA document template.

senden9 4y ago
Yes. You get a Data Processing Agreement (DPA) for free. That is what you need in the EU for GDPR purposes. Customers with HIPAA compliance needs may need an Business Associate Agreement (BAA). That BBA thing is only included in paid plans.

qwertqwerttt 4y ago

[flagged]

qwertqwerttt 4y ago

[flagged]

qwertqwerttt 4y ago

[flagged]

darthrupert 4y ago

Good for them. Looking superficially at the application they're talking about, it's also possible that a more cloudy implementation of said software would have lowered the costs also on AWS side. Like using lambda functions instead of EC2.

bilinguliar 4y ago

What stops me from using such platforms is the risk that one day for any reason my account can be suspended and I will have to migrate my apps and data. Do you have a strategy for that situation? Your old Ansible branch hopefully is still there and compatible with your recent production code changes. And your sqlite DB is replicated to an external storage and your data is reachable even if you have lost control over “your” PaaS account.

biorach 4y ago
> What stops me from using such platforms is the risk that one day for any reason my account can be suspended and I will have to migrate my apps and data. You have found a hosting provider where this is not a risk?
- Noughmad 4y ago
  If you're on AWS or GCP or Azure, and they terminate your account, and you use only the "standard" services (raw instances, k8s, database, redis, queues, email, etc.) it's generally relatively easy to migrate to one of the other two. Fly is different enough that moving to or from it takes much more time and effort.
  - bilinguliar 4y ago
    Yes, this is my approach, as long as you stick to standard interfaces, you can migrate rather quickly. Your level of abstraction may vary. I stick to VMs after realising how much overhead I had with the cloud as a one-person shop. Teams can interface with k8s which is also standard nowadays, taking you can spawn a cluster fast.
  - nicoburns 4y ago
    > Fly is different enough that moving to or from it takes much more time and effort. It is? Fly seems to be only docker containers. You can't get much more standard than that these days!
  - biorach 4y ago

lenkite 4y ago

Why should HTML files be embedded within the Go binary bloating its size ? And then needing to fiddle and hack around with Go's embedded FileServer to support basic HTTP caching is painful. Is there no facility for a CDN in fly.io ?

berkle4455 4y ago
Yeah fly does static/cdn content just fine
dgb23 4y ago
I assume there is. But that’s not the point I think. The point of embedding is similar to making a jar from an ops perspective. You “bundle” everything into one thing and you deploy that thing as single binary/archive. Less moving parts, less complexity. Secondly, providing etags/modified headers for serving static assets is not a hack. It’s just not built-in. But it’s perfectly fine to serve those directly from your app server with the appropriate headers, so proxies can serve them directly. In fact I would ask the reverse: why use a CDN when you can use canonical features for deployment (Go embedd, Java jar etc) and serving (HTTP cache headers)? Personally I wouldn’t necessarily use a 3rd party library for this but to each his own.
- dj_mc_merlin 4y ago
  > why use a CDN when you can use canonical features for deployment (Go embedd, Java jar etc) and serving (HTTP cache headers)? * different work profiles (streaming large amounts of compressed data vs small JSON requests/replies) means that different software is more optimal for each -- an application thread usually is a lot more powerful and does a lot more (and thus is slower in the general case) than an nginx thread * you're using your own compute on your own dime to do what your service provider is probably offering to do for cheaper * bloats the image size -- there is a productivity difference between working with a 150MB image and a 1GB one (debugging, easily diffing changes) Admittedly, these aren't problems for a one man startup or a very low traffic website, but these things do eventually matter as your system grows in size.

byhemechi 4y ago

Fly actually has rudimentary static file hosting: you can use a [[statics]] block in fly.toml and any exact filename match (no index.html etc) will be served directly from the router. I'm not sure this would end up being useful for OP's exact usecase, i'm pretty sure it doesn't set etags. https://fly.io/docs/reference/configuration/#the-statics-sections https://fly.io/docs/reference/configuration/#the-statics-sec...

jokethrowaway 4y ago

The only good thing about EC2 is reliability. You can get equivalent hardware for much cheaper elsewhere and save way more than 9$. Add some load balancing across cheap hosts and you can achieve good reliability. I run things on Digital Ocean, hetzner, ovh, linode, fly: they all cause downtime from time to time. I have clients on azure / Aws / Google and it's a much rarer occurrence. Fly is definitely among the unreliable ones, so you're paying for a simplified deployment / ops experience here - the heroku model. Even at that, configuration is not the easiest and there are gotchas you need to know. Documentation is also pretty sparse and the example images were stale. Getting a build to work was a huge pain. The free offering is nice, but I'm not recommending it for production.

re-thc 4y ago
EC2 has Graviton for now, which is "exclusive". Graviton 3 can be nice if you can make it work with your workload.

is_taken 4y ago

One could consider using https://github.com/caarlos0/env https://github.com/caarlos0/env instead of the hand-woven env var handling.

FpUser 4y ago

I currently rent AMD 16 core server with 128GB RAM and 2x2TB NVME drives for around $100 / month from Hetzner. Price for equivalent hardware on Fly (without mentioning drives) is $1,126 / month.

maeln 4y ago
Well yes of course. But then you have to manage everything yourself. The whole purpose of fly.io, heroku, raleway, etc, is that you don't have to care (much) about ops & sec. Handling it yourself (or hiring someone to do it) can cost way more than 1000$/m. When you grow big enough it might not be worth it anymore, but for smaller project, it can be really useful. And for the record, at the moment, I host most of my service on my own server.
- nurettin 4y ago
  This response would have made more sense if fly.io provided fully managed db services.
vincentkriek 4y ago
But what would it cost to run what you are actually using?
re-thc 4y ago
There's no anycast support and the ability to have servers around the world.

ngrilly 4y ago

Great post! Not sure why giftyweddings.com needs to serve static files with an ETag in the HTTP response header: a hash of the file content is already included in the URL, which means it will invalidated when the content changes, just based on the path, regardless of the ETag.

benhoyt 4y ago
Yeah, this is a good point. I've previously just used the "hash in the URL" approach as it seemed more obvious than ETag. I asked Ben Johnson why his hashfs library uses both, and he said "Yeah, that's a good point. I can't remember why I added both. I suppose some proxies may use ETag? I dunno."
- ngrilly 4y ago
  Haha. Fair enough. Thanks :)

icemelt8 4y ago

[dead]

pearjuice 4y ago

The only problem I have with Fly is that it is VC backed. It's receiving a lot of developer love now, but wonder what happens when it eventually gets acquired by a behemoth in a few years and the same fate as Heroku is bestowed upon it.

mrkurt 4y ago
We aren't super interested in selling. I want to work on Fly forever and selling is a quick way to end that. But I also don't think you can build a from-scratch cloud without VC money. It's very expensive.
- pearjuice 4y ago
  Appreciate the honesty and transparency but sadly VC isn't chasing the profits from being a cloud- or app-server-provider. Looking at the profiles of the VCs which participated in funding rounds, most of them are exit-oriented. A16z's portfolio proudly opens with "exits". Intel Capital is also very proud of their ~50% IPO or acquisition stat. Hopefully you can work on Fly forever but history has learned that probably won't be the case - and that's not judgemental.
  - mrkurt 4y ago
    You'll notice that the ones they feature most are IPOs. Which isn't the same as getting acquired. I'm not opposed to an IPO, I am opposed to get subsumed by a larger company.
- eatonphil 4y ago
  > But I also don't think you can build a from-scratch cloud without VC money. It's very expensive. Linode did it 20 years ago (somehow). Dunno if there's a more recent example though. :)

CharlesMHend 4y ago

[flagged]

ilrwbwrkhv 4y ago

Why not just use digital ocean or hetzner?

senden9 4y ago
Do you mean VPS's (virtual private servers)? Because there you need to take care of the maintainance of the OS, system upgrades, initial setup, etc. With a system like Fly.io you just push your app and the OS is abstracted away from you. That is exactly what the article is about.
- ilrwbwrkhv 4y ago
  How hard is it to do apt update && apt upgrade -y every once in a while?

usrusr 4y ago

So what's the state of the company behind fly.io? Because if it happens to be going through some stage of VC fueled bought growth, all talk about price comparison isn't worth the air exhaled for speaking.

conaclos 4y ago

Could someone help me I understand What is makinh fly.io different from regular cloud service?

regulation_d 4y ago
Depends what you mean by "regular cloud service", but broadly Fly.io and Heroku are examples of Platform-As-A-Service, versus AWS, GCP, Azure, and Digital Ocean which are more Infrastructure-As-A-Service. https://www.redhat.com/en/topics/cloud-computing/iaas-vs-paas-vs-saas https://www.redhat.com/en/topics/cloud-computing/iaas-vs-paa...

krishadi 4y ago

Compared to Code + Docker + AWS Copilot CLI, am I going to see a 10x improvement in my workflow?

sebslomski 4y ago

I wish I could say I love fly.io, but it really is not ready yet for production. A few months back we migrated a non essential production app to fly.io and we've had 3 major downtimes since where we didn't knew at all what was going on. One thing from heroku in 2021 should have been learned here: Communicate before your clients learn about the issue. Communicate open. I hope they improve in the next year

8organicbits 4y ago

I enjoyed this article, but I'm noticing more and more that everything I read about fly is either a fun/low cost side project, or it's a (very impressive) article about fly.io internals. There's very clearly a capable tech team, but I'm confused about their target market. What customer success stories am I missing?

swyx 4y ago
i dont work at fly but i do work in devrel and this is pretty common. its basically a joint result of the fact that most content marketing is either about lowering the barriers of adoption and telling an impressive technical story for recruiting and sales; and that most big companies require a lot of hoop jumping to post official case studies; and that fly is still a newish paradigm that most companies haven't yet adopted. i have no doubt they'll come along if fly continues owning mindshare at this level. when its obvious on HN but not yet obvious on the marketing sites you just have to wait a couple years (with some exceptions to the rule, e.g. people often bring up the failure of light table which got significant HN pull and seems to have died out https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=light%20table&sort=byPopularity&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...)
- recuter 4y ago
  Insightful > i have no doubt they'll come along if fly continues owning mindshare at this level. when its obvious on HN but not yet obvious on the marketing sites you just have to wait a couple years Seems like an accurate observation. Now please elaborate as to why? And how does one shorten this? I am unskilled at devrel and wish to benefit from your experience further. Cheers. :)
  - itake 4y ago
    I think they’re copying digital ocean’s strategy. DO had great tutorials on hosting applications 3-5 years ago. This brought in SEO and social credibility.
  - swyx 4y ago

revskill 4y ago

In a long time till now, Heroku still doesn't support mounting volumes. Is volume mounting the hardest problem in cloud computing ? All buzzwords till now is scammy in the sense that, it doesn't make any sense when you can't cache your data in your local file system.

simonw 4y ago
"Is volume mounting the hardest problem in cloud computing ?" It kind of is. If you don't provide a mutable filesystem, you get a whole bunch of benefits: Need to scale to handle more traffic? Start another instance and add it to the load balancer. App crashes for any reason at all (including a hardware failure)? Fire up a fresh instance on another physical server and load balance there instead. Want to provide zero-downtime deployments? Start a new instance running with the new code, switch the load balancer over to serving from that instead, then shut down the old instance. Each of these becomes a LOT more complicated if you offer read-write volume support.
Existenceblinks 4y ago
This. DO app platform doesn't support mounting their volume either (wait for 3 years now, and probably won't happen forever). I wonder how render.com make it like it's trivial while the others just assume you wanted a block storage .. nope.

thegeomaster 4y ago

I looked at Fly.io pricing, and boy that's expensive. $558/mo for a virtual machine with 8 dedicated CPU cores and 64GB of RAM. I pay ~$120/mo for a Zen 2 12-core dedicated server with 128GB of RAM. It just doesn't make sense to migrate anything that needs some chunkier resources.

nielsole 4y ago
fly.io dedicated cores probably are vCPU aka Hyperthreads anyways. So the gap is even wider.
ilyt 4y ago
Cloud pricing is always terrible compared to "just a fucking machine somewhere in a rack" or even more traditional VM providers.
- thegeomaster 4y ago
  Right, but they add quite a bit of margin from what I see. Correct me if this comparison is not fair: Fly.io, 8 vCPUs, 32GB RAM (dedicated-cpu-8x): $398/mo AWS, 8 vCPUs, 32GB RAM (t3.2xlarge, us-east-2): $240/mo So, 65% more expensive. Quite steep.
  - OJFord 4y ago
    PaaS is also always more expensive than IaaS (which as GP said is always more expensive than I not-aaS). They're charging you more for the convenience of `flyctl region add lhr` or whatever it is vs figuring out the routing & VPCs for example in AWS yourself. It's not all roses though, I find the docs a bit lacking (good on networking - bad on security & storage) and the price of that convenience (aside from literal price) is that it is limiting - as soon as you think 'well I just want a very simple firewall/security group wall' or 'what's the equivalent of allowing only this x to y with an IAM policy', nope, can't do it.
    - thegeomaster 4y ago

lopatin 4y ago

Say I want to write an app, deploy it, and never think about it again. What's the easiest way to do this? Fly.io? AWS Lambda?

nprateem 4y ago
Google Cloud Run is very easy.
the__alchemist 4y ago
If it's a web app, Heroku is a smooth experience; it lets you deploy by pushing a git repo.
bordercontrol 4y ago
Hetzner Ubuntu Server, a good firewall configuration and automated backups. I can't think of anything easier. I tried a lot of stuff, but this just works. For internal applications I basically block all traffic outside of our office network, activate auto updates for the OS and just stick to one version of the app for as long as I can. Edit: and only one app per server. Also only the Hetzner Cloud offering with managed backups and managed firewall.
- fauigerzigerk 4y ago
  How does this meet the condition "write an app, deploy it, and never think about it again"? As I'm reading it, your setup is the exact opposite of that.
  - bordercontrol 4y ago
    Why do you think you need to touch them after deployment? You just pay the monthly bill. The thing is you can't just deploy and rest usually as there are often security concerns, your provider could run out of service, various system failures which require a restore of an healthy state or similiar. Even if you serve just static files, there could be the need to adjust your DNS, because the provider changed after 5 years something, or some other provider-related configuration. You really want to care for all those things at your frist deploy if you don't want to care for them long-term. The Hetzner firewall makes frequent security app updates mostly unnecessary, Ubuntu auto updates care for the security of the OS, the backups make recovery easy, if Hetzner goes out of service, you can restore your system wherever you want as it is just an Ubuntu server, by keeping only one app per server you also reduce the complexity of the system, separate the systems, so that failure can't spread. Managing a server is nowadays with offerings like Hetzner the easiest way to run apps which just need to work and don't need to scale to exponentially over time. Why add anything on top of it? It's done really within 5 minutes if you know what you do. If you need something which scales and doesn't require file storage / databases, then I'd go for the provider-agnostic Serverless framework. If you need storage and/or databases then it really depends, as Serverless gets costly at these things and more complex and there are more provider-lock-ins. Containers may make mor sense in such cases. At our company we use these two systems to reduce maintaining basically to zero.

YuukiRey 4y ago

I do the same except I use Litestream (litestream.io/) for backing up SQLite. So far using fly.io was nothing but pleasant and allowed me to stop paying ~5EUR for a Digital Ocean droplet.

robertwt7 4y ago

Fly.io is so good, i really like it. Started using it to host my backends for hobby project while all my FE are at vercel. The free version keeps my project running and it is very generous as well! Because of all their generous free tier, I'm willing to pay more for my personal projects and literally host everything at fly lol.

stpedgwdgfhgdd 4y ago

Tip: Use cloudflare R2 for images and backups Saves you traffic costs

ihti_ 4y ago

Fly.io is excellent for testing, small personal projects, and similar, but it's NOT for production!!! Instances can silently fail anytime, and sometimes there are no easy ways to recover. Once I had to go through the process of updating domain DNS to point to the new instance.

shp0ngle 4y ago
That’s what I get from reading all these comments here.
Existenceblinks 4y ago
I was about to demo my app to someone and quite shock that my app was down. Though, it's super easy to restart with a single fly command.
mrkurt 4y ago
I am so confused about what you're describing here. Apps get static IPs, at no point would you need to make a DNS change to route traffic to a new instance. VMs can definitely fail silently. When apps fail, we're not very good at notifying you of what's going on. I'm hoping that improves this year.
- ihti_ 4y ago
  My domain DNS records were pointed to the Fly app IP. When the app silently died, and support wasn't able to help they suggested me to launch a new app which meant new IP for DNS.

chromatin 4y ago

Very interesting. I have a question regarding the change from a external periodic process (author mentions two: backup database, and send post-wedding email to couple) to goroutine: - if fly.io ever needs to scale your app up to > 1 instance, won't couples receive duplicate emails? (similarly, any other background process like database backup would be run in multiplicity)

mrkurt 4y ago
We don't autoscale apps by default, you have to opt in to that. Many apps don't need or want that functionality.

pictur 4y ago

I understand that such sites are paid to avoid maintenance. But if the scale is not too big by renting a vps, I think it is always more logical to set up your own system. Unless of course you want to get your hands dirty.

aziis98 4y ago

I'm litteraly using that same function func getEnvOrDefault(name, defaultValue string) string { value, ok := os.LookupEnv(name) if !ok { value = defaultValue } return value } for some of my projects

hu3 4y ago
Curious, is this coincidence related to GitHub Copilot?
benhoyt 4y ago
Heh, that's funny. I distinctly remember typing it in from scratch just the other day (no Copilot), and I guess it's short enough it sorta writes itself: the function name is kind of obvious, the name of "defaultValue" is necessary because "default" is a keyword, and so on. I normally do early returns, so it's somewhat surprising I wrote "value = defaultValue" instead of "return defaultValue", but whatever.

alexpotato 4y ago

There are stories from the late 1800s/early 1900s of people creating private mail delivery services as competition to the US Postal Service. There is even a story of the Federal government forcing these companies to make sure that the letters had postage even though they were NOT being delivered by the USPS. Customers would actually pay a premium over the postage to the private company because the overall experience with private company was better than the USPS. I am wondering if something similar is going to happen with AWS: more and more private companies will charge a premium for services built on top of AWS (and therefore reliable) but much easier to use. (I imagine this is probably already happening and I'm sure HN folks will point out examples). PS In the end, these private mail companies were deemed illegal and went out of business.

samtc 4y ago
Fly.io is not built on top of AWS. see https://fly.io/docs/reference/regions/ https://fly.io/docs/reference/regions/
- onekorg 4y ago
  Not sure if still the case, but remember watching a talk (around 2021) where they mentioned they were using different providers. Among them AWS for some regions.

FrostAlot 4y ago

I had the same experience with them. Very simple to deploy when I moved over from Heroku. Was up and running within a couple of hours and only used UI to deploy.