13 ms·

Fundamentally I think some of the problems come down to the difference between what Fly set out to build and what the market currently want. Fly (to my underst

Fundamentally I think some of the problems come down to the difference between what Fly set out to build and what the market currently want. Fly (to my understanding) at its core is about edge compute. That is where they started and what the team are most excited about developing. It's a brilliant idea, they have the skills and expertise. They are going to be successful at it. However, at the same time the market is looking for a successor to Heroku. A zero dev ops PAAS with instant deployment, dirt simple managed Postgres, generous free level of service, lower cost as you scale, and a few regions around the world. That isn't what Fly set out to do... exactly, but is sort of the market they find themselves in when Heroku then basically told its low value customers to go away. It's that slight miss alignment of strategy and market fit that results in maybe decisions being made that benefit the original vision, but not necessarily the immediate influx of customers. I don't envy the stress the Fly team are under, but what an exciting set of problems they are trying to solve, I do envy that!

vineyardmike 4y ago
I agree - fly is so easy to use (when it works) that it’s hard not to be impressed. BUT what I’ve found is that we don’t need edge compute, since our customers aren’t that latency sensitive, so it’s lost on us. It’s only a few more milliseconds to us-east-1. I’ve heard (on HN) of a dozen different companies vying for the heroku replacement spots and yet Fly seemed to capture the attention. I couldn’t name another one off hand. What I truly want and probably lots of other people too is Flyctl (and workflow) for AWS. The same simplicity to run as fly, but give me something cheap in Virginia or the Dalles.
- latchkey 4y ago
  > What I truly want and probably lots of other people too is Flyctl for AWS. The same simplicity to run as fly, but give me something cheap in Virginia or the Dalles. Google Cloud. It is painfully easy to spin up managed postgres, super easy to deploy gcp cloud functions or gcp cloud run. It isn't expensive either and just works.
  - 0cf8612b2e1e 4y ago
    If someone is not already using the holy trinity (AWS/Azure/GCP) there is probably a reason.
    - monsieurbanana 4y ago
      I'm not using gcp anymore because it's not worth risk losing access to my personal gmail account just to play around with pet projects. I might be paranoid, but I just don't feel comfortable when there's so much in play.
      - guhcampos 4y ago
        Create a new Gmail account?
        vineyardmike 4y ago
        Google associates different accounts that are from the same owner when handling issues FYI. So if they think your account is doing something wrong on GCP, be wary of associated accounts.
        latchkey 4y ago
        Never once heard of that.
        miyuru 4y ago
        https://news.ycombinator.com/item?id=17115643 https://news.ycombinator.com/item?id=17115643
        latchkey 4y ago
        Did you read the comments? My takeaway is that it was bs.
- cldellow 4y ago
  Render.com is another spiritual successor of Heroku. I'd love a world where Fly and Render are both very successful companies.
  - te_chris 4y ago
    Not gonna happen. Both will get acquired because that’s how things work now
    - jamil7 4y ago
      Not sure why this is downvoted, it’s a valid point.
    - jstummbillig 4y ago
      Unless a company is very explicit about this not being in the books, I tend to share this outlook. From the perspective of a recent founder, it's downright spooky to build around any SaaS, considering how few of them have been around for 10+ years, when that is certainly what our business is aiming for. I know (and share the feels): Devs tend to get excited about the new thing – but if Google Workspace shut down next month, we would be in so much operational trouble. When other peoples fancies stand in the way of the entire operation you are responsible for, it actually begs the question how much closed source SaaS you can allow before it starts to be quite frankly irresponsible. We are not imagining things. SaaS of all sizes shut down all the time, and when you are heavily relying on them and building software around them to run a business the prospect is spooky as hell.
      - zamnos 4y ago
        The difference between (free) Gmail and Google workspace is that workspace is a paid product. If you're big enough to warrant an AM, you can get terms which include continuity of business planning if Google does happen to shut down Workspace. (They won't.)
        manmal 4y ago
- manmal 4y ago
  I can second that I‘ve seen render.com mentioned very often, maybe even more so than fly.
- gen220 4y ago
  > What I truly want and probably lots of other people too is Flyctl for AWS. The same simplicity to run as fly, but give me something cheap in Virginia or the Dallas. Pardon the ignorance, is this not the Amplify CLI [1] ? [1]: https://docs.amplify.aws/cli/ https://docs.amplify.aws/cli/
  - pid-1 4y ago
    No
    - scubbo 4y ago
      Can you elaborate?
      - ctvo 4y ago
        Things that just work and are delight to use and the AWS Amplify CLI are not often mentioned together. The Amplify CLI is a growing collection of poorly thought out, poorly implemented functionality that looks good in demos, but falls apart under any close inspection.
      - Aeolun 4y ago
        I can only assume that if you’ve ever used the amplify cli it makes total sense. At least that single ‘no’ contained a whole wealth of blood and tears to me.
      - nl 4y ago
        (No the OP) I like Amplify and use it often. However, it isn't well integrated with "normal" backends, so if you want to keep a backend and frontend deployed together you either have to use their Amplify backend API or work out your own deployment.
- trunnell 4y ago
  > Flyctl for AWS Have you tried AWS Copilot? I’m having good success with it. Probably not quite as simple as flyctl, but still it’s only one command to deploy a container. I would really like fly.io to overcome these hurdles. I bet they will.
- zoomzoom 4y ago
  I think this whole category is interesting, from the next-gen PaaS to the cloud-native ecosystem. Totally empathize with how hard what fly is doing in terms of scale and reliability is. At Coherence (withcoherence.com) we're focused on a developer experience layer on top of AWS/GCP. You might describe it as flyctl for AWS.
