←back to thread

Reliability: It’s not great

(community.fly.io)
1226 points bishopsmother | 6 comments | 06 Mar 23 17:47 UTC | HN request time: 0.413s | source | bottom
Show context
samwillis ◴[06 Mar 23 19:38 UTC] No.35046486[source]▶
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!

replies(20): >>35046650 #>>35046685 #>>35046754 #>>35046953 #>>35047128 #>>35047302 #>>35047334 #>>35047345 #>>35047376 #>>35047603 #>>35047656 #>>35047786 #>>35047788 #>>35047937 #>>35048244 #>>35048674 #>>35049946 #>>35050285 #>>35051885 #>>35056048 #
satvikpendem ◴[06 Mar 23 21:07 UTC] No.35047603[source]▶
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

replies(2): >>35048654 #>>35048955 #
notpushkin ◴[06 Mar 23 22:27 UTC] No.35048654[source]▶
Dokku is also nice and battle-tested: 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/

Both work pretty well on $5 servers.

replies(5): >>35048720 #>>35049033 #>>35049034 #>>35050171 #>>35050962 #
1. arjvik ◴[06 Mar 23 23:00 UTC] No.35049033[source]▶
Lunni has got an interesting concept — and I can actually see some good uses for it!

Is the actual "production" workflow still pasting a Docker Compose file in? I would much rather have an automated deployment process that doesn't require human input, that way it can be scripted as part of CI/CD, etc.

Personally, I fell in love with `git push production` (naming a git remote `production`) to trigger a deploy. Ironically I didn't like this back when I first tried Heroku, but it's grown on me since. As of now, I have a custom git receive hook on my server (building a NAS from "scratch" using IaC on my home server) that triggers a redeployment using Docker Compose.

Also, you mention Swarm... what does Lunni bring with Swarm as opposed to simple Docker Compose? Does it distribute across multiple systems?

replies(1): >>35049453 #
2. notpushkin ◴[06 Mar 23 23:37 UTC] No.35049453[source]▶
I'll start with the Swarm since it's a major point actually: Docker's Swarm mode is comparable to Kubernetes or Nomad: you can launch a cluster of servers and run your application there.

Unlike Kubernetes or Nomad though, it uses mostly the same concepts Docker Compose does, to the point that your development docker-compose.yml file will likely just work there (with some minimal tweaks). I love this website that talks more about it: https://dockerswarm.rocks/

Edit: As opposed to `docker compose up`, when running on a single server: not much. It will restart on server reboot by default, and allow you to run multiple replicas of a service (deprecated in Docker Compose), but that's it. Most important though, it would allow you to add more nodes later on, and it will then scale your services across the whole swarm – so you can start with just one server and scale to hundreds if needed.

> I would much rather have an automated deployment process that doesn't require human input, that way it can be scripted as part of CI/CD, etc.

This is almost doable with Lunni. This guide will walk through setting up a CI for a typical webapp that packages it in a Docker image and pushes to a registry: https://lunni.dev/docs/deploy/from-git/ (currently for GitLab CI and GitHub Actions only)

As for the continuous delivery, we're gonna have a webhook that you can call when your CI pipeline is finished. It's not exposed in the UI yet but I'll try to prioritize it (now that I remember I wanted to do it :')

`git push production` feels a bit easier, but I'm a bit concerned about bloat: for this to work, we'll have to bundle some sort of CI and container registry with Lunni itself. I think sticking with third-party CI is a more elegant approach here. What do you think?

replies(2): >>35050156 #>>35050992 #
3. Aeolun ◴[07 Mar 23 01:06 UTC] No.35050156[source]▶
You can set up a git hook on repositories that listens for the completion of the docker_build task and then redeploys the app while pulling new images?
replies(1): >>35053381 #
4. moondev ◴[07 Mar 23 02:56 UTC] No.35050992[source]▶
> Most important though, it would allow you to add more nodes later on, and it will then scale your services across the whole swarm – so you can start with just one server and scale to hundreds if needed.

Have you in all honesty and with first hand experience, deployed and supported in prod on swarm over hundreds of servers?

replies(1): >>35053416 #
5. notpushkin ◴[07 Mar 23 09:30 UTC] No.35053381{3}[source]▶
Not a git hook, but you can do that as a part of CI workflow. So, you can have a script like:

    docker buildx build --push ...
    curl -X POST https://lunni.example.com/api/webhooks/c8aaa9b8-1bda-4a99-820c-36a75d31f8a7
that will rebuild a Docker image, then trigger the redeploy.
6. notpushkin ◴[07 Mar 23 09:37 UTC] No.35053416{3}[source]▶
Nope :') I do know a guy though, and I've heard good things. I'd love to hear about your experience too!

I know that it is possible to outgrow Swarm – I think that's a nice problem to have actually. We might include some tools for “graduating” from Lunni to something more serious like Kubernetes at some point.