8 ms·

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

by dig1 6y ago

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/ https://dokku.com/ [2] https://deislabs.io/ https://deislabs.io/ [3] https://rancher.com/ https://rancher.com/ [4] https://www.reddit.com/r/devops/comments/bgpw5w/flynn_vs_dokku/elqdska https://www.reddit.com/r/devops/comments/bgpw5w/flynn_vs_dok...

babaganoosh89 6y ago
Caprover is also nice, you use docker files instead of heroku build packs and it has a nice gui.
- conradfr 6y ago
  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.
IgorPartola 6y ago
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.
- undecisive 6y ago
  Absolutely this. While I'm mildly curious what will come of dokku + kubernetes (and maybe a little excited, though have tempered expectations), actually setting up some simple scripting that points to dokku means I can be fairly sure that when I've set up a dokku box, the databases are backed up, should the box go down and all the backups get fried, I can have a new box set upp they will be back up and running in much less than an hour from the point that I notice. So the only reason I might want something like Flynn is in the case of unexpected uptick in load. And unfortunately, in my first experience with Flynn, things went bad and I wasn't able to restore from backups, which scared me off more than I was scared about load balancing (read: ran out of time for the experiments and vowed "one day I'll try again. Maybe."). That said, overall flynn did seem reasonably polished, so I'm sad about the announcement. Maybe, some day, someone will take on this middle ground between Dokku and Kubernetes. But until then, Dokku has definitely proved itself.
JMTQp8lwXL 6y ago
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.
- IgorPartola 6y ago
  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 6y ago
    > 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.
    - IgorPartola 6y ago
      Is K8s the only way to deploy two different services that talk to each other? Why not something like AWS’s or Google’s or Microsoft’s container service? Why not a second app on Heroku or Google App Engine, etc? If you have a team of 50 engineers but 40 of them work on the front end of your SPA, and the backend is simple CRUD, why do you need your own container infrastructure? I stand by that the decision should be primarily based on how much of your team’s effort is diverted to devops. K8s is a devops solution, not a way to organize code or a development framework.
imdsm 6y ago
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.
- arcturus17 6y ago
  > 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_ 6y ago
    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.
- josegonzalez 6y ago
  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
  - mauflows 6y ago
    Thank you so much for you're work. Seems like you give attention to every issue filed
- 6y ago
csnweb 6y ago
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.
jokethrowaway 6y ago
Sure K8s is kinda heavyweight but it's simple to use and complete. My minimal self hates k8s but my get-stuff-done self uses k8s.

by dig1 6y ago

babaganoosh89 6y ago

Caprover is also nice, you use docker files instead of heroku build packs and it has a nice gui.

conradfr 6y ago
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.

IgorPartola 6y ago

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.

undecisive 6y ago
Absolutely this. While I'm mildly curious what will come of dokku + kubernetes (and maybe a little excited, though have tempered expectations), actually setting up some simple scripting that points to dokku means I can be fairly sure that when I've set up a dokku box, the databases are backed up, should the box go down and all the backups get fried, I can have a new box set upp they will be back up and running in much less than an hour from the point that I notice. So the only reason I might want something like Flynn is in the case of unexpected uptick in load. And unfortunately, in my first experience with Flynn, things went bad and I wasn't able to restore from backups, which scared me off more than I was scared about load balancing (read: ran out of time for the experiments and vowed "one day I'll try again. Maybe."). That said, overall flynn did seem reasonably polished, so I'm sad about the announcement. Maybe, some day, someone will take on this middle ground between Dokku and Kubernetes. But until then, Dokku has definitely proved itself.

JMTQp8lwXL 6y ago

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.

IgorPartola 6y ago
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 6y ago
  > 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.
  - IgorPartola 6y ago
    Is K8s the only way to deploy two different services that talk to each other? Why not something like AWS’s or Google’s or Microsoft’s container service? Why not a second app on Heroku or Google App Engine, etc? If you have a team of 50 engineers but 40 of them work on the front end of your SPA, and the backend is simple CRUD, why do you need your own container infrastructure? I stand by that the decision should be primarily based on how much of your team’s effort is diverted to devops. K8s is a devops solution, not a way to organize code or a development framework.

imdsm 6y ago

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.

arcturus17 6y ago
> 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_ 6y ago
  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.
josegonzalez 6y ago
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
- mauflows 6y ago
  Thank you so much for you're work. Seems like you give attention to every issue filed
6y ago

csnweb 6y ago

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.

jokethrowaway 6y ago

Sure K8s is kinda heavyweight but it's simple to use and complete. My minimal self hates k8s but my get-stuff-done self uses k8s.