trilobyte 4y ago
> generous free level of service, This is likely the biggest culprit for a lot of these companies. Too many of us have grown up in the culture of getting hosting and platform for "free", but at some point the companies providing it still have to pay the bills. There has to be a better pricing model that let's someone deploy their relatively small, low-traffic app for $10s/month or even $200 - $300 / year for the basics (e.g. - Heroku free tier type capabilities). It's not going to save these companies but it would limit excessive growth of their own costs from a free tier while at the same time still being affordable for 1 - 2 person teams who are trying to get something in front of users.
- karmelapple 4y ago
  I agree. And I know this is unpopular, but I think none of these companies should be expected to have a free tier. A low-cost tier? Certainly. Perhaps even a free trial with a credit card? Great. But our team, who has used Heroku for over a decade, got bit multiple times by Heroku having a free tier. Why were we impacted by other apps? Because Heroku’s load balancers are shared amongst all their apps. That includes all the sketchy apps running on the platform. If Heroku could somehow isolate us from everyone else? Great - and they offered that for awhile with a reasonably-priced Add-On supported by them called SSL Endpoint. It cost about $15/month and put us into a pool that was shared with other folks willing to spend that much per month to run their app. I understand that’s not great for a hobby project. But for those of us trying to run a large product on Heroku and not have to spend multiple extra thousands of dollars every month for a Heroku Private Space, this was a great way of pooling: put a small fee in place for one pool of resources. Not many malware writers or other misbehaving app creators will probably want to spend that much per month. But they axed that a few years ago. Only a couple months after when we were thrown back into the load balancer pool with all the other free apps, one of the IPs was marked as spam and we had to figure out a kind of janky solution. Additionally, Heroku seemingly spent a ton of resources on free tier support, malware fighting, etc. I hope to see more features on Heroku since they’ve dropped that support… but I haven’t seen much evidence of that in roughly six months since they did that. But we’ll see.
  - trilobyte 4y ago
mattbillenstein 4y ago
Yeah, distributed systems at the global scale are very very difficult - at least with the Heroku style problem, you'd be looking at scaling in a single datacenter I think - deployments to multiple datacenters wouldn't share dependencies. I do wonder however if they'd be better off using less l33t tech - do almost everything on Postgres vs consul and vault, etc. Scaling, failover, consistency, etc is a more well-known problem and there are a lot of people who've ran other DBs at tremendous scale than the alternatives. Simplicity is the key to reliability, but this isn't a simple product, so idk.
- lmm 4y ago
  > I do wonder however if they'd be better off using less l33t tech - do almost everything on Postgres vs consul and vault, etc. Scaling, failover, consistency, etc is a more well-known problem and there are a lot of people who've ran other DBs at tremendous scale than the alternatives. In my experience people who ran Postgres distributed across a WAN tended to use obscure third-party plugins at best, more often a pile of dodgy Perl scripts. Using something designed from the ground up to be clustered seems to have a much better chance of working out than trying to make something that's been built as a single-instance system for decades work across the internet.
  - mattbillenstein 4y ago
    Yeah, point taken, I wasn't thinking to cluster across the WAN - more like an api wrapping postgres in a single DC. But you pay the price of read latency I guess... it's a hard problem no doubt.
- zamnos 4y ago
  Backend simplicity also means a more shallow moat. It makes it easier for Digital Ocean/Linode (Akamai)/Hetzner to offer a competing service with the same backend knobs to turn, should they decide they want to get into that market. The goal should be to make the backend as simple as possible, but no simplier. Complexity here leads to operational burden and toil. But that's why you hire good SREs and treat them well. What's more important is frontend complexity, aka how difficult it is for customers to use. Backend and frontend complexity aren't necessarily linked, which, imo, fly.io achieves, downtime aside.
ec109685 4y ago
The CloudFlare folks wrote a good blog post on how they are seeing their customers use Edge compute — latency is far down on the list: https://blog.cloudflare.com/cloudflare-workers-serverless-week/ https://blog.cloudflare.com/cloudflare-workers-serverless-we...
- everybodyknows 4y ago
  Hmm, that post is almost three years old -- still accurate?
  - prdonahue 4y ago
    Yes, especially as compliance and regulatory frameworks continue to evolve and become more difficult to adhere to as mentioned elsewhere in the comments. We're inherently faster than other "serverless" platforms due to the scale and homogeneous design of our network, and that network has presence in nearly 50% more cities than it did just 3 years ago. We were plenty fast enough then and we're even faster now. Other things that customers (still) really care about: developer experience, ease of use, and cost. Nobody likes paying the AWS tax to move data around—they just want to use the best solution from the best cloud provider. Workers and the associated storage primitives allow them to pick and choose from the best that AWS, Azure, Cloudflare, GCP, et al. have to offer. (Disclaimer: I'm a long time Cloudflare employee focused on App Sec, and I speak to customers regularly who look to Workers largely for compliance reasons, but I don't work on the Developer Platform business. Am sure my Dev Platform peers will chime in with more nuanced answers!)
- fmajid 4y ago
  The US CLOUD Act means a EU customer cannot use a US cloud provider to host PII, even if the server itself is physically in the EU, because US law will still compel the provider to yield the data to US authorities. The European Commission is trying to paper over the cracks with a fig leaf of judicial review, but it's only a matter of time until a Schrems III decision from the CJEU invalidates that polite fiction.
  - 4y ago
