[HN Gopher] RIP Flynn.io
___________________________________________________________________
RIP Flynn.io
Author : corobo
Score : 147 points
Date : 2021-02-28 17:31 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| hiharryhere wrote:
| I used Flynn for a side project. When it worked it was awesome
| and simple, but it was a bit too unpredictable and flakey for me
| to feel comfortable using it in my company.
|
| Dokku has been rock solid for almost 5 years now for my business.
| Would love to have multiple nodes but otherwise fantastic and
| easy. I had to move off Heroku as my customers require an
| Australian based host and heroku doesn't support the region.
| Migrating was a breeze.
|
| I wanted to love Flynn and checked back in it every year or so
| but the blogs stopped a long while back and the brief
| documentation never really fleshed out.
| golemiprague wrote:
| How do you deal with maintaining and securing the servers? The
| big advantage of Heroku is that for small projects you don't
| have to deal with server maintenance, you just upload and
| forget. Isn't using Dokku kind of miss the whole point?
| neom wrote:
| Jeff Lindsay who was heavily involved in developing Flynn (and
| Dokku) is working on a pretty cool new project called Tractor,
| it's basically a modern Smalltalk environment:
| https://github.com/sponsors/progrium
| jpgvm wrote:
| I was one of the maintainers of Flynn for a period of time and I
| still use it on a personal cluster that has been humming along
| problem free for several years.
|
| I'm very sad to see it go of course but the writing was on the
| wall for a long time after the demise of all non-k8s container
| management systems.
|
| This is the ultimate fate of tools like Nomad and services like
| ECS. k8s changed the game by providing a target API/platform that
| gained enough traction to force each of the large providers to
| support a managed implementation of it.
|
| I miss my time working on Flynn, we were a very small team but we
| wrote some good software and I learnt a ton in the process.
| mwarkentin wrote:
| I don't see ECS going anywhere. AWS still maintains old
| services like SimpleDB and ECS development seems to be speeding
| up if anything.
| dig1 wrote:
| Sad news, but I'm not surprised with this. The complete ecosystem
| was "killed" (if that can be said) with K8s buzz and hipsterism
| (sorry guys, but I see K8s as Hadoop/BigData of modern days - a
| solution from a huge company that has no place in 90% setups).
| Alternatives like Deis [2] moved to K8s a long time ago. My
| favorite tool for some time, Rancher [3], did that as well.
|
| I've been using Dokku [1] for a few years on a small setup,
| surprisingly without a single problem, taking into account it was
| written in "not-so-cool" bash. And I was considering Flynn as the
| next step if I need to scale it because Dokku doesn't have
| clustering support (added: looks like clustering support for
| Dokku is in work [4]).
|
| After many checks, I got the impression Flynn simply wasn't there
| yet. Either because of low development pace, low number of
| supported appliances, or something else, I'm not sure. In the
| end, I picked up Ansible for more distributed installations.
|
| [1] https://dokku.com/
|
| [2] https://deislabs.io/
|
| [3] https://rancher.com/
|
| [4]
| https://www.reddit.com/r/devops/comments/bgpw5w/flynn_vs_dok...
| imdsm wrote:
| Dokku, Deis, Rancher, and finally Flynn. Another one falls.
| I've been around all these projects and small scale docker PaaS
| for almost a decade, and k8s has just killed them off, which is
| so sad. As you say, you don't always want to use k8s for a
| small three machine setup. I guess it was always going to
| happen, after containers stopped feeling cool, people stopped
| working on projects for them.
| josegonzalez wrote:
| Re: Dokku, reports of our demise are greatly exaggerated.
|
| We're still chugging along, and have recently added Cloud
| Native Buildpacks support[1], as well as integrations with
| Kubernetes[2] and Nomad[3]. Happy to hear where you found out
| that development on the project was halted, given that I made
| a release yesterday[4]... [1]:
| https://dokku.com/docs/deployment/methods/cloud-native-
| buildpacks/ [2]: https://github.com/dokku/dokku-
| scheduler-kubernetes [3]:
| https://github.com/dokku/dokku-scheduler-nomad [4]:
| https://github.com/dokku/dokku/releases/tag/v0.23.9
| arcturus17 wrote:
| > Dokku, Deis, Rancher, and finally Flynn. Another one falls.
|
| Isn't Dokku alive and well? I don't use it but I read about
| it in some related research recently, and some people on this
| thread report to be happy users.
| stefan_ wrote:
| It works perfectly fine, chugging along nicely. This whole
| thread confuses me; the whole point of Dokku is that _it
| isn 't k8s_.
|
| It's not like you were gonna deploy Dokku at $BigCorp, no
| Kubernetes is a huge selling point for anything I'm gonna
| use in my free time.
| JMTQp8lwXL wrote:
| Slightly off topic, but when is 'big enough' for k8s to make
| sense? Is dozens of eng teams plus 50+ microservices make
| sense?
|
| For a company that is a single eng team, it's obvious. But
| progressively larger organizations, it seems like a gray zone.
| jordanthoms wrote:
| I moved us from Heroku to GKE a few years ago when we had ~4
| engineers - Took a bit to get things figured out and get CI
| deploys etc working well, but it really wasn't all that
| complicated.
|
| Honestly baffled at how many people are convinced you need
| hundreds of engineers before k8s can work well - they must be
| doing something very different from what we are. We did keep
| databases out of k8s (until recently when we added
| CockroachDB running inside the cluster) and only had ~6
| services to move which may have kept things simpler. We're
| now scaling to run thousands of vcpu at peak times and a
| dozen different services, and it's still not all that hard to
| manage.
|
| Can somebody who has had the opposite experience comment on
| what actually made it so difficult to implement? I imagine
| that if you are managing the cluster control plane yourself
| that will make things much more difficult - but unless you
| have some very specific requirement you can use a hosted k8s
| to reduce that.
| arcticfox wrote:
| > For a company that is a single eng team, it's obvious.
|
| I'm not sure I get this. Are you saying that it obviously
| does or doesn't make sense?
|
| My team is _three people_ and k8s makes our lives easier than
| any alternatives I 'm aware of. We used to be on Heroku,
| which is cool, until you need to do run anything other than a
| monolith or more secure than all publicly-accessible
| services.
| IgorPartola wrote:
| It's not dependent on size but what you do. If you run a mono
| stack you initially spend less time on devops than when you
| run microservices. Anyone that tries to tell you otherwise
| hasn't done a Heroku deploy lately. When your engineers spend
| enough time on devops to impact productivity is when you
| reach for a different solution. I can only see one other
| reason to start with microservices: you are developing
| something with much higher than usual security requirements
| and need an "air gap" between pieces of your system. Like if
| you store raw credit card numbers and want to separate their
| storage mechanism from the res rig the system with a really
| tightly controlled API.
|
| Even so, K8 is a solution where running containers on a
| container as a service system is prohibitively expensive. The
| newfangled systems aren't free in terms of operating costs
| and would you rather pay for extra hardware or for
| engineering time, knowing that hardware doesn't take
| vacations or leave your company for a better job?
| kostarelo wrote:
| > It's not dependent on size but what you do
|
| It is dependent on size. You could for example start with
| an engineering team working on a mono stack and outsource
| data and analytics operations. But at some point, you will
| decide that data and analytics have to be in-house. You
| start with a mono stack for each of them. But then you
| suddenly start splitting each of these three into sub-
| teams. Suddenly mono stack doesn't make all that sense.
|
| K8s solves the problem of horizontal scaling in both teams
| and infrastructure. It's inevitable when (and only if) you
| plan on scaling up. Not that all teams/companies will/want
| to follow that path.
| chucky_z wrote:
| I'd take the alternate view. K8s is a huge relief from both
| development and operations, but it absolutely _requires_ an
| entire team of dedicated folks along with re-tooling
| everything to fit it 's paradigm. This is true of all
| orchestration systems, but _especially_ true for k8s. If you
| have a dozen eng teams and 50 microservices, and 2 or 3
| devops /SRE people because it's all in AWS/GCP/Azure, k8s is
| going to crash and burn. If you have a dozen eng teams with
| 2+ devops/SRE folks in each of them, and a handful of extra
| folks to form a whole new team for K8s you're in great shape.
| JMTQp8lwXL wrote:
| We have multiple data centers and a similarly sized devops
| team (separate from SRE). They're exceptionally skilled and
| lord I pray they'll make it, because I know it won't be an
| easy journey.
|
| None of our teams have dedicated devops engineers. Teams
| just have engineers that do everything: back end, front
| end, deployments, monitoring dashboards. Teams write run
| books for SRE. Dev Ops supplies eng teams tooling for
| deployments.
|
| I've argued many, many times we spread our engineers too
| thin and we need greater specialization for better
| outcomes. We have enough engineers, but the problem is
| everyone owns their own thin but very tall vertical slice
| of the total system.
| dilyevsky wrote:
| We have 3 infra eng + manager for over a dozen devs and a
| bunch of services deployed on k8s (including all DBs). K8s
| itself is self managed (nothing is hosted) and has been the
| least of our concerns operations-wise.
| IgorPartola wrote:
| Dokku has been a workhorse for me. For all the fears of "but
| what about redundancy?" I have run a fairly successfully
| service on it for five or so years on a single Vultr VPS and
| made more money from that than any other side project or all of
| them combined. Glad I directed my attention to the product and
| not the devops like I had in the past. 10/10 would recommend.
| babaganoosh89 wrote:
| Caprover is also nice, you use docker files instead of heroku
| build packs and it has a nice gui.
| conradfr wrote:
| I recently transitionned from capistrano deployments to
| CapRover and it's mostly working fine. The variety of ways to
| deploy apps was especially relevant to my situation.
|
| My biggest complaint would be the non-zero downside
| deployment.
| csnweb wrote:
| May be it's less about kubernetes then about the market itself?
| If I don't want do any ops I also don't want to maintain a
| server and keep that safe, so I would go for Heroku instead of
| running that myself. And if you need more there are also
| managed k8s offerings which seem to be working fine for many
| small teams as well. For us it's basically a cheaper version of
| Heroku with a little bit more effort. We are actually using
| small managed k8s clusters from Digitalocean since nearly a
| year now and had zero issues with it so far. I really like not
| having to take care of the servers.
| dedene wrote:
| Is there a good maintained alternative?
| jrnkntl wrote:
| I'm happily using Dokku[1] and another one in this host your
| own PaaS space is CapRover[2]
|
| [1] https://dokku.com/
|
| [2] https://caprover.com
| boramalper wrote:
| I can second Dokku, though haven't used CapRover. Dokku has
| its quirks but it has served me well in the past two years.
| josegonzalez wrote:
| Maintainer of Dokku here.
|
| Would love to pick your brain as to what our quirks are and
| how we might avoid them in the future. Feel free to hit up
| the `@dokku` twitter account, catch us on the gliderlabs
| slack (https://glider-slackin.herokuapp.com), or even
| provide feedback in the Discussions section of the primary
| Github repository
| (https://github.com/dokku/dokku/discussions).
| LogicX wrote:
| Going to take you up on this offer. We've been running
| Dokku in production for years; and have a few quirks
| which have resulted in us evaluating moving to k8s.
| kevinob11 wrote:
| @josegonzalez, thanks so much for all of your work on
| Dokku and for being so responsive in the community for
| the last couple years. We tried Flynn at one point and
| had enough issues we moved back to dokku within 2 months
| and have been happily living on it for years now. You
| helped me directly with an issue with DB naming at one
| point, much appreciated!
| tebbers wrote:
| Dokku is FANTASTIC, thank you so much for your work on
| it.
| simplify wrote:
| I can second caprover. Personally I find it easier to use
| than dokku. The admin ui is quite nice.
| josegonzalez wrote:
| Aside from having an admin UI, would you be willing to talk
| a bit about how caprover is easier to use than dokku?
|
| Feel free to hit up the `@dokku` twitter account, catch us
| on the gliderlabs slack (https://glider-
| slackin.herokuapp.com), or even provide feedback in the
| Discussions section of the primary Github repository
| (https://github.com/dokku/dokku/discussions).
|
| (I am the dokku maintainer).
| faizshah wrote:
| Kind of related: is there something like Dokku but for FaaS?
| krts- wrote:
| There's faasd [https://github.com/openfaas/faasd] which is
| OpenFaaS without the Kubernetes overhead.
| geerlingguy wrote:
| And alexellis is a pretty active maintainer.
| woudsma wrote:
| I'm working on a self-hosted, open source PaaS called Swarmlet.
| I really like Dokku, but I needed something that's a bit more
| scalable to my needs.
|
| The installer is currently broken, I simply don't have enough
| time / bandwidth right now to work on it unfortunately.
|
| That said, if you want to contribute, please let me know! I
| hope to get things running again soon.
|
| https://swarmlet.dev or https://github.com/swarmlet/swarmlet
| rdli wrote:
| Assuming you're a company (as opposed to an individual), if you
| want a PAAS, there are a few different options that in my view
| are sustainable which I think is the key criteria for adopting
| something for your platform.
|
| - Heroku. Sure it's a bit expensive but it's still super easy
| if you're a dev. - OpenShift. If you're a really big
| enterprise, OpenShift is a reasonable choice for PAAS. But only
| if you're huge. - Kubernetes. Yes, it's complicated. Yes, it
| has a steep learning curve. But it's open source, has a huge
| and growing ecosystem, and it has less lock in than any other
| PAAS-like thing that I can think of.
|
| The main downside of Kubernetes beyond its complexity is that
| you still have to build abstractions on top of it for your
| developers. But that world is improving regularly.
| qbasic_forever wrote:
| CapRover is a nice Docker-based PaaS you can run yourself:
| https://caprover.com/
| _kst_ wrote:
| As others have mentioned, the current site (README.md) says very
| little about what Flynn is.
|
| You can see a version of the repo and README.md, just before it
| became unmaintained, here:
|
| https://github.com/flynn/flynn/tree/2c20757de8b32a40ba06f7e5...
|
| IMHO it would have been much better if the maintainers had added
| the "Flynn is Unmaintained" information to the top of the
| README.md rather than removing all the existing information. I've
| submitted a GitHub issue suggesting it:
| https://github.com/flynn/flynn/issues/4623
|
| A plea to project maintainers in general: Please include enough
| information in your top-level README (or README.md, or
| README.whatever) so that someone who has never heard of your
| project can find get a good overview. I've also seen READMEs that
| only discuss the most recent changes. That's fine for readers who
| have already been following the project, but not for a more
| general audience.
| Aeolun wrote:
| Wonder if anyone will take this up now, since its BSD licensed
| and all.
|
| Guess it'd have to have a different name though.
| jabo wrote:
| I'm sad/surprised that a project with almost 8K stars on GitHub
| is dead. Does anyone know why they decided to not build/maintain
| it anymore?
| breakingcups wrote:
| If a project is primarily developed by one company,
| contributions will drop to approximately zero once funding runs
| out.
|
| Even if outside people are willing to contribute, there is
| usually no one with maintainer / merge powers who is willing or
| permitted to step up to handle contributions.
| toyg wrote:
| With enough alternative commercial supporters, someone will
| fork and keep going. But in this case it looks like there was
| no ecosystem of alternative providers who could pick up the
| mantle.
| ignoramous wrote:
| Software is hard [0], especially in the face of a rapidly
| changing tech industry. Incumbents are upended on a regular
| basis and even the mightiest FOSS projects falter, some less
| violently than others.
|
| Besides, stars may not be the right metric, but rather,
| community participation [1]. It could have likely helped had
| Flynn been donated to a Foundation like the Cloud Native
| Foundation (assuming they are open to incubating such
| projects)?
|
| Another reason could be that because momentum is everything
| when faced with stiff competition, things may have slowed down
| for Flynn.
|
| Some of the things that slow projects down:
|
| 1. Overwhelming feature gap.
|
| 2. Spiralling technical debt.
|
| 3. Rise in dramatic hard-to-fix bugs.
|
| 4. Inadequate staffing / inability to keep up with the changing
| ecosystem.
|
| Also, looks like the lead developer (@titanous) has deleted
| their blog and tweets too, and so, it is likely we will never
| know what went on. Hopefully, they consider publishing their
| thoughts so that we may all learn and improve.
|
| I wonder if Pieter Hintjens (of the ZeroMQ fame) had the right
| idea that a software project should always attempt to reach
| "completion" and stay "completed". That is, you complete one
| key part after the other and build on top of that solid
| foundation that doesn't change...? That might keep things in
| control for a small team of core developers to tackle issues
| arising from taking up as complex a task as Flynn's?
|
| [0]
| https://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/E...
|
| [1] https://medium.com/runacapital/open-source-growth-
| benchmarks...
| smashah wrote:
| I am also extremely interested as to why this stopped being
| maintained.
| jpgvm wrote:
| Macro: Kubernetes took all the air out of the room. Micro:
| Lack of funding.
|
| i.e pretty much the same as everything else that has went the
| way of the dodo in this space.
| ponyous wrote:
| Our staging environment is down because something went wrong with
| Flynn a week or two ago and there is absolutely no information on
| how to debug it.
|
| I'm happy they marked is as unmaintained because I got the
| impression it wasn't all that well maintained for last few years
| - can't remember why anymore, but something to do with having to
| use master branch otherwise the package was 3 years old in ubuntu
| main repository...
|
| I guess we'll be moving staging to k8s without hesitation now.
|
| It was decent and served the purpose for our staging environment.
| Rip.
| postit wrote:
| I'm disgusted that all competition to k8s is dying a slow death.
| I'm counting the days for nomad with expectation and whishing
| something better will arise.
| Aeolun wrote:
| I have the feeling that nobody is making (or trying to make)
| any money on Nomad? Their cash cow must be terraform.
| zimpenfish wrote:
| Worked for a company a couple of years ago that used Flynn (with
| one of the maintainers) and it was pretty easy to use and
| understand. I guess it's Dokku or Nomad for my next adventure
| then!
| endisneigh wrote:
| What ever happened to Docker swarm? Considering how popular
| Docker (still) is, I'm surprised it's not solidly #2 behind K8s.
| mintplant wrote:
| The Docker company gave up on all that and switched to selling
| "developer tools".
| [deleted]
| dhosek wrote:
| Aside from an easily-missed sidebar, there's nothing that
| indicates what flynn _was_. This happens a lot it seems with XXX
| is dead posts on HN. The link is to something that says that XXX
| is dead but there 's often little or no indication of what XXX
| was in the first place.
| maximilianroos wrote:
| Readme from before the change:
| https://github.com/flynn/flynn/blob/2c20757de8b32a40ba06f7e5...
| imdsm wrote:
| That's fair, but I guess the people who will feel sad about
| this are the ones who know what it is/was. I remember back when
| it was being developed, along with Deis and later, Rancher. But
| the shadow of Kubernetes has caused them all to wither. :(
| [deleted]
| sytse wrote:
| Their tagline was: "Flynn is an open source platform (PaaS) for
| running applications in production."
|
| In some way an alternative for using Kubernetes and managed
| services of cloud providers.
|
| I think there is a need for something that is easier to use
| than Kubernetes. I've started the 5 minute production app for
| this. The idea is to use managed services and Terraform to make
| stateful services easy. This way you're not locked in but have
| flexibility going forward.
| klohto wrote:
| Go with Nomad then
| walski wrote:
| In this case there is a very recent version of their landing
| page on archive.org:
| https://web.archive.org/web/20210203121152/https://flynn.io/
|
| (Not that the page had changed in any meaningful way in pretty
| much forever)
| riffic wrote:
| seriously the lack of context surrounding these sort of posts
| is lazy and awful.
| corobo wrote:
| You can submit text _or_ url mate. I would love to have given
| you context. I 'm not going to cram a companies history into
| the title, it wouldn't have got any upvotes :)
|
| In simple terms it was a self hosted Heroku. It got massive
| attention here and raised a load of cash before kubernetes
| etc were a thing
| macintux wrote:
| Sometimes people will post a quick comment after submitting
| a link indicating why they submitted it.
| corobo wrote:
| Aye and if they do that too soon you're back at no
| upvotes while people decide if you're farming karma or
| not
|
| In any case I got distracted and forgot about it till I
| saw it on the homepage
| einpoklum wrote:
| I wonder about that... why can't you submit a couple of
| sentences of context with your URL? Even a single sentence
| would be better than the nothing we have now, where you
| need to guess what the URL is about.
| corobo wrote:
| I had no idea it wasn't possible either until submitting
| this, I just thought everyone was being lazy and assuming
| knowledge of a product as the person I responded to did
| with me haha
| oap_bram wrote:
| I was definitely a _very_ late adopter of the program, but
| because it was so badly documented and seemingly dead even a few
| months ago I dropped it as well.
|
| I use https://fly.io now for this purpose. It's not self-hosted,
| but it does the job for me :)
| jimaek wrote:
| Consider checking https://appfleet.com as well, we worked a lot
| to simplify the process with a nice UI and a constantly
| improving UX
|
| Disclosure: I work for appfleet
| ornornor wrote:
| > I use https://fly.io now for this purpose.
|
| That looks pretty cool, thanks.
| evoxmusic wrote:
| Qovery is partially open source and have a 100% free plan for
| individual developers. https://www.qovery.com
___________________________________________________________________
(page generated 2021-02-28 23:00 UTC)