[HN Gopher] Fly.io: The reclaimer of Heroku's magic
___________________________________________________________________
Fly.io: The reclaimer of Heroku's magic
Author : sealeck
Score : 171 points
Date : 2022-05-15 19:56 UTC (3 hours ago)
(HTM) web link (christine.website)
(TXT) w3m dump (christine.website)
| onphonenow wrote:
| 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/) - 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).
| newaccount2021 wrote:
| colesantiago wrote:
| Bilal_io wrote:
| Edge on Android with the built-in AdBlock Plus prevented all
| ads from showing up.
| sealeck wrote:
| I mean you could just install an ad blocker.
| normie3000 wrote:
| No ads for me either
| st3fan wrote:
| 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 wrote:
| 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 wrote:
| 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.
| krn wrote:
| > 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
| DizzyDoo wrote:
| 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....
| joseph wrote:
| 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.
| [deleted]
| pharmakom wrote:
| Can someone explain what fly.io actually _is_ for someone with an
| AWS background?
| jjtheblunt wrote:
| the website for fly.io is extremely well written in explaining
| fly.io in terms of AWS
| [deleted]
| normie3000 wrote:
| How mature is fly.io?
| throwawaycuriou wrote:
| Define mature
| mrkurt wrote:
| 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 wrote:
| 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 wrote:
| 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.
| sanjayio wrote:
| Where would you feel comfortable running pacemaker infra?
| Half-joking here.
| [deleted]
| Shadonototra wrote:
| 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
|
| --
|
| 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
| config_yml wrote:
| Does fly.io have the same git push deploy magic?
| jchw wrote:
| 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.
| sergiomattei wrote:
| 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 wrote:
| Why do you need to SFTP into a disk?
| sergiomattei wrote:
| 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 wrote:
| Can you not ssh into a fly instance and then pull?
| sergiomattei wrote:
| No. Flyctl SSH does not allow this functionality.
| [deleted]
| mrkurt wrote:
| We've been kicking around ideas for managing files on volumes.
| This is a common problem - it's actually more difficult than
| you'd expect because "securitah". Once your volume is mounted
| in one of your VMs, we can't run tools outside the VM to let
| you manage the file system. On something like k8s with vanilla
| Docker, we could. But no one should run multitenant Docker.
|
| It's not really an excuse, just a reason it's taking longer to
| solve than we'd like.
|
| The errors on the web UI sucked. These have improved
| drastically in the last three months (because we have smart,
| dedicated people working on fullstack for us now).
| sergiomattei wrote:
| Thank you for the response. I want to love your service.
|
| Will keep an eye on the changelogs to see when I can test
| deploy my apps.
| the__alchemist wrote:
| > 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.
| hthrowaway5 wrote:
| 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?
| chasd00 wrote:
| 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.
| brundolf wrote:
| 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.
| sanjayio wrote:
| Big concern of mine as well. They take your CC for usage, which
| is reasonable given bad actors, but then I can't put a limit on
| my monthly charges.
| detaro wrote:
| That's also something that has kept me with VPS hosts over
| cloudy things for hobby stuff: a) included traffic amount is
| vastly higher there, leading to way lower cost per GB if you
| need it and b) they usually do just cap you if you exceed
| traffic and don't opt-in to pay more.
| natly wrote:
| Just use a static hoster for a blog site (like netlify or even
| github pages).
| ushakov wrote:
| what if they want to use a CMS?
| pkalinowski wrote:
| https://forestry.io could help
| [deleted]
| brundolf wrote:
| I've got a small amount of dynamic content
| skrtskrt wrote:
| 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
| [deleted]
| mrkurt wrote:
| This is a problem. And a bit of an own goal on our part.
|
| I hate services that don't put a price on things like bandwidth
| (because there's always a price!). So we priced bandwidth and
| made it transparent. You can put an app on Fly.io and server
| petabytes of data every month, if you want. We'll never
| complain that you're serving the wrong content type.
|
| But the reality is - having an unlimited bandwidth promise is
| perfect for for a fire and forget blog site. We're not doing
| ourselves any favors with scary pricing for that kind of app.
| brundolf wrote:
| I think it's also fine to just say "that's not our primary
| target market". Just thought it was worth pointing out as a
| (perhaps small?) segment of Heroku's market, if we're
| comparing apples to apples
| mrkurt wrote:
| Oh but you are! And it won't even cost you anything. I'd
| bet money your blog fits in our free tier, we just don't
| (a) tell you that and (b) solve the "what happens if
| there's a bandwidth burst" problem.
| brundolf wrote:
| Yeah, I also supposed that it would probably _mostly_ fit
| in the free tier, which is great. But I 'd lose a small
| amount of sleep over the possibility of getting a huge
| bandwidth burst (DDOS or otherwise) that goes straight to
| my bank account
|
| A feature that could help would be giving people the
| option to set a cost limit, where if their site surpasses
| that limit in a given month you just pull it offline
| instead of charging more money. That's what I'd want for
| my blog site, and I've heard others request such a
| feature from other cloud providers
| ignoramous wrote:
| > _We 'll never complain that you're serving the wrong
| content type._
|
| Cloudflare shouldn't restrict media (video, images, and
| audio) from its unlimited bandwidth promise for Workers and
| R2 (though, ToS doesn't yet reflect that).
|
| https://news.ycombinator.com/item?id=28682885
|
| > _But the reality is - having an unlimited bandwidth promise
| is perfect for for a fire and forget blog site_
|
| I think, an auto _flyctl pause -a <myapp>_ when _myapp_
| exceeds _$x_ in charges (with an auto-resume when the billing
| rolls over) may serve as a viable interim solution. May be
| this is already possible with fly.io 's graphql api?
| EnKopVand wrote:
| I don't want an unlimited bandwidth promise, I want a cap
| that I know can never be exceeded. I mean, I use Azure
| professionally and one of the key reasons I don't use it to
| host my own stuff is exactly because it could potentially
| become very expensive. I'd rather have my own stuff shut down
| until I decide what I want to do with it.
|
| Things like alerts are fine, professionally, but not for
| things like running a small app, blog or whatever, that
| you're not sure where is heading.
|
| I don't think anything I've build on my own time has ever
| ended up breaking my bank, but signing up my credit card is a
| risk I'm never going to take, and I'm fairly certain I'm not
| alone in that. Of course I have no idea if there are enough
| of us to make small scale fixed prices products profitable at
| scale.
| mrkurt wrote:
| We actually launched with that feature:
| https://news.ycombinator.com/item?id=22616857
|
| No one took us up on it. What we found is that the majority
| of people want their stuff to stay up, and the right UX for
| "shut it down so you don't get billed" is not obvious.
|
| We ended up implementing prepayment instead. If you sign up
| and buy $25 in credit, we'll just suspend your apps when
| the credit runs out.
|
| Bandwidth is weird because we have to pay for it (as does
| every other provider). We aren't yet in a position where we
| can just make it free without limits. Maybe next year. :)
| brundolf wrote:
| I can't speak for your whole market, but I know for me
| the pre-loading flow sounds really clunky because I'd
| have to go and manually add funds each month (right?)
|
| It's understandable if your usage data showed the fee-
| capping feature just wasn't popular enough to be worth
| maintaining, though that would surprise me based on this
| thread (but possibly HN just isn't representative of the
| whole market)
| ceejayoz wrote:
| I'd be happy with a "refill if under $10 up to $x/month".
| If they can cut off when you're out of credit they can
| presumably do it for other criteria, too.
| bsder wrote:
| > And a bit of an own goal on our part.
|
| More than a bit.
|
| Simply give people the option to put a charge limit and let
| the app be offline when that limit gets hit. Don't make it
| the default, but do allow people to do it.
|
| This would resolve 99% of the fear people have. And most
| people wouldn't set the limit anyway. However, your
| _knowledgable_ people might set it, and those are the ones
| you 're most trying to attract.
| 2c2c2c wrote:
| 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 ?
| jchw wrote:
| 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.
| atonse wrote:
| I think it is because they are refreshingly open about their
| stack and people love their writing tone.
|
| And the architecture seems solid.
| sanjayio wrote:
| Agreed, really enjoyed their tone on explaining SQLite and
| litestream.
| mavbo wrote:
| 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 wrote:
| these were the reasons we chose fly in the end; very happy
| with it
| sergiotapia wrote:
| 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 wrote:
| 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.
| mountainriver wrote:
| jedisct1 wrote:
| Koyeb https://www.koyeb.com also feels magical.
| ushakov wrote:
| i'm running 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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).
| taylorlapeyre wrote:
| 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.
| anurag wrote:
| Render has review apps (https://render.com/docs/preview-
| environments). We're actively working on pipelines (early
| access ETA late summer).
| taylorlapeyre wrote:
| Any plans for a chatops extension for Slack? The best think
| about Heroku is being able to say "/deploy [app]/[branch] to
| [environment]", and have it Just Work, all with inline
| threads that convey status updates about the deployment. Does
| Render plan to build something like that?
| anurag wrote:
| No immediate plans, but I'd love to see this on Render at
| some point, and not just for Slack.
| [deleted]
| mrkurt wrote:
| First, Heroku's pipelines and GitHub integration are (or, I
| guess, were) excellent.
|
| We (Fly.io) intentionally didn't build a pipeline replacement.
| We exist for one reason: to run apps close to users. We're just
| now to the size where we can do that well. It'll be a while
| before we can get good at a second thing. Heroku shipped them
| something like 8 years after they launched.
|
| At the same time, GitHub actions and Buildkite are _very_ good.
| They're less opinionated than Heroku Pipelines, but I don't
| regret figuring out how to use them for my own projects.
|
| I think there's a chance that emulating Heroku that closely is
| a path to failure in the 2020s.
| taylorlapeyre wrote:
| Yeah, totally get that.
|
| > I think there's a chance that emulating Heroku that closely
| is a path to failure in the 2020s.
|
| I'm not sure I agree, considering that a different platform
| emulating this exact setup with ~zero configuration is
| basically everything we want! GitHub actions is (I agree)
| really great and very versatile, but I'll take Heroku's UI
| over digging through actions plugin documentation for hours
| any day.
| EqNoteqp wrote:
| 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.
| closeparen wrote:
| Chat is a multi-player CLI. Anything you would do in a
| terminal that your team members should also know about can
| profitably be integrated with chat.
| bri3d wrote:
| 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?"
| tshaddox wrote:
| Perhaps for looking back to see the history of things, a
| unified ledger is convenient. But as a notifications/alerts
| solution it's terrible because it essentially guarantees
| that the signal to noise ratio will be incredibly low.
| kbrisso wrote:
| 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.
| daxfohl wrote:
| 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!
| anon3949494 wrote:
| 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.
| sanjayio wrote:
| I'm always confused why edge services are always selling points
| given point 1. The most basic of backend services won't be able
| to completely utilize edge services.
| anon3949494 wrote:
| Yep, for anyone confused on how this works:
|
| You'd still be sending writes to a single region (leader). If
| the leader is located across the world from the request's
| origin, there will be a significant latency. Not to mention
| you need to wait for that write to replicate across the world
| before it becomes generally available.
| mrkurt wrote:
| This is the distribute-your-Rails-app-without-making-any-
| code-changes version of that story. It works great for apps
| that are 51% or more read heavy. You drop our library in,
| add a region, and off you go. The library takes care of
| eventual consistency issues.
|
| HTTP requests that write to the DB are basically the same
| speed as "Heroku, but in one place". If you're building
| infrastructure for all the full stack devs you can target,
| this is a good way to do it.
|
| Distributing write heavy work loads is an application
| architecture problem. You can do it with something like
| CockroachDB, but you have to model your data specifically
| to solve that problem. We have maybe 5 customers who've
| made that leap.
|
| In our experience, people get a huge boost from read
| replicas without needing to change their app (or learn to
| model data for geo-distribution).
| anon3949494 wrote:
| It's also trivial to serve read requests from a caching
| layer or via a CDN. At any sufficient scale, you're
| probably going to need a CDN anyway, whether your
| database is replicated or not. You don't want every read
| to hit your database.
| jrockway wrote:
| I don't think this is that trivial. I've never seen it
| done correctly. It typically manifests itself as not
| being able to read your own writes, and I see this all
| the time (often from companies that have blog posts about
| how smart their caching algorithm is). For example, you
| add something to a list, then you're redirected to the
| list, and it's not there. Then you press refresh and it
| is.
|
| I guess that's acceptable because people don't really
| look for the feedback; why do users add the same thing to
| the list twice, why does everyone hit the refresh button
| after adding an item to the list, etc. It's because the
| bug happens after the user is committed to using your
| service (contract, cost of switching too high; so you
| don't see adding the cache layer correspond to "churn"),
| and that it's annoying but not annoying enough to file a
| support ticket (so you don't see adding the cache layer
| correspond to increased support burden).
|
| All I can say is, be careful. I wouldn't annoy my users
| to save a small amount of money. That the industry as a
| whole is oblivious to quality doesn't mean that it's okay
| for you to be oblivious about quality.
|
| (Corollary: relaxing the transactional isolation level on
| your database to increase performance is very hard to
| reason about it. Do some tests and your eyes will pop out
| of your head.)
| mrkurt wrote:
| Database read request are not the same as readonly HTTP
| requests. I am much happier having all requests hit my
| app process than I am trying to do the CDN dance.
|
| Right now your choices are: run a database in on region
| and:
|
| 1. Use the weird HTTP header based cache API with a
| boring CDN
|
| 2. Write a second, JS based app with Workers or Deno
| Deploy that can do more sophisticated data caching
|
| 3. Just put your database close to users. You can use us
| for this, or you can use something like Cloud Flare
| Workers and their databases.
|
| My hot take is: if something like Fly.io had existed in
| 1998, most developers wouldn't bother with a CDN.
|
| Weirdly, most Heroku developers already don't bother with
| a CDN. It's an extra layer that's not always worth it.
| kasey_junk wrote:
| It's a tremendous latency speed up for read heavy apps that
| can tolerate eventually consistent read replicas. Any app
| using a popular sql rdbms likely falls into this category at
| scale. Any app using a redid cache likely falls into this
| category at scale.
|
| Also any app that has global clients and terminates ssl
| likely benefits from edge compute.
| closeparen wrote:
| Hot take: if people spent half the energy doing multi-region
| that they today spend screwing around with Kubernetes, they'd
| be a hell of a lot more reliable.
| jpgvm wrote:
| I think people misconstrue the benefits of k8s to be related
| to reliability or similar. Ultimately it's about the API and
| the consistency and productivity it offers.
|
| For larger teams having a well defined API that delineates
| applications from infrastructure that doesn't require extreme
| specialist knowledge (it still requires some specialist
| knowledge but vastly less than direct manipulation of
| resources via something like Terraform) is a massive
| productivity boost.
|
| Of course none of that matters if you have 4 developers like
| OP but for folks like myself that routinely end up at places
| with 300+ engineers then it's a huge deal.
| Trasmatta wrote:
| > I think people misconstrue the benefits of k8s to be
| related to reliability or similar. Ultimately it's about
| the API and the consistency and productivity it offers
|
| I think this is the first time I've heard somebody say one
| of the benefits of kubernetes was productivity.
| donmcronald wrote:
| > It's easy to forget that most companies are a handful of
| people or just solo devs.
|
| I have the same complaint all the way down to simple sysadmin
| tasks. Ex: MS365 has a lot of churn on features and changes.
| It's like they think everyone has a team of admins for it when
| in reality a lot of small businesses would be satisfied with a
| simple, email only product they can manage without help.
| iammiles wrote:
| I strongly agree with your last paragraph. I used Heroku for my
| wedding website and I would 100% use it again on a project
| site.
|
| In about 15 minutes I was able to take my site from localhost
| to a custom domain with SSL with just a little more than a git
| push. I can't think of many solutions that are simpler than
| that.
| twblalock wrote:
| Even small companies should be multi-region, if they care about
| uptime.
| ceejayoz wrote:
| Very few companies have uptime requirements so critical they
| can justify this. Small companies with limited ops resources
| may struggle to make a multi-region setup work more reliably
| than a single-region one.
| tomnipotent wrote:
| No, they shouldn't. In many instances it's cheaper to
| tolerate downtime than to pay to avoid it, especially when
| there's no SLA involved.
| treeman79 wrote:
| Most of the time. If heroku is having downtime. Then Amazon
| is having downtime. Then half the internet is down. Let
| customers know Amazon is down. Sit back and relax.
| nosvince wrote:
| Wow, that's a horrible way of thinking about the user
| experience. And honestly, I'm not surprised. That's why
| companies that really care about the user experience will
| always steal market share from those that don't.
| neojebfkekeej wrote:
| It's actually small companies that care about user
| experience that will often make these trade-offs. Less
| time managing multi-cloud deployments means more time
| spent building our core product and talking to users.
| [deleted]
| tomnipotent wrote:
| Uptime isn't an axiom. Most software isn't mission
| critical and most users won't notice if it's down for 30
| minutes once or twice a month, and for everything else we
| have SLA's to manage professional expectations.
| hthrowaway5 wrote:
| As someone that was a very active Heroku user for years and
| then worked there for years: I wouldn't trust it as my host.
| There is nowhere near enough people maintaining it in order to
| have confidence it'll run without reliability or security
| issues. They aren't exactly in a position to retain or attract
| talent either.
|
| I thought Cedar was going to fall over years ago but ironically
| I think people migrating _off_ the platform are helping it stay
| alive.
| tomjakubowski wrote:
| > 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/
|
| 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 wrote:
| > 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.
| anamexis wrote:
| Yes, there are hundreds of different ways you could
| accomplish this. Fly.io is a convenient and easy to use
| one.
| [deleted]
| manmal wrote:
| You don't need to route every write to primary though, but
| only those writes that have dependencies on other writes.
| Things like telemetry can be written in edge instances.
| Depends on your application of course, but in many cases
| that should be only a tiny fraction of all requests needing
| redirects to primary.
|
| And why would you get 20 instances, all around the world
| right out of the gate? 6-7 probably do the job quite well,
| but maybe you don't even need that many. Depending on where
| most of your customers are, you could get good results with
| 3-4 for most users.
| nickjj wrote:
| > You don't need to route every write to primary though,
| but only those writes that have dependencies on other
| writes.
|
| Thanks, can you give an example of how that works? Did
| you write your own fork of Postgres or are you using a
| third party solution like BDR?
|
| Also do you have a few use cases where you'd want writes
| being dependent on another write?
|
| > 6-7 probably do the job quite well
|
| You could, let's call it 5.
|
| For a 2gb set up would that be about $50 for the web app,
| $50 for the background workers, $160ish for postgres and
| then $50 for Redis? We're still at $300+?
|
| I was thinking maybe 5 background workers wasn't
| necessary but frameworks like Rails will put a bunch of
| things through a background worker where you would want
| low latency even if they're happening in the background
| because it's not only things like sending an email where
| it doesn't matter if it's delayed for 2 seconds behind
| the scenes. It's performing various Hotwire Turbo actions
| which render templates and modify records where you'd
| want to see those things reflected in the web UI as soon
| as possible.
| nicoburns wrote:
| For low-latency workers like that it might make sense to
| just run them on the same instance as the web servers.
| nehalem wrote:
| 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.
| ignoramous wrote:
| 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 wrote:
| > [...] 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?
| ushakov wrote:
| 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
| anurag wrote:
| Render has native automatic backups for PostgreSQL:
| https://render.com/docs/databases#backups
|
| Review apps on Render are called Preview Environments:
| https://render.com/docs/preview-environments
| dubswithus wrote:
| --delete
| detaro wrote:
| As the article mentions, it doesn't force you to use docker.
___________________________________________________________________
(page generated 2022-05-15 23:00 UTC)