vendiddy 4y ago
I can second this. We were evaluating moving off Heroku and to Fly.io, but we didn't need all of the edge compute stuff. We just want a better Heroku without having to think about infrastructure and having to think about edge compute just got in our way. I feel like Next.js is in a similar position. While their main vision is SSR, I wonder if they are missing out on a chunk of the market that simply doesn't want to think about infra. We use them because we just don't have to worry about webpack or fiddling with deployment and hosting. We could care less about SSR and in fact we disabled it app-wide.
- alexgrover 4y ago
  Why would they be missing out? Vercel can host static sites just fine, whether that’s one generated by Next or any other framework or written by hand
  - vendiddy 4y ago
    To clarify, I'm referring to folks who just need to write single page apps, but don't benefit from SSR. (I didn't find disabling SSR straightforward.) I wonder if Vercel is underestimating the size of the market that just wants a "Heroku for React".
- leerob 4y ago
  One of the key design choices of Next.js was to enable granularity on the runtime (Node.js or Edge[1]) and the rendering method (static or dynamic[2]) on a per-route basis. If you want a full SSR site, that's okay. If you want a full static site, that's also okay. We often see folks wanting a mix of both. For example, maybe the /about page is static, but the home page is dynamic and personalized based on the visitor. You can do all of this with Next.js. Our future direction is adding even further granularity, enabling this decision at the data fetch level, allowing you to cache results across deployments[3]. [1]: https://beta.nextjs.org/docs/rendering/edge-and-nodejs-runtimes https://beta.nextjs.org/docs/rendering/edge-and-nodejs-runti... [2]: https://beta.nextjs.org/docs/rendering/static-and-dynamic-rendering https://beta.nextjs.org/docs/rendering/static-and-dynamic-re... [3]: https://vercel.com/blog/vercel-cache-api-nextjs-cache https://vercel.com/blog/vercel-cache-api-nextjs-cache
bostik 4y ago
There's a wonderfully blunt saying that applies here (too): you are not in the business you think you are, you are in the business your customers think you are. If you offer data volumes, the low water mark is how EBS behaves. If you offer a really simple way to spin up Postgres databases, you are implicitly promising a fully managed experience. And $deity forbid, if you want global CRUD with read-your-own-writes semantics, the yardstick people measure you against is Google's Spanner.
- quickthrower2 4y ago
  In a nutshell if you offer cloud services you need to be better than the MAG clan, Digital Ocean too. And people will want it dirt cheap. It’s still hard to be a profitable web host as it always was (MAG has the advantage that none of them were web hosts at first base)
  - blowski 4y ago
    MAG?
    - avidal 4y ago
      From context, I'm assuming Microsoft / Amazon / Google, referring to Azure / AWS / Google Cloud respectively.
      - gvtek0 4y ago
        Yep. Because when I think reliable cloud infra, I think Azure.
    - deleted 4y ago
      [deleted]
    - jerrygenser 4y ago
      microsoft apple google
    - gizmo 4y ago
erebe__ 4y ago
You can take a look at www.qovery.com It provides an Heroku like experience but runs on your cloud account (aws, scaleway or digital ocean). They build on existing tech that is already working, so it is more stable.
- ignoramous 4y ago
  Save for a few "in-preview" features, Fly was stable too but then they started growing faster than they could keep up (a good problem to have!). Stability isn't a permanent state.
richardhod 4y ago
What are the limitations to heroku that people are going to Fly for? Maybe there's a standard article that would be useful to read about it?
- zamnos 4y ago
  It's more about Heroku dropping free and low-cost plans, which is them demonstrating that they don't currently care about three low end of the market, more than any specfic feature.
  - doodlesdev 4y ago
    Also the absolute disaster with security they had just before dropping free tiers, and the awful response which took months to even acknowledge some kinds of data (such as pipeline keys) where affected. [0] [0]: https://github.blog/2022-04-15-security-alert-stolen-oauth-user-tokens/ https://github.blog/2022-04-15-security-alert-stolen-oauth-u...
- mcintyre1994 4y ago
  This is an old doc from fly so I’m not sure how much of it is still accurate, but it talks about some of the stuff Heroku didn’t have that they have: https://fly.io/docs/app-guides/speed-up-a-heroku-app/ https://fly.io/docs/app-guides/speed-up-a-heroku-app/ > There's no support for a single dedicated IP address for your application. With Heroku, your application's CPU resources are mostly located in one datacenter. Heroku doesn't support HTTP2 or Brotli compression and it doesn't do Edge TLS termination. And it doesn't run your applications on dedicated MicroVMs. These are all things that Fly's Global Application Platform does. The other comment that mentions Heroku dropping low cost plans is the reason for the explosion in growth as I understand it though.
- simonw 4y ago
  People don't trust it any more, because Salesforce have been under-investing in it for years and recently rug-pulled on everyone who had ever used the free tier (after providing that free tier for 15 years already - long enough for people to reasonably expect it to continue).
VWWHFSfQ 4y ago
> dirt simple managed Postgres Heroku PostgreSQL is very simple, yes. But once you need non-trivial scale it's expensive and extremely non-performant. Even a medium-sized RDS will outperform Heroku's most expensive database offering by 20x in my experience. My company doesn't even run PG on Heroku anymore. We have a VPC/Private Space connection to AWS Aurora because the cost/performance difference is so extreme.
- snacktaster 4y ago
  I don't know the details of how Heroku implements their hosted postgres service, but I'm _guessing_ that it's just a bunch of PG servers running on EC2 instances. There's probably a lot of CPU stealing "noisy neighbors" going on. But yeah, I've also experienced Heroku's PG databases being dog-slow compared to RDS for the same workloads.
  - mixmastamyk 4y ago
    They're probably using older or cheaper instance types. By not upgrading while charging the same or more over time, one can skim more profit.
- karmelapple 4y ago
  I have run the experiment, and Crunchy Data’s Postgres servers are 4X more bang for the buck than Heroku’s. I let some folks at Heroku know this who are product managers, and they are investigating it… but I would be shocked if Heroku gets a big performance improvement anytime in, say, 2023. 20X seems like a lot for RDS, though I’d be curious to learn more! We are switching to Crunchy because of that clear cost/performance difference you mention.
  - jrochkind1 4y ago
    I would be kind of shocked if heroku gets a big performance improvement ever again. It seems the owners have decided to basically freeze it.
leishman 4y ago
This is spot on. I found myself using Fly for a project because it was super easy, not because I needed edge compute. TBH it's still actually unclear to me who needs edge compute? What apps require this sort of infra? It's not 99% of web apps right?
- davnicwil 4y ago
  Personally I see this as a 'why not, if it works' type thing. Sure you don't need it for 99% of usecases, but if it just works using familiar architectures then it is also strictly better for 99% of usecases so you might as well, and people will naturally want it. That 'familiar architectures' part is the hard bit, though.
  - kevincox 4y ago
    But it isn't better in 99% of use cases. Lots of use cases are rendering an API response or HTML page that involves multiple database requests. Therefore the distance between database and app server is more important than the distance between the client and the app server. Edge compute can be helpful for static or quite cachable content. But often this is handled as well or nearly as well by a caching CDN. So that leaves a few cases where edge compute is useful. Where you are globally distributing the data itself (and ideally moving the data around as your users travel or move) which is incredibly rare and expensive to build, and when you need pure computation that needs no request to your backend and if 50ms of latency is important for a pure computation most of the time you can just move it to the client. In my experience these tend to be rare. I would estimate that edge compute is actually helpful for 1-5% of projects, not 99%.
- hinkley 4y ago
  I still think that in the next pendulum swing we'll end up with edge computing and (smaller) self-hosted backends. Everything old is new again, and we haven't entirely recreated Akamai from first principles yet.
- vineyardmike 4y ago
  One of the big benefits of edge compute is that it’s geographically distributed. Doesn’t make a big impact across the US, but globally a lot of nations have specific data laws, so it’s important to host data in the required nation. Keep customer data in its nation of origin, but have a single control plane and platform for ever data center.
satvikpendem 4y ago
I'm going to plug Coolify, an open source Heroku alternative (with Docker support too) that I'm using on a cheap $5 Hetzner server which is a lot cheaper than the equivalent Fly or Render etc service, and it really doesn't have much upkeep from me even if you add in the time setting up the server initially, which is like an hour, and afterwards, it Just Works™. https://coolify.io https://coolify.io
- notpushkin 4y ago
  Dokku is also nice and battle-tested: https://dokku.com/ https://dokku.com/ And may I also plug Lunni, a self-hosted Docker Swarm-based PaaS I'm working on right now: https://lunni.dev/ https://lunni.dev/ Both work pretty well on $5 servers.
  - satvikpendem 4y ago
    Lunni looks really interesting! Looks like a Coolify competitor, I'll definitely check it out. Do you have a Discord to join? Coolify has one and I found it great to discuss the project and talk directly to the creator. I used to use Dokku but I personally liked the GUI from Coolify so I've been using that. Nice to see that you have a GUI as well, makes configuring apps a lot easier.
    - notpushkin 4y ago
      That's a nice idea actually, thank you! Just launched one: https://discord.gg/9EAne8g2Pq https://discord.gg/9EAne8g2Pq (Bridged to Matrix: https://matrix.to/#/#lunni:matrix.org https://matrix.to/#/#lunni:matrix.org) Lunni is actually pretty young in terms of community (just me and a few friends now :-), so just a room in Telegram was sufficient so far, but I think it's a good time to start something more official.
      - satvikpendem 4y ago
        Thanks, just joined. One thing I noticed is that the CI/CD setup for GitHub/lab is still based on the CI files themselves. What I like about Coolify and didn't like about others is that I could simply install a GitHub app to my account and Coolify would automatically pull my repositories and even set up git push to deploy for me, no messing around with CI files needed. https://lunni.dev/docs/deploy/from-git/#github https://lunni.dev/docs/deploy/from-git/#github vs https://docs.coollabs.io/coolify/sources https://docs.coollabs.io/coolify/sources
ghiculescu 4y ago
I coincidentally tweeted the exact same thing earlier today. I selfishly hope Fly put all their focus toward becoming Heroku 2.0. I’m sure some people care about all the edge latency stuff but I don’t know many of them.
- machiaweliczny 4y ago
  Yeah, I guess devs first will need to learn better SQL before it will start to matter.
- deleted 4y ago
  [deleted]
hiAndrewQuinn 4y ago
God, I'm glad someone else sees it as clearly as I do. I learned about Fly from them acquiring freaking Litestream! The SQLite replicator! The canonical database at the edge of the network! Of course that's what they want to do.
decidertm 4y ago
I'm a co-founder at Northflank. This is what we've spent 3+ years building. https://northflank.com https://northflank.com. I am sympathetic with much of Kurt's post. We spent a long time building solutions to several of the areas highlighted (managed PG, persistent volumes, secret management and service discovery). Making radical changes to architecture on a live cloud platform is always a challenge. On the front-end Northflank is a next-gen PaaS built for high DX, speed, and powerful capability (real-time UI, API, CLI, GitOps, IaC). Our backend is built using Kubernetes as an OS: providing a huge amount of flexibility on service discovery, load-balancing, persistence/volumes and scale. The benefit of using Kubernetes is a universal API across all major cloud providers. We can scale clusters and regions across EKS, GKE and AKS in seconds, either in our managed PaaS or inside our customer's own cloud account. Our managed dataservices: MySQL, Postgres, Redis, Mongo, Minio are all built using Kubernetes Operators with a small but mighty team. From a generous free tier to autoscaling to managed postgres and other advanced PaaS/DevOps automation workflows Northflank offers something unique.
mrkurt 4y ago
This is, indeed, the exciting part. As Heroku fans, we never really felt like it needed a replacement. And if it did, it seemed like Render was the natural Heroku v.next. One thing we've noticed, though, is that people do actually want Heroku but close to users. It's not exactly edge compute. In some cases, it's "Heroku in Tokyo". In others it's "Heroku, but running in all the english speaking regions". I think the thing that ate up most of our energy is also the thing that might actually make this business work. We built on top of our own hardware. That's the thing that made it difficult to build managed Postgres. We put way more energy into the underlying infrastructure than most nü-Heroku companies. The cost was extreme, but I'm like 63% sure this was the right choice.
- KRAKRISMOTT 4y ago
  Just partner with Neon or other similar companies in this space. Scale-to-zero distributed databases is well understood technology. https://neon.tech/ https://neon.tech/
  - nikita 4y ago
    Yes, we are partnering with many companies like Hasura and Replit to help with managed Postgres. Since Neon scales to 0 and also autoscales to your workload it very economical for the long tail of low usage customers.
  - pier25 4y ago
    Does Neon support triggers and subscriptions?
    - nikita 4y ago
      yes to triggers - it's full postgres. logical replication is not exposed just yet, but soon
      - pier25 4y ago
        will subscription work with scale to zero?
sirsinsalot 4y ago
Digital Ocean gave me the PaaS replacement and managed PG and I couldn't be happier. If anyone else is looking.
- chillfox 4y ago
  I tried running a docker app on Digital Ocean's app platform, the UI is nice and I can see it being acceptable for your average CRUD app. But I had to abandon it due to the latency just being too high and their built in monitoring interval not being configurable to the ~5-20ms range (this was for competitive Battlesnake last year).
say_it_as_it_is 4y ago
Edge of what exactly? The software resides within networks they control. There is no edge in this scenario.
MuffinFlavored 4y ago
> generous free level of service, Can't you make the argument that Heroku got out of this market on purpose? I know they were bought out by "ye old corporate greedy meanie overlord" or whatever but... I'm sure there is data that showed it made sense from a "make money business" perspective to not be in that market.
- natbobc 4y ago
  I would even go so far as to say free users aren’t customers in a platform like this. There’s no revenue model and if it’s “run without constraint” you get some fun scaling problems but those types of issues can sometimes lead to optimizations that keep the system online in the face of many small apps but doesn’t necessarily cover the case of a large resource app.
milani 4y ago
> lower cost as you scale The cost aside, I'm wondering how fly or heroku support their customers when they grow to microservices ecosystems. The problem shifts from deploying easily to deploying reliably meaning one release of a service should not break the other services. Other problems appear too, like service discovery, peer authentication, gateways, test and staging environments where there are downstream dependencies, etc. Are customers supposed to leave when they grow to this level? Or are there solutions for these?
amw-zero 4y ago
Why does there need to be a successor to Heroku?

vineyardmike 4y ago

I agree - fly is so easy to use (when it works) that it’s hard not to be impressed. BUT what I’ve found is that we don’t need edge compute, since our customers aren’t that latency sensitive, so it’s lost on us. It’s only a few more milliseconds to us-east-1. I’ve heard (on HN) of a dozen different companies vying for the heroku replacement spots and yet Fly seemed to capture the attention. I couldn’t name another one off hand. What I truly want and probably lots of other people too is Flyctl (and workflow) for AWS. The same simplicity to run as fly, but give me something cheap in Virginia or the Dalles.

latchkey 4y ago
> What I truly want and probably lots of other people too is Flyctl for AWS. The same simplicity to run as fly, but give me something cheap in Virginia or the Dalles. Google Cloud. It is painfully easy to spin up managed postgres, super easy to deploy gcp cloud functions or gcp cloud run. It isn't expensive either and just works.
- 0cf8612b2e1e 4y ago
  If someone is not already using the holy trinity (AWS/Azure/GCP) there is probably a reason.
  - monsieurbanana 4y ago
    I'm not using gcp anymore because it's not worth risk losing access to my personal gmail account just to play around with pet projects. I might be paranoid, but I just don't feel comfortable when there's so much in play.
    - guhcampos 4y ago
      Create a new Gmail account?
      - vineyardmike 4y ago
        Google associates different accounts that are from the same owner when handling issues FYI. So if they think your account is doing something wrong on GCP, be wary of associated accounts.
        latchkey 4y ago
        Never once heard of that.
        miyuru 4y ago
        https://news.ycombinator.com/item?id=17115643 https://news.ycombinator.com/item?id=17115643
        latchkey 4y ago
        Did you read the comments? My takeaway is that it was bs.
cldellow 4y ago
Render.com is another spiritual successor of Heroku. I'd love a world where Fly and Render are both very successful companies.
- te_chris 4y ago
  Not gonna happen. Both will get acquired because that’s how things work now
  - jamil7 4y ago
    Not sure why this is downvoted, it’s a valid point.
  - jstummbillig 4y ago
    Unless a company is very explicit about this not being in the books, I tend to share this outlook. From the perspective of a recent founder, it's downright spooky to build around any SaaS, considering how few of them have been around for 10+ years, when that is certainly what our business is aiming for. I know (and share the feels): Devs tend to get excited about the new thing – but if Google Workspace shut down next month, we would be in so much operational trouble. When other peoples fancies stand in the way of the entire operation you are responsible for, it actually begs the question how much closed source SaaS you can allow before it starts to be quite frankly irresponsible. We are not imagining things. SaaS of all sizes shut down all the time, and when you are heavily relying on them and building software around them to run a business the prospect is spooky as hell.
    - zamnos 4y ago
      The difference between (free) Gmail and Google workspace is that workspace is a paid product. If you're big enough to warrant an AM, you can get terms which include continuity of business planning if Google does happen to shut down Workspace. (They won't.)
      - manmal 4y ago
