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?
I just don't understand all the fetishism for go. At its core, its a brutally pragmatist language optimized for engineers who barely understand closures while running reasonably fast.
need a garbage collected native compiled language?/
- ocaml fits the bill and provides better type checking
need a fast as possible system?
- rust is faster and has much better abstraction for type checking. unless you're writing a throwaway or a very short lambda function, rust is almost always a better choice here as handling errors and maintaining the code is going to be more important overtime and go is just now getting its generics story straight
need a networking application?
- elixir (and erlang) do this so much better. it has 30+ years of high reliability networking built in and its about as fast as go. additionally, fault tolerance and error handling is so much better. I have real parallelism out of the box and async primitives that make goroutines look like a joke.
additionally, all 3 (ocaml, rust and elixir) give you proper tools for handling error branches. go downgrades you back to c style which works but means your code is going to evolve into a god damn mess as there's no way to separate your error path from your happy path
Literally the only place I see go making sense are small scripts that need to be written asap and wont' need much long term maintenance. for everything else, go seems woefully inadequate.
I worked at one of the beneficiaries of that exodus with some ex-Heroku Erlang folk. Can't speak to if Dogwood was a fools errand or not but dumping Erlang in favor of Go considering the quality of Erlang talent they had on staff was definitely a colossal fuckup.
Have seen similar transitions in different companies, and while I can't say anything about Heroku, it is often not the target technology or architecture that matters.
For instance I've seen PHP -> nodejs transition while moving to micrservices, and while the ideas made sense on paper:
- It didn't come from the engineers at large. Most weren't phased by the prospect and the main engine for the change was the top architects and the engineering management.
- target architecture and language were very popular, and easy to hire. Incidentally salaries would be cheaper for same level of experience engineers.
Predictidbly a ton of the existing engineers left and new blood came in, and it was mostly according to plan from what I gathered. Some of the "old folks" stayed at a premium once they were the only ones left with enough knowledge, but they got relagated in side "experts" roles and the product as a whole saw a big change in philosophy (I think mentally what was seen as the "core" also became "legacy" in everyone's mind as engineers moved away)
Lets re-write it they said. It will be easier to maintain they said. It will be more use friendly they said. We're Netscape and there's nothing like us they said.
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.
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.
> 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.
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 :-)
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.
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.
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.
> 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.
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.
> 2. File persistence is fine but not typically necessary. S3 works just fine.
I'm so glad you pointed this out. Cloud-native development is an important factor in newly architected systems. Defaulting to an S3 API for persistent I/O brings loads of benefits over using traditional file I/O, and brings significant new design considerations. Until a majority of software developers learn exactly how and why to use these new designs, we'll be stuck with outmoded platforms catering to old designs.
> 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.
I have used multi-region for every production database I've deployed in the last ~8 years, and it took < 10 seconds of extra time. It's a core feature of services like RDS on AWS.
There is a benefit if you're multi-region (but not global) because individual regions go down all the time.
It costs more every month, but if you have a B2B business, it's worth the extra cost.
> I wouldn't straight out recommend fly.io. See, part of Heroku's value proposition was their excellent support. I had asked fly.io to delete my account since there wasn't a provision to delete it from their interface and they never bothered to reply and put me in some kind of shadow ban from re-registering with my email.
I mean if this is how you're going to treat your customers, then good luck! I'm yet to try out railway.app and..looks interesting to say the least.
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.
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).
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.
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.
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.
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.
Last week I couldn't get Fly.io to spin up a simple Postgres database for my app. I've now been on Render for a week with multiple production apps, and so far it has been working fine.
Fly has a nice DX but unfortunately the platform still has major issues with reliability and networking. There are often problems with deploys leading to stuck and unreachable instances or other networking issues. It's probably exacerbated by the new user growth but the slick deploy workflow can't override having an app that works.
Render and others are interesting but K8S is still fundamentally better considering all the DX progress there making it pretty easy to get a container running in a cluster.
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).
> 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.
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.
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.
Fly.io is a reclaimer. Also see: Vercel, Digital Ocean, Dokku, Netlify, Firebase, Engine Yard, OpenShift, Appfleet, Github Pages, Render, AWS Amplify.
Heroku made it easier to deploy, but now it feels a tad bit bit more frictional than other services, including fly.io and these mentioned above. It is probably a bit outdated in that regard.
We use a tool called squash.io. It's geared more for instant QA environment than production workloads, but it has the advantage of being super simple. It just listens for feature branch commits and grabs the docker-compose file and runs it. Funny enough, before we signed up we also considered Heroku since we had a relationship with Salesforce and I was familiar with their product. After an intro call, they never followed up. Guess that was a sign.
The only things I can see missing are automated Redis hosting by the platform.
There have been so many times I wanted some simple key value store which I do not have to bother about setting up and taking care of. Something like "ambient Redis". It's OK not to have crazy scaling promises. You just enable an API (maybe for a small fee) and just use it.
If and when you get big enough you switch to a setup you bother about setting up and taking care of.
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!
This is pretty much what I believe. This isn't HN frontpage worthy, but one of the things I'm most excited about is people running production CockroachDB clusters on Fly.io. It is still a little more difficult to use the underlying infrastructure than it should be, but we're getting close.
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.
The one thing I'm really missing after looking at a number of hosts (Fly and Render being top of list otherwise) is a free database tier.
For a toy app, 10k db rows (across all tables) from Heroku was enough to get the app running and have a public URL to share, and I miss those days.
I'm working on a fresh Rails7 toy app to try out some new features, and my current thinking is to use sqlite, and add an initializer early in the stack to migrate+seed the db if it's missing. If it's ephemeral that's fine, I just want some baseline data to interact with the app at a distance beyond localhost.
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.
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?
[+] [-] hthrowaway5|3 years ago|reply
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?
[+] [-] cultofmetatron|3 years ago|reply
need a garbage collected native compiled language?/
- ocaml fits the bill and provides better type checking
need a fast as possible system?
- rust is faster and has much better abstraction for type checking. unless you're writing a throwaway or a very short lambda function, rust is almost always a better choice here as handling errors and maintaining the code is going to be more important overtime and go is just now getting its generics story straight
need a networking application?
- elixir (and erlang) do this so much better. it has 30+ years of high reliability networking built in and its about as fast as go. additionally, fault tolerance and error handling is so much better. I have real parallelism out of the box and async primitives that make goroutines look like a joke.
additionally, all 3 (ocaml, rust and elixir) give you proper tools for handling error branches. go downgrades you back to c style which works but means your code is going to evolve into a god damn mess as there's no way to separate your error path from your happy path
Literally the only place I see go making sense are small scripts that need to be written asap and wont' need much long term maintenance. for everything else, go seems woefully inadequate.
[+] [-] jpgvm|3 years ago|reply
[+] [-] makeitdouble|3 years ago|reply
For instance I've seen PHP -> nodejs transition while moving to micrservices, and while the ideas made sense on paper:
- It didn't come from the engineers at large. Most weren't phased by the prospect and the main engine for the change was the top architects and the engineering management.
- target architecture and language were very popular, and easy to hire. Incidentally salaries would be cheaper for same level of experience engineers.
Predictidbly a ton of the existing engineers left and new blood came in, and it was mostly according to plan from what I gathered. Some of the "old folks" stayed at a premium once they were the only ones left with enough knowledge, but they got relagated in side "experts" roles and the product as a whole saw a big change in philosophy (I think mentally what was seen as the "core" also became "legacy" in everyone's mind as engineers moved away)
[+] [-] john_the_writer|3 years ago|reply
[+] [-] amerine|3 years ago|reply
[+] [-] ditsuke|3 years ago|reply
[+] [-] brundolf|3 years ago|reply
[+] [-] anon3949494|3 years ago|reply
1. Multi-region deployment only work if your database is globally distributed too. However, making your database globally distributed creates a set of new problems, most of which take time away from your core business.
2. File persistence is fine but not typically necessary. S3 works just fine.
It's easy to forget that most companies are a handful of people or just solo devs. At the same time, most money comes from the enterprise, so products that reach sufficient traction tend to shift their focus to serving the needs of these larger clients.
I'm really glad Heroku froze when it did. Markets always demand growth at all costs, and I find it incredibly refreshing that Heroku ended up staying in its lane. IMO it was and remains the best PaaS for indie devs and small teams.
[+] [-] tomjakubowski|3 years ago|reply
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 :-)
[+] [-] closeparen|3 years ago|reply
[+] [-] hthrowaway5|3 years ago|reply
I thought Cedar was going to fall over years ago but ironically I think people migrating off the platform are helping it stay alive.
[+] [-] sanjayio|3 years ago|reply
[+] [-] donmcronald|3 years ago|reply
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|3 years ago|reply
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.
[+] [-] throwaway892238|3 years ago|reply
I'm so glad you pointed this out. Cloud-native development is an important factor in newly architected systems. Defaulting to an S3 API for persistent I/O brings loads of benefits over using traditional file I/O, and brings significant new design considerations. Until a majority of software developers learn exactly how and why to use these new designs, we'll be stuck with outmoded platforms catering to old designs.
[+] [-] smt88|3 years ago|reply
I have used multi-region for every production database I've deployed in the last ~8 years, and it took < 10 seconds of extra time. It's a core feature of services like RDS on AWS.
There is a benefit if you're multi-region (but not global) because individual regions go down all the time.
It costs more every month, but if you have a B2B business, it's worth the extra cost.
[+] [-] amerine|3 years ago|reply
[+] [-] twblalock|3 years ago|reply
[+] [-] neya|3 years ago|reply
[+] [-] sergiomattei|3 years ago|reply
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.
[+] [-] mrkurt|3 years ago|reply
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).
[+] [-] jhardy54|3 years ago|reply
[+] [-] 2c2c2c|3 years ago|reply
Is there any in depth comparison between them and render.com ?
[+] [-] sergiotapia|3 years ago|reply
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|3 years ago|reply
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.
[+] [-] nehalem|3 years ago|reply
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|3 years ago|reply
[+] [-] anurag|3 years ago|reply
Review apps on Render are called Preview Environments: https://render.com/docs/preview-environments
[+] [-] heartbreak|3 years ago|reply
[+] [-] ushakov|3 years ago|reply
Render is more user-friendly and great for teams, but Fly.io is more flexible and has more advanced features
[+] [-] manigandham|3 years ago|reply
Render and others are interesting but K8S is still fundamentally better considering all the DX progress there making it pretty easy to get a container running in a cluster.
[+] [-] nik736|3 years ago|reply
[+] [-] onphonenow|3 years ago|reply
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).
[+] [-] the__alchemist|3 years ago|reply
Sounds like mission accomplished; the elusive 1.0.
[+] [-] taylorlapeyre|3 years ago|reply
Until another service has all of this, we’re sticking with Heroku.
[+] [-] mrkurt|3 years ago|reply
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.
[+] [-] quickthrower2|3 years ago|reply
Heroku made it easier to deploy, but now it feels a tad bit bit more frictional than other services, including fly.io and these mentioned above. It is probably a bit outdated in that regard.
[+] [-] tootie|3 years ago|reply
[+] [-] chanux|3 years ago|reply
If and when you get big enough you switch to a setup you bother about setting up and taking care of.
Am I making sense to anyone?
[+] [-] daxfohl|3 years ago|reply
I think if fly succeeds, they need to figure out edge IaaS, and not put all their eggs into edge PaaS. And I hope they do! I'm curious what a successful edge IaaS looks like!
[+] [-] mrkurt|3 years ago|reply
[+] [-] chasd00|3 years ago|reply
[+] [-] ushakov|3 years ago|reply
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
[+] [-] mardix|3 years ago|reply
[+] [-] jamie_ca|3 years ago|reply
For a toy app, 10k db rows (across all tables) from Heroku was enough to get the app running and have a public URL to share, and I miss those days.
I'm working on a fresh Rails7 toy app to try out some new features, and my current thinking is to use sqlite, and add an initializer early in the stack to migrate+seed the db if it's missing. If it's ephemeral that's fine, I just want some baseline data to interact with the app at a distance beyond localhost.
[+] [-] arkadiyt|3 years ago|reply
[+] [-] jshen|3 years ago|reply
[+] [-] st3fan|3 years ago|reply
[+] [-] tptacek|3 years ago|reply