manmal 4y ago
I can second that I‘ve seen render.com mentioned very often, maybe even more so than fly.
gen220 4y ago
> What I truly want and probably lots of other people too is Flyctl for AWS. The same simplicity to run as fly, but give me something cheap in Virginia or the Dallas. Pardon the ignorance, is this not the Amplify CLI [1] ? [1]: https://docs.amplify.aws/cli/ https://docs.amplify.aws/cli/
- pid-1 4y ago
  No
  - scubbo 4y ago
    Can you elaborate?
    - ctvo 4y ago
      Things that just work and are delight to use and the AWS Amplify CLI are not often mentioned together. The Amplify CLI is a growing collection of poorly thought out, poorly implemented functionality that looks good in demos, but falls apart under any close inspection.
    - Aeolun 4y ago
      I can only assume that if you’ve ever used the amplify cli it makes total sense. At least that single ‘no’ contained a whole wealth of blood and tears to me.
    - nl 4y ago
      (No the OP) I like Amplify and use it often. However, it isn't well integrated with "normal" backends, so if you want to keep a backend and frontend deployed together you either have to use their Amplify backend API or work out your own deployment.
trunnell 4y ago
> Flyctl for AWS Have you tried AWS Copilot? I’m having good success with it. Probably not quite as simple as flyctl, but still it’s only one command to deploy a container. I would really like fly.io to overcome these hurdles. I bet they will.
zoomzoom 4y ago
I think this whole category is interesting, from the next-gen PaaS to the cloud-native ecosystem. Totally empathize with how hard what fly is doing in terms of scale and reliability is. At Coherence (withcoherence.com) we're focused on a developer experience layer on top of AWS/GCP. You might describe it as flyctl for AWS.

trilobyte 4y ago

> generous free level of service, This is likely the biggest culprit for a lot of these companies. Too many of us have grown up in the culture of getting hosting and platform for "free", but at some point the companies providing it still have to pay the bills. There has to be a better pricing model that let's someone deploy their relatively small, low-traffic app for $10s/month or even $200 - $300 / year for the basics (e.g. - Heroku free tier type capabilities). It's not going to save these companies but it would limit excessive growth of their own costs from a free tier while at the same time still being affordable for 1 - 2 person teams who are trying to get something in front of users.

karmelapple 4y ago
I agree. And I know this is unpopular, but I think none of these companies should be expected to have a free tier. A low-cost tier? Certainly. Perhaps even a free trial with a credit card? Great. But our team, who has used Heroku for over a decade, got bit multiple times by Heroku having a free tier. Why were we impacted by other apps? Because Heroku’s load balancers are shared amongst all their apps. That includes all the sketchy apps running on the platform. If Heroku could somehow isolate us from everyone else? Great - and they offered that for awhile with a reasonably-priced Add-On supported by them called SSL Endpoint. It cost about $15/month and put us into a pool that was shared with other folks willing to spend that much per month to run their app. I understand that’s not great for a hobby project. But for those of us trying to run a large product on Heroku and not have to spend multiple extra thousands of dollars every month for a Heroku Private Space, this was a great way of pooling: put a small fee in place for one pool of resources. Not many malware writers or other misbehaving app creators will probably want to spend that much per month. But they axed that a few years ago. Only a couple months after when we were thrown back into the load balancer pool with all the other free apps, one of the IPs was marked as spam and we had to figure out a kind of janky solution. Additionally, Heroku seemingly spent a ton of resources on free tier support, malware fighting, etc. I hope to see more features on Heroku since they’ve dropped that support… but I haven’t seen much evidence of that in roughly six months since they did that. But we’ll see.
- trilobyte 4y ago

mattbillenstein 4y ago

Yeah, distributed systems at the global scale are very very difficult - at least with the Heroku style problem, you'd be looking at scaling in a single datacenter I think - deployments to multiple datacenters wouldn't share dependencies. I do wonder however if they'd be better off using less l33t tech - do almost everything on Postgres vs consul and vault, etc. Scaling, failover, consistency, etc is a more well-known problem and there are a lot of people who've ran other DBs at tremendous scale than the alternatives. Simplicity is the key to reliability, but this isn't a simple product, so idk.

lmm 4y ago
> I do wonder however if they'd be better off using less l33t tech - do almost everything on Postgres vs consul and vault, etc. Scaling, failover, consistency, etc is a more well-known problem and there are a lot of people who've ran other DBs at tremendous scale than the alternatives. In my experience people who ran Postgres distributed across a WAN tended to use obscure third-party plugins at best, more often a pile of dodgy Perl scripts. Using something designed from the ground up to be clustered seems to have a much better chance of working out than trying to make something that's been built as a single-instance system for decades work across the internet.
- mattbillenstein 4y ago
  Yeah, point taken, I wasn't thinking to cluster across the WAN - more like an api wrapping postgres in a single DC. But you pay the price of read latency I guess... it's a hard problem no doubt.
zamnos 4y ago
Backend simplicity also means a more shallow moat. It makes it easier for Digital Ocean/Linode (Akamai)/Hetzner to offer a competing service with the same backend knobs to turn, should they decide they want to get into that market. The goal should be to make the backend as simple as possible, but no simplier. Complexity here leads to operational burden and toil. But that's why you hire good SREs and treat them well. What's more important is frontend complexity, aka how difficult it is for customers to use. Backend and frontend complexity aren't necessarily linked, which, imo, fly.io achieves, downtime aside.

ec109685 4y ago

The CloudFlare folks wrote a good blog post on how they are seeing their customers use Edge compute — latency is far down on the list: https://blog.cloudflare.com/cloudflare-workers-serverless-week/ https://blog.cloudflare.com/cloudflare-workers-serverless-we...

everybodyknows 4y ago
Hmm, that post is almost three years old -- still accurate?
- prdonahue 4y ago
  Yes, especially as compliance and regulatory frameworks continue to evolve and become more difficult to adhere to as mentioned elsewhere in the comments. We're inherently faster than other "serverless" platforms due to the scale and homogeneous design of our network, and that network has presence in nearly 50% more cities than it did just 3 years ago. We were plenty fast enough then and we're even faster now. Other things that customers (still) really care about: developer experience, ease of use, and cost. Nobody likes paying the AWS tax to move data around—they just want to use the best solution from the best cloud provider. Workers and the associated storage primitives allow them to pick and choose from the best that AWS, Azure, Cloudflare, GCP, et al. have to offer. (Disclaimer: I'm a long time Cloudflare employee focused on App Sec, and I speak to customers regularly who look to Workers largely for compliance reasons, but I don't work on the Developer Platform business. Am sure my Dev Platform peers will chime in with more nuanced answers!)
fmajid 4y ago
The US CLOUD Act means a EU customer cannot use a US cloud provider to host PII, even if the server itself is physically in the EU, because US law will still compel the provider to yield the data to US authorities. The European Commission is trying to paper over the cracks with a fig leaf of judicial review, but it's only a matter of time until a Schrems III decision from the CJEU invalidates that polite fiction.
- 4y ago

vendiddy 4y ago

I can second this. We were evaluating moving off Heroku and to Fly.io, but we didn't need all of the edge compute stuff. We just want a better Heroku without having to think about infrastructure and having to think about edge compute just got in our way. I feel like Next.js is in a similar position. While their main vision is SSR, I wonder if they are missing out on a chunk of the market that simply doesn't want to think about infra. We use them because we just don't have to worry about webpack or fiddling with deployment and hosting. We could care less about SSR and in fact we disabled it app-wide.

alexgrover 4y ago
Why would they be missing out? Vercel can host static sites just fine, whether that’s one generated by Next or any other framework or written by hand
- vendiddy 4y ago
  To clarify, I'm referring to folks who just need to write single page apps, but don't benefit from SSR. (I didn't find disabling SSR straightforward.) I wonder if Vercel is underestimating the size of the market that just wants a "Heroku for React".
leerob 4y ago
One of the key design choices of Next.js was to enable granularity on the runtime (Node.js or Edge[1]) and the rendering method (static or dynamic[2]) on a per-route basis. If you want a full SSR site, that's okay. If you want a full static site, that's also okay. We often see folks wanting a mix of both. For example, maybe the /about page is static, but the home page is dynamic and personalized based on the visitor. You can do all of this with Next.js. Our future direction is adding even further granularity, enabling this decision at the data fetch level, allowing you to cache results across deployments[3]. [1]: https://beta.nextjs.org/docs/rendering/edge-and-nodejs-runtimes https://beta.nextjs.org/docs/rendering/edge-and-nodejs-runti... [2]: https://beta.nextjs.org/docs/rendering/static-and-dynamic-rendering https://beta.nextjs.org/docs/rendering/static-and-dynamic-re... [3]: https://vercel.com/blog/vercel-cache-api-nextjs-cache https://vercel.com/blog/vercel-cache-api-nextjs-cache

bostik 4y ago

There's a wonderfully blunt saying that applies here (too): you are not in the business you think you are, you are in the business your customers think you are. If you offer data volumes, the low water mark is how EBS behaves. If you offer a really simple way to spin up Postgres databases, you are implicitly promising a fully managed experience. And $deity forbid, if you want global CRUD with read-your-own-writes semantics, the yardstick people measure you against is Google's Spanner.

quickthrower2 4y ago
In a nutshell if you offer cloud services you need to be better than the MAG clan, Digital Ocean too. And people will want it dirt cheap. It’s still hard to be a profitable web host as it always was (MAG has the advantage that none of them were web hosts at first base)
- blowski 4y ago
  MAG?
  - avidal 4y ago
    From context, I'm assuming Microsoft / Amazon / Google, referring to Azure / AWS / Google Cloud respectively.
    - gvtek0 4y ago
      Yep. Because when I think reliable cloud infra, I think Azure.
  - deleted 4y ago
    [deleted]
  - jerrygenser 4y ago
    microsoft apple google
  - gizmo 4y ago

erebe__ 4y ago

You can take a look at www.qovery.com It provides an Heroku like experience but runs on your cloud account (aws, scaleway or digital ocean). They build on existing tech that is already working, so it is more stable.

ignoramous 4y ago
Save for a few "in-preview" features, Fly was stable too but then they started growing faster than they could keep up (a good problem to have!). Stability isn't a permanent state.

richardhod 4y ago

What are the limitations to heroku that people are going to Fly for? Maybe there's a standard article that would be useful to read about it?

zamnos 4y ago
It's more about Heroku dropping free and low-cost plans, which is them demonstrating that they don't currently care about three low end of the market, more than any specfic feature.
- doodlesdev 4y ago
  Also the absolute disaster with security they had just before dropping free tiers, and the awful response which took months to even acknowledge some kinds of data (such as pipeline keys) where affected. [0] [0]: https://github.blog/2022-04-15-security-alert-stolen-oauth-user-tokens/ https://github.blog/2022-04-15-security-alert-stolen-oauth-u...
mcintyre1994 4y ago
This is an old doc from fly so I’m not sure how much of it is still accurate, but it talks about some of the stuff Heroku didn’t have that they have: https://fly.io/docs/app-guides/speed-up-a-heroku-app/ https://fly.io/docs/app-guides/speed-up-a-heroku-app/ > There's no support for a single dedicated IP address for your application. With Heroku, your application's CPU resources are mostly located in one datacenter. Heroku doesn't support HTTP2 or Brotli compression and it doesn't do Edge TLS termination. And it doesn't run your applications on dedicated MicroVMs. These are all things that Fly's Global Application Platform does. The other comment that mentions Heroku dropping low cost plans is the reason for the explosion in growth as I understand it though.
simonw 4y ago
People don't trust it any more, because Salesforce have been under-investing in it for years and recently rug-pulled on everyone who had ever used the free tier (after providing that free tier for 15 years already - long enough for people to reasonably expect it to continue).

VWWHFSfQ 4y ago

> dirt simple managed Postgres Heroku PostgreSQL is very simple, yes. But once you need non-trivial scale it's expensive and extremely non-performant. Even a medium-sized RDS will outperform Heroku's most expensive database offering by 20x in my experience. My company doesn't even run PG on Heroku anymore. We have a VPC/Private Space connection to AWS Aurora because the cost/performance difference is so extreme.

snacktaster 4y ago
I don't know the details of how Heroku implements their hosted postgres service, but I'm _guessing_ that it's just a bunch of PG servers running on EC2 instances. There's probably a lot of CPU stealing "noisy neighbors" going on. But yeah, I've also experienced Heroku's PG databases being dog-slow compared to RDS for the same workloads.
- mixmastamyk 4y ago
  They're probably using older or cheaper instance types. By not upgrading while charging the same or more over time, one can skim more profit.
karmelapple 4y ago
I have run the experiment, and Crunchy Data’s Postgres servers are 4X more bang for the buck than Heroku’s. I let some folks at Heroku know this who are product managers, and they are investigating it… but I would be shocked if Heroku gets a big performance improvement anytime in, say, 2023. 20X seems like a lot for RDS, though I’d be curious to learn more! We are switching to Crunchy because of that clear cost/performance difference you mention.
- jrochkind1 4y ago
  I would be kind of shocked if heroku gets a big performance improvement ever again. It seems the owners have decided to basically freeze it.

leishman 4y ago

This is spot on. I found myself using Fly for a project because it was super easy, not because I needed edge compute. TBH it's still actually unclear to me who needs edge compute? What apps require this sort of infra? It's not 99% of web apps right?

davnicwil 4y ago
Personally I see this as a 'why not, if it works' type thing. Sure you don't need it for 99% of usecases, but if it just works using familiar architectures then it is also strictly better for 99% of usecases so you might as well, and people will naturally want it. That 'familiar architectures' part is the hard bit, though.
- kevincox 4y ago
  But it isn't better in 99% of use cases. Lots of use cases are rendering an API response or HTML page that involves multiple database requests. Therefore the distance between database and app server is more important than the distance between the client and the app server. Edge compute can be helpful for static or quite cachable content. But often this is handled as well or nearly as well by a caching CDN. So that leaves a few cases where edge compute is useful. Where you are globally distributing the data itself (and ideally moving the data around as your users travel or move) which is incredibly rare and expensive to build, and when you need pure computation that needs no request to your backend and if 50ms of latency is important for a pure computation most of the time you can just move it to the client. In my experience these tend to be rare. I would estimate that edge compute is actually helpful for 1-5% of projects, not 99%.
hinkley 4y ago
I still think that in the next pendulum swing we'll end up with edge computing and (smaller) self-hosted backends. Everything old is new again, and we haven't entirely recreated Akamai from first principles yet.
vineyardmike 4y ago
One of the big benefits of edge compute is that it’s geographically distributed. Doesn’t make a big impact across the US, but globally a lot of nations have specific data laws, so it’s important to host data in the required nation. Keep customer data in its nation of origin, but have a single control plane and platform for ever data center.

satvikpendem 4y ago

I'm going to plug Coolify, an open source Heroku alternative (with Docker support too) that I'm using on a cheap $5 Hetzner server which is a lot cheaper than the equivalent Fly or Render etc service, and it really doesn't have much upkeep from me even if you add in the time setting up the server initially, which is like an hour, and afterwards, it Just Works™. https://coolify.io https://coolify.io

notpushkin 4y ago
Dokku is also nice and battle-tested: https://dokku.com/ https://dokku.com/ And may I also plug Lunni, a self-hosted Docker Swarm-based PaaS I'm working on right now: https://lunni.dev/ https://lunni.dev/ Both work pretty well on $5 servers.
- satvikpendem 4y ago
  Lunni looks really interesting! Looks like a Coolify competitor, I'll definitely check it out. Do you have a Discord to join? Coolify has one and I found it great to discuss the project and talk directly to the creator. I used to use Dokku but I personally liked the GUI from Coolify so I've been using that. Nice to see that you have a GUI as well, makes configuring apps a lot easier.
  - notpushkin 4y ago
    That's a nice idea actually, thank you! Just launched one: https://discord.gg/9EAne8g2Pq https://discord.gg/9EAne8g2Pq (Bridged to Matrix: https://matrix.to/#/#lunni:matrix.org https://matrix.to/#/#lunni:matrix.org) Lunni is actually pretty young in terms of community (just me and a few friends now :-), so just a room in Telegram was sufficient so far, but I think it's a good time to start something more official.
    - satvikpendem 4y ago
      Thanks, just joined. One thing I noticed is that the CI/CD setup for GitHub/lab is still based on the CI files themselves. What I like about Coolify and didn't like about others is that I could simply install a GitHub app to my account and Coolify would automatically pull my repositories and even set up git push to deploy for me, no messing around with CI files needed. https://lunni.dev/docs/deploy/from-git/#github https://lunni.dev/docs/deploy/from-git/#github vs https://docs.coollabs.io/coolify/sources https://docs.coollabs.io/coolify/sources

ghiculescu 4y ago

I coincidentally tweeted the exact same thing earlier today. I selfishly hope Fly put all their focus toward becoming Heroku 2.0. I’m sure some people care about all the edge latency stuff but I don’t know many of them.

machiaweliczny 4y ago
Yeah, I guess devs first will need to learn better SQL before it will start to matter.
deleted 4y ago
[deleted]

hiAndrewQuinn 4y ago

God, I'm glad someone else sees it as clearly as I do. I learned about Fly from them acquiring freaking Litestream! The SQLite replicator! The canonical database at the edge of the network! Of course that's what they want to do.

decidertm 4y ago

I'm a co-founder at Northflank. This is what we've spent 3+ years building. https://northflank.com https://northflank.com. I am sympathetic with much of Kurt's post. We spent a long time building solutions to several of the areas highlighted (managed PG, persistent volumes, secret management and service discovery). Making radical changes to architecture on a live cloud platform is always a challenge. On the front-end Northflank is a next-gen PaaS built for high DX, speed, and powerful capability (real-time UI, API, CLI, GitOps, IaC). Our backend is built using Kubernetes as an OS: providing a huge amount of flexibility on service discovery, load-balancing, persistence/volumes and scale. The benefit of using Kubernetes is a universal API across all major cloud providers. We can scale clusters and regions across EKS, GKE and AKS in seconds, either in our managed PaaS or inside our customer's own cloud account. Our managed dataservices: MySQL, Postgres, Redis, Mongo, Minio are all built using Kubernetes Operators with a small but mighty team. From a generous free tier to autoscaling to managed postgres and other advanced PaaS/DevOps automation workflows Northflank offers something unique.

mrkurt 4y ago

This is, indeed, the exciting part. As Heroku fans, we never really felt like it needed a replacement. And if it did, it seemed like Render was the natural Heroku v.next. One thing we've noticed, though, is that people do actually want Heroku but close to users. It's not exactly edge compute. In some cases, it's "Heroku in Tokyo". In others it's "Heroku, but running in all the english speaking regions". I think the thing that ate up most of our energy is also the thing that might actually make this business work. We built on top of our own hardware. That's the thing that made it difficult to build managed Postgres. We put way more energy into the underlying infrastructure than most nü-Heroku companies. The cost was extreme, but I'm like 63% sure this was the right choice.

KRAKRISMOTT 4y ago
Just partner with Neon or other similar companies in this space. Scale-to-zero distributed databases is well understood technology. https://neon.tech/ https://neon.tech/
- nikita 4y ago
  Yes, we are partnering with many companies like Hasura and Replit to help with managed Postgres. Since Neon scales to 0 and also autoscales to your workload it very economical for the long tail of low usage customers.
- pier25 4y ago
  Does Neon support triggers and subscriptions?
  - nikita 4y ago
    yes to triggers - it's full postgres. logical replication is not exposed just yet, but soon
    - pier25 4y ago
      will subscription work with scale to zero?

sirsinsalot 4y ago

Digital Ocean gave me the PaaS replacement and managed PG and I couldn't be happier. If anyone else is looking.

chillfox 4y ago
I tried running a docker app on Digital Ocean's app platform, the UI is nice and I can see it being acceptable for your average CRUD app. But I had to abandon it due to the latency just being too high and their built in monitoring interval not being configurable to the ~5-20ms range (this was for competitive Battlesnake last year).

say_it_as_it_is 4y ago

Edge of what exactly? The software resides within networks they control. There is no edge in this scenario.

MuffinFlavored 4y ago

> generous free level of service, Can't you make the argument that Heroku got out of this market on purpose? I know they were bought out by "ye old corporate greedy meanie overlord" or whatever but... I'm sure there is data that showed it made sense from a "make money business" perspective to not be in that market.

natbobc 4y ago
I would even go so far as to say free users aren’t customers in a platform like this. There’s no revenue model and if it’s “run without constraint” you get some fun scaling problems but those types of issues can sometimes lead to optimizations that keep the system online in the face of many small apps but doesn’t necessarily cover the case of a large resource app.

milani 4y ago

> lower cost as you scale The cost aside, I'm wondering how fly or heroku support their customers when they grow to microservices ecosystems. The problem shifts from deploying easily to deploying reliably meaning one release of a service should not break the other services. Other problems appear too, like service discovery, peer authentication, gateways, test and staging environments where there are downstream dependencies, etc. Are customers supposed to leave when they grow to this level? Or are there solutions for these?

amw-zero 4y ago

Why does there need to be a successor to Heroku?