6 ms·

PAAS Comparison – Dokku vs. Flynn vs. Deis vs. Kubernetes vs. Docker Swarm

128 points by wilsonfiifi 9y ago

SubiculumCode 9y ago
Well one is a Russian operative. ;)
- medecau 9y ago
  Sad.
- WrtCdEvrydy 9y ago
  I think Flynn should rename, just saying.
jacques_chester 9y ago
A first note, this is not like-for-like. Dokku, Flynn and Deis fit the PaaS spot more meaningfully. Kubernetes and Swarm are sometimes called "Container as a Service" -- you still need a bunch of work to select, install and configure features that PaaS users take for granted. Missing from the list: Cloud Foundry. And OpenShift! Give Red Hat some respect here for making Kubernetes into a platform. And DCOS, which I think got its thunder stolen by Kubernetes. But I mostly know Cloud Foundry, because it's my day job to keep making it better. It's the most mature out of all of these, has been soak tested to 250,000 running applications[0], can be deployed to any major IaaS or bare metal, comes with routing, logging, service injection, healing, no-downtime upgrading and I forget what other headlines I usually pick out of the several hundred features it now includes. The Cloud Foundry Foundation includes Pivotal (my employer), IBM, SAP, Google, DellEMC, VMWare, Cisco, Suse and those are just the fancy tech names. The reason you don't hear about it is that we and our partners have focused on competing for enterprise sales. It's not how you get publicity on HN, but it does mean that PivotalCF -- our commercial distribution -- has the fastest-growing sales of an opensource-based product in history. And sales are still zooming up and to the right. The nice thing is that we and other partners get very broad, specific feedback from customers who are already at massive scale and who expect utter, non-negotiable reliability. We run a public service ourselves (Pivotal Web Services), SAP have HANA Cloud, IBM runs BlueMix. We and other Cloud Foundry contributors have had the benefit of that dogfooding and feedback for longer than any other container-based platform in existence. And it turns out, there are so many things that can go wrong. So many. It's crazy. Lastly, Cloud Foundry teams have massive investments in project automation. This gives us two capabilities: one is that we can roll out complete rebuilds of the whole platform within hours of an upstream CVE patch. Users can then apply these fixes to their platform live, in-place, without any running apps noticing that it has occurred. BOSH[1] will roll out the deployment with canaries, and Diego[2] will relaunch containers as they are reaped during upgrade. The second capability is that we are confident in making very deep, very aggressive changes if it proves necessary, because we have tests upon tests upon mountains of more tests. And again: nobody notices, except that their platform gets faster or becomes reliable under even more extreme circumstances. If I sound like an utterly biased fan, it's because I am an utterly biased fan. I've watched this thing evolve up-close for years. It is amazing. We build installable superpowers. Disclosure: If it's not obvious, I work for Pivotal on Cloud Foundry. [0] https://content.pivotal.io/blog/250k-containers-in-production-a-real-test-for-the-real-world https://content.pivotal.io/blog/250k-containers-in-productio... [1] http://bosh.io/ http://bosh.io/ [2] https://github.com/cloudfoundry/diego-design-notes https://github.com/cloudfoundry/diego-design-notes Minor edits for style.
- tyingq 9y ago
  Mesos should probably be on the list as well.
  - jacques_chester 9y ago
    Absolutely. I made a side reference through DCOS, which is the PaaS-packaged Mesos.
- Veratyr 9y ago
  Is it still the case that CF requires a ton of overhead to get running? Last I checked there was no easy way to set up CF without: - Running on a cloud - Spinning up ~8 different servers, each with ~2GB of memory iirc Kinda a lot of overhead if you're just running a few dev environments like I was.
  - jacques_chester 9y ago
    I get this question a lot. PCFDev[0] if you just want a dev environment to tinker with. You can also tinker with cflocal[1] (unsupported) or BOSH-lite[2] (somewhat-supported) if you're looking to practice ops as well. A lot of Cloud Foundry teams do integration testing with BOSH-lite on large single VMs, because it essentially presents BOSH with a "VM" interface that spins up nested containers instead. You can, in theory, deploy however few or however many real VMs, or bare metal servers, as you wish, by editing a BOSH manifest. By default the cf-deployment[3] manifest uses something like 23 VMs of varying sizes. That's because the default manifest is intended for production use with multi-AZ HA as the minimum level of reliability. If you don't need that, one of the alternatives I noted will get you what you want. [0] https://pivotal.io/pcf-dev https://pivotal.io/pcf-dev [1] https://github.com/sclevine/cflocal https://github.com/sclevine/cflocal [2] https://github.com/cloudfoundry/bosh-lite https://github.com/cloudfoundry/bosh-lite [3] https://github.com/cloudfoundry/cf-deployment https://github.com/cloudfoundry/cf-deployment
- smashed 9y ago
  But to be fair, Pivotal Cloud Foundry is so expensive it's not even in the same league as the others and I can totally understand why the article just ignored it altogether.
notamy 9y ago
Somewhat-related question: I have a cluster of ~6 machines that I'm using to play with containers and container orchestration tools and so on. I specifically want to be able to 1. Have a non-cli interface for management, and especially not have to write a bunch of YML files myself, and 2. Be able to specify exactly which machine in the cluster a specific container ends up on. Something like Openshift Origin seems to be the way to go, but is there another option worth thinking about?
- jacques_chester 9y ago
  OpenShift uses Kubernetes, which allows that degree of precision. I'm not familiar with its GUI though. I believe DCOS has a really nice interface.
  - gnur 9y ago
    The interface of DCOS really is excellent, the default project for kubernetes doesn't even come close, especially the 1.9 release of DCOS polished everything up. It does have its quirks though. Which does force you to use the json editor sometimes. But the openshift UI is also very nice, I've been using it through the CDK with minishift and it's an excellent interface for kubernetes/openshift.
    - smarterclayton 9y ago
      Even the OpenShift UI forces you to drop into a yaml editor every now and then. Kubernetes is too powerful to really represent in any UI without a ton of work - which is really the central decision when adopting Kube. Do you want the power available if you need it? Or do you want something simpler that might constrain a future choice? Of note, there's a structured web editor for any API resource in Kube, OpenShift, or extension being prototyped now that I'm hoping helps bridge that gap. Also, check out the latest nightlies or 3.6.0-alpha.2 for a bunch of massive improvements to the overview - I think it's easily the biggest enhancement over the last few years.
      - 9y ago
jimaek 9y ago
I am personally using Rancher with Docker to deploy my apps. I like the web-ui and 1.6.1 is stable to use in production.
- jondubois 9y ago
  Yeah, Rancher is great with Kubernetes too - It sets it up for you on your favourite infrastructure provider and launches instances for you.
- drdaeman 9y ago
  Is it? 1.1.x looked nice when I had evaluated it (especially the Web UI), but was a real bugs nest in the long run. Had issues with almost every component. Usually found matching bugs that were already filed and had the workarounds described, but it left the bad aftertaste. Finally, DNS component had nearly malfunctioned and I've switched to Compose with some WeaveNet and semi-manual (re)scheduling. Lost some useful functionality (and the UI) but at least the switch fixed things and it works. Wanted to use Swarm for fully automated scheduling without a DIY external watchdog system, but its networking is extremely limited at the moment (and I haven't groked how to use it with Weave). Kubernetes looks nice, but the amount of YAML I'll have to write scares me away. And I'm not sure I trust all that "we do magic" stuff anymore. The more complicated system is, the harder it's to figure out what to do when it starts to fail.
  - daniel_levine 9y ago
    There's now http://ksonnet.heptio.com http://ksonnet.heptio.com to make it much easier to get started with k8s and eliminate the need to write YAML
richardknop 9y ago
Couple additional PaaS that could be on the list as well: cloudfoundry, deus, tsuru, openshift (although that's mostly covered by kubernetes).
eliq 9y ago
So, the way I deploy code is to SSH into my server, clone my repo from GitHub, setup the db and start the relevant systemd services. If I need to install updates it's a simple git pull and restart the services. I can use something like ansible for configuration management to reduce the manual SSH part. For someone like me, what benefit do these PaaS offerings provide?
- jacques_chester 9y ago
  If you have something that works and you don't need to manage hundreds or thousands of applications in a uniform way, I'd stay with what you trust. Edit: Though as PaulRobinson points out, before thinking about a PaaS you ought to think about CI/CD. I mean I think Cloud Foundry is the bee's dancing knees, but for a single app it's probably massive overkill.
- PaulRobinson 9y ago
  Automated repeatability, automated rollbacks, self-documenting infrastructure and the ability to deploy with a single command or automatically on a successful test build. That means you can merge to master and know the build will just get released when the tests pass without having to do any of that work. Further, as the needs of your infrastructure or DB develop (you are hoping for growth, right?), your deployment stays automated, you can add more complexity to your setup with little additional workload, and you can hire other developers who can safely ship to production without having to be shown any of your method.
  - Silhouette 9y ago
    The question always seems to be how much extra overhead you incur setting these things up in the first place for a relatively small business or side project. I've been curious about these kinds of automation tools for as long as they've been around, but they always look like more trouble than they're worth for any of the projects and deployment strategies I'm involved with at that smaller end of the scale. Maybe they work better if you're doing a relatively standard DB + API + front-end kind of setup, which as it happens nothing I work on actually is. Or maybe they just don't really pay for themselves until you're working at a scale where a simple copy/clone step and everyday scripting tools aren't sufficient to run everything routine anyway?
jdwyah 9y ago
Surprised not to see an ECS shoutout yet. I'm curious what the rap is on that that makes people walk right on past the AWS default option. I've been really happy with ECS. Tons works out of the box. Last piece for me was figuring out a good way to do cron, but I just figured that out. http://blog.ratelim.it/blog/cron-jobs-on-amazon-ecs-with-datapipeline http://blog.ratelim.it/blog/cron-jobs-on-amazon-ecs-with-dat...
- Veratyr 9y ago
  All the options in the article can be self-hosted or run anywhere you like, ECS is proprietary and Amazon only, which is likely why it was excluded. Heroku wasn't in the comparison either.
- mwarkentin 9y ago
  Glad you figured it out, but they just announced native scheduled tasks: http://docs.aws.amazon.com/AmazonECS/latest/developerguide/scheduled_tasks.html http://docs.aws.amazon.com/AmazonECS/latest/developerguide/s...
  - jdwyah 9y ago
    Hah! Le sigh. That's hilarious. Thanks for the pointer, can't believe I missed that.
sandGorgon 9y ago
Docker Swarm is the simplest setup for a fairly sophisticated PAAS. It works of a docker compose file that will carry port binding, network configuration,etc. You just run "docker stack deploy". Adding multiple nodes to a cluster is a one line command.
- pryelluw 9y ago
  Do you mind sharing more from the standpoint of security? What can a user expect to maintain, do, or setup to be secure (as possible)?
  - sandGorgon 9y ago
    docker swarm has TLS overlay network support built in. So it is secure by construction. Docker Secrets is built-in (https://docs.docker.com/engine/swarm/secrets/ https://docs.docker.com/engine/swarm/secrets/) and is pretty cool. Not sure what else are you looking at
    - pryelluw 9y ago
      Thanks. Thats a solid start. :)
- y4mi 9y ago
  i think the article is correct in its presentation though. while the docker swarm service looks very promising and will probably proof itself to be the best for small to medium and maybe even big corps, its most definitely not battle tested yet, as its just too new. you actually need to add unstable repos on most distris to use the 'stack deploy' option. quite a few are still <12
  - sandGorgon 9y ago
    > you actually need to add unstable repos on most distris to use the 'stack deploy' option. quite a few are still <12 Same with k8s - package revisions are at the mercy of distro maintainers. However, I have found that docker is far more updated that k8s. BTW Docker Swarm is fairly well tested - but I think it is called Docker Enterprise Edition in its well tested form. There might be edge cases where k8s is better than docker swarm.. however I personally believe in 90% of startuppy deployment usecases are worth not fighting ingresses for.
neocodesoftware 9y ago
help me imagine using flynn in production - these seeem like deal breakers upgrade flynn requires back up and restore backups are full backups only no incremental recommended filesystem is s3 azure or google since postgres is not reliable
- aisofteng 9y ago
  >postgres is not reliable That will require a pretty strong argument.
dabeeeenster 9y ago
We used Flynn over the last 12 months (tech agency, lots of fairly small projects) but gave it up in favour of Dokku. Every single one of our nodes eventually died, and we were unable to recover them. They chewed up disk space continuously and eventually ran out of disk and then were not recoverable. Other times they just died and would not restart all the required services. This was not even as part of a cluster; just single nodes. We raised issues and messaged on IRC but nothing happened. We really wanted to like it, but that was our experience. There's a lot of magic going on behind the scenes, which makes it really hard to even start to try and resuscitate a dead node. Sorry Flynn! We moved to Dokku and are really happy with it. It's not H/A but it's mega simple and it works really well. It's basically just Docker, buildpacks and the networking to wire everything together. The plugins also mean it's more useful than Flynn - if you need something like ElasticSearch you just install the plugin. Ditto LetsEncrypt etc etc.
likelynew 9y ago
Why is upvoted so much. This just touches the surface. Although, I am not very related to PaaS, I know much more for the three of the methods listed. This even oversimplifies so many things, to the point of getting it wrong. > WHEN TO CHOOSE DOKKU: for hobby and side projects that do not require high availability Surely, not correct. Don't make your decision on this line. It's not made for fault tolerance, but anyone who has doubts regarding which to use is very likely to use a single region of single cloud provider. I think most companies(even large one) do that. > Big caveat (for Kubernetes): it is very hard to setup I really don't think he did that. It's really easy for AWS at least. See https://kubernetes.io/docs/getting-started-guides/aws/ https://kubernetes.io/docs/getting-started-guides/aws/ > WHEN TO CHOOSE DOCKER SWARM: in my opinion, this has a very strong potential to be a contender against current solutions mentioned above but as of right now, it is still evolving. AFAIK, it has been extensively tested and is being used live. I am not sure, but the amount of presence it has, it's hard to believe that it is just evolving and not to be used.
- deforciant 9y ago
  Swarm is used but I have heard many companies migrating from swarm to k8s and openshift. Swarm is just unstable, network connectivity is flaky, not sure how can you run it in prod (maybe you can't?). As for k8s - would recommend it for anything from hobby projects to large prod deployment. Easy to set up anywhere. This article is indeed very shallow and clearly author hasn't bothered to do some research.
  - likelynew 9y ago
    > This article is indeed very shallow and clearly author hasn't bothered to do some research. Well, yeah, but the thing concerning here is HN upvoted it to the top. I have nothing against the author. > As for k8s - would recommend it for anything from hobby projects to large prod deployment That's what I am saying. IMO, the reputation that it has to be used only if somewhat wanted to manage very large number of servers is a little misleading. I think Kubernetes can feel very intimidating at the start but it's not that hard.
meddlepal 9y ago
Seriously why is this anywhere near the top of the page? It's basically two to three sentences about each and barely scratches the surface of each technology.
johnsmith21006 9y ago
You want to invest into what will win including ones own skills. K8 is the winner, IMO. Writing is already on the wall.
CrankyBear 9y ago
So much is wrong here it's hard to know where to begin. First, PaaS is not container orchestration. Second, this is extremely superficial. Third, some things are flat out wrong. For example, Docker Swarm has been depreciated. Swarm's capability is baked into Docker as of 1.12. For a better overview see: https://insights.hpe.com/articles/the-basics-explaining-kubernetes-mesosphere-and-docker-swarm-1702.html https://insights.hpe.com/articles/the-basics-explaining-kube...
alixaxel 9y ago
Flynn looks very interesting nowadays (it's been a while since I last checked it), I specially like the fact that they are trying to handle stateful (databases for instance) environments too. But after reading through the website and the Go code, I'm still a bit lost regarding what kind of guarantees/architecture this implies. Has anyone had any experience deploying database appliances with this?
tylerflint 9y ago
Some of those aren't PaaS, but container orchestration frameworks. If you're reading this list of comparisons out of genuine interest, I would suggest also looking into Nanobox: https://nanobox.io https://nanobox.io
technologyvault 9y ago
One of the engineers from my company, Nanobox (a micro-PaaS), compares a few of these tools and others in context of how well they cover the development to production workflow: https://content.nanobox.io/development-to-production-workflow-coverage-solution-comparison/ https://content.nanobox.io/development-to-production-workflo... Tools included on this chart include: - Heroku - Kubernetes - Flynn - Nanobox - Openshift - Dokku - Rancher - Convox - Mesosphere - Hyper.sh

128 points by wilsonfiifi 9y ago

SubiculumCode 9y ago

Well one is a Russian operative. ;)

medecau 9y ago
Sad.
WrtCdEvrydy 9y ago
I think Flynn should rename, just saying.

jacques_chester 9y ago

A first note, this is not like-for-like. Dokku, Flynn and Deis fit the PaaS spot more meaningfully. Kubernetes and Swarm are sometimes called "Container as a Service" -- you still need a bunch of work to select, install and configure features that PaaS users take for granted. Missing from the list: Cloud Foundry. And OpenShift! Give Red Hat some respect here for making Kubernetes into a platform. And DCOS, which I think got its thunder stolen by Kubernetes. But I mostly know Cloud Foundry, because it's my day job to keep making it better. It's the most mature out of all of these, has been soak tested to 250,000 running applications[0], can be deployed to any major IaaS or bare metal, comes with routing, logging, service injection, healing, no-downtime upgrading and I forget what other headlines I usually pick out of the several hundred features it now includes. The Cloud Foundry Foundation includes Pivotal (my employer), IBM, SAP, Google, DellEMC, VMWare, Cisco, Suse and those are just the fancy tech names. The reason you don't hear about it is that we and our partners have focused on competing for enterprise sales. It's not how you get publicity on HN, but it does mean that PivotalCF -- our commercial distribution -- has the fastest-growing sales of an opensource-based product in history. And sales are still zooming up and to the right. The nice thing is that we and other partners get very broad, specific feedback from customers who are already at massive scale and who expect utter, non-negotiable reliability. We run a public service ourselves (Pivotal Web Services), SAP have HANA Cloud, IBM runs BlueMix. We and other Cloud Foundry contributors have had the benefit of that dogfooding and feedback for longer than any other container-based platform in existence. And it turns out, there are so many things that can go wrong. So many. It's crazy. Lastly, Cloud Foundry teams have massive investments in project automation. This gives us two capabilities: one is that we can roll out complete rebuilds of the whole platform within hours of an upstream CVE patch. Users can then apply these fixes to their platform live, in-place, without any running apps noticing that it has occurred. BOSH[1] will roll out the deployment with canaries, and Diego[2] will relaunch containers as they are reaped during upgrade. The second capability is that we are confident in making very deep, very aggressive changes if it proves necessary, because we have tests upon tests upon mountains of more tests. And again: nobody notices, except that their platform gets faster or becomes reliable under even more extreme circumstances. If I sound like an utterly biased fan, it's because I am an utterly biased fan. I've watched this thing evolve up-close for years. It is amazing. We build installable superpowers. Disclosure: If it's not obvious, I work for Pivotal on Cloud Foundry. [0] https://content.pivotal.io/blog/250k-containers-in-production-a-real-test-for-the-real-world https://content.pivotal.io/blog/250k-containers-in-productio... [1] http://bosh.io/ http://bosh.io/ [2] https://github.com/cloudfoundry/diego-design-notes https://github.com/cloudfoundry/diego-design-notes Minor edits for style.

tyingq 9y ago
Mesos should probably be on the list as well.
- jacques_chester 9y ago
  Absolutely. I made a side reference through DCOS, which is the PaaS-packaged Mesos.
Veratyr 9y ago
Is it still the case that CF requires a ton of overhead to get running? Last I checked there was no easy way to set up CF without: - Running on a cloud - Spinning up ~8 different servers, each with ~2GB of memory iirc Kinda a lot of overhead if you're just running a few dev environments like I was.
- jacques_chester 9y ago
  I get this question a lot. PCFDev[0] if you just want a dev environment to tinker with. You can also tinker with cflocal[1] (unsupported) or BOSH-lite[2] (somewhat-supported) if you're looking to practice ops as well. A lot of Cloud Foundry teams do integration testing with BOSH-lite on large single VMs, because it essentially presents BOSH with a "VM" interface that spins up nested containers instead. You can, in theory, deploy however few or however many real VMs, or bare metal servers, as you wish, by editing a BOSH manifest. By default the cf-deployment[3] manifest uses something like 23 VMs of varying sizes. That's because the default manifest is intended for production use with multi-AZ HA as the minimum level of reliability. If you don't need that, one of the alternatives I noted will get you what you want. [0] https://pivotal.io/pcf-dev https://pivotal.io/pcf-dev [1] https://github.com/sclevine/cflocal https://github.com/sclevine/cflocal [2] https://github.com/cloudfoundry/bosh-lite https://github.com/cloudfoundry/bosh-lite [3] https://github.com/cloudfoundry/cf-deployment https://github.com/cloudfoundry/cf-deployment
smashed 9y ago
But to be fair, Pivotal Cloud Foundry is so expensive it's not even in the same league as the others and I can totally understand why the article just ignored it altogether.

notamy 9y ago

Somewhat-related question: I have a cluster of ~6 machines that I'm using to play with containers and container orchestration tools and so on. I specifically want to be able to 1. Have a non-cli interface for management, and especially not have to write a bunch of YML files myself, and 2. Be able to specify exactly which machine in the cluster a specific container ends up on. Something like Openshift Origin seems to be the way to go, but is there another option worth thinking about?

jacques_chester 9y ago
OpenShift uses Kubernetes, which allows that degree of precision. I'm not familiar with its GUI though. I believe DCOS has a really nice interface.
- gnur 9y ago
  The interface of DCOS really is excellent, the default project for kubernetes doesn't even come close, especially the 1.9 release of DCOS polished everything up. It does have its quirks though. Which does force you to use the json editor sometimes. But the openshift UI is also very nice, I've been using it through the CDK with minishift and it's an excellent interface for kubernetes/openshift.
  - smarterclayton 9y ago
    Even the OpenShift UI forces you to drop into a yaml editor every now and then. Kubernetes is too powerful to really represent in any UI without a ton of work - which is really the central decision when adopting Kube. Do you want the power available if you need it? Or do you want something simpler that might constrain a future choice? Of note, there's a structured web editor for any API resource in Kube, OpenShift, or extension being prototyped now that I'm hoping helps bridge that gap. Also, check out the latest nightlies or 3.6.0-alpha.2 for a bunch of massive improvements to the overview - I think it's easily the biggest enhancement over the last few years.
    - 9y ago

jimaek 9y ago

I am personally using Rancher with Docker to deploy my apps. I like the web-ui and 1.6.1 is stable to use in production.

jondubois 9y ago
Yeah, Rancher is great with Kubernetes too - It sets it up for you on your favourite infrastructure provider and launches instances for you.
drdaeman 9y ago
Is it? 1.1.x looked nice when I had evaluated it (especially the Web UI), but was a real bugs nest in the long run. Had issues with almost every component. Usually found matching bugs that were already filed and had the workarounds described, but it left the bad aftertaste. Finally, DNS component had nearly malfunctioned and I've switched to Compose with some WeaveNet and semi-manual (re)scheduling. Lost some useful functionality (and the UI) but at least the switch fixed things and it works. Wanted to use Swarm for fully automated scheduling without a DIY external watchdog system, but its networking is extremely limited at the moment (and I haven't groked how to use it with Weave). Kubernetes looks nice, but the amount of YAML I'll have to write scares me away. And I'm not sure I trust all that "we do magic" stuff anymore. The more complicated system is, the harder it's to figure out what to do when it starts to fail.
- daniel_levine 9y ago
  There's now http://ksonnet.heptio.com http://ksonnet.heptio.com to make it much easier to get started with k8s and eliminate the need to write YAML

richardknop 9y ago

Couple additional PaaS that could be on the list as well: cloudfoundry, deus, tsuru, openshift (although that's mostly covered by kubernetes).

eliq 9y ago

So, the way I deploy code is to SSH into my server, clone my repo from GitHub, setup the db and start the relevant systemd services. If I need to install updates it's a simple git pull and restart the services. I can use something like ansible for configuration management to reduce the manual SSH part. For someone like me, what benefit do these PaaS offerings provide?

jacques_chester 9y ago
If you have something that works and you don't need to manage hundreds or thousands of applications in a uniform way, I'd stay with what you trust. Edit: Though as PaulRobinson points out, before thinking about a PaaS you ought to think about CI/CD. I mean I think Cloud Foundry is the bee's dancing knees, but for a single app it's probably massive overkill.
PaulRobinson 9y ago
Automated repeatability, automated rollbacks, self-documenting infrastructure and the ability to deploy with a single command or automatically on a successful test build. That means you can merge to master and know the build will just get released when the tests pass without having to do any of that work. Further, as the needs of your infrastructure or DB develop (you are hoping for growth, right?), your deployment stays automated, you can add more complexity to your setup with little additional workload, and you can hire other developers who can safely ship to production without having to be shown any of your method.
- Silhouette 9y ago
  The question always seems to be how much extra overhead you incur setting these things up in the first place for a relatively small business or side project. I've been curious about these kinds of automation tools for as long as they've been around, but they always look like more trouble than they're worth for any of the projects and deployment strategies I'm involved with at that smaller end of the scale. Maybe they work better if you're doing a relatively standard DB + API + front-end kind of setup, which as it happens nothing I work on actually is. Or maybe they just don't really pay for themselves until you're working at a scale where a simple copy/clone step and everyday scripting tools aren't sufficient to run everything routine anyway?

jdwyah 9y ago

Surprised not to see an ECS shoutout yet. I'm curious what the rap is on that that makes people walk right on past the AWS default option. I've been really happy with ECS. Tons works out of the box. Last piece for me was figuring out a good way to do cron, but I just figured that out. http://blog.ratelim.it/blog/cron-jobs-on-amazon-ecs-with-datapipeline http://blog.ratelim.it/blog/cron-jobs-on-amazon-ecs-with-dat...

Veratyr 9y ago
All the options in the article can be self-hosted or run anywhere you like, ECS is proprietary and Amazon only, which is likely why it was excluded. Heroku wasn't in the comparison either.
mwarkentin 9y ago
Glad you figured it out, but they just announced native scheduled tasks: http://docs.aws.amazon.com/AmazonECS/latest/developerguide/scheduled_tasks.html http://docs.aws.amazon.com/AmazonECS/latest/developerguide/s...
- jdwyah 9y ago
  Hah! Le sigh. That's hilarious. Thanks for the pointer, can't believe I missed that.

sandGorgon 9y ago

Docker Swarm is the simplest setup for a fairly sophisticated PAAS. It works of a docker compose file that will carry port binding, network configuration,etc. You just run "docker stack deploy". Adding multiple nodes to a cluster is a one line command.

pryelluw 9y ago
Do you mind sharing more from the standpoint of security? What can a user expect to maintain, do, or setup to be secure (as possible)?
- sandGorgon 9y ago
  docker swarm has TLS overlay network support built in. So it is secure by construction. Docker Secrets is built-in (https://docs.docker.com/engine/swarm/secrets/ https://docs.docker.com/engine/swarm/secrets/) and is pretty cool. Not sure what else are you looking at
  - pryelluw 9y ago
    Thanks. Thats a solid start. :)
y4mi 9y ago
i think the article is correct in its presentation though. while the docker swarm service looks very promising and will probably proof itself to be the best for small to medium and maybe even big corps, its most definitely not battle tested yet, as its just too new. you actually need to add unstable repos on most distris to use the 'stack deploy' option. quite a few are still <12
- sandGorgon 9y ago
  > you actually need to add unstable repos on most distris to use the 'stack deploy' option. quite a few are still <12 Same with k8s - package revisions are at the mercy of distro maintainers. However, I have found that docker is far more updated that k8s. BTW Docker Swarm is fairly well tested - but I think it is called Docker Enterprise Edition in its well tested form. There might be edge cases where k8s is better than docker swarm.. however I personally believe in 90% of startuppy deployment usecases are worth not fighting ingresses for.

neocodesoftware 9y ago

help me imagine using flynn in production - these seeem like deal breakers upgrade flynn requires back up and restore backups are full backups only no incremental recommended filesystem is s3 azure or google since postgres is not reliable

aisofteng 9y ago
>postgres is not reliable That will require a pretty strong argument.

dabeeeenster 9y ago

We used Flynn over the last 12 months (tech agency, lots of fairly small projects) but gave it up in favour of Dokku. Every single one of our nodes eventually died, and we were unable to recover them. They chewed up disk space continuously and eventually ran out of disk and then were not recoverable. Other times they just died and would not restart all the required services. This was not even as part of a cluster; just single nodes. We raised issues and messaged on IRC but nothing happened. We really wanted to like it, but that was our experience. There's a lot of magic going on behind the scenes, which makes it really hard to even start to try and resuscitate a dead node. Sorry Flynn! We moved to Dokku and are really happy with it. It's not H/A but it's mega simple and it works really well. It's basically just Docker, buildpacks and the networking to wire everything together. The plugins also mean it's more useful than Flynn - if you need something like ElasticSearch you just install the plugin. Ditto LetsEncrypt etc etc.

likelynew 9y ago

Why is upvoted so much. This just touches the surface. Although, I am not very related to PaaS, I know much more for the three of the methods listed. This even oversimplifies so many things, to the point of getting it wrong. > WHEN TO CHOOSE DOKKU: for hobby and side projects that do not require high availability Surely, not correct. Don't make your decision on this line. It's not made for fault tolerance, but anyone who has doubts regarding which to use is very likely to use a single region of single cloud provider. I think most companies(even large one) do that. > Big caveat (for Kubernetes): it is very hard to setup I really don't think he did that. It's really easy for AWS at least. See https://kubernetes.io/docs/getting-started-guides/aws/ https://kubernetes.io/docs/getting-started-guides/aws/ > WHEN TO CHOOSE DOCKER SWARM: in my opinion, this has a very strong potential to be a contender against current solutions mentioned above but as of right now, it is still evolving. AFAIK, it has been extensively tested and is being used live. I am not sure, but the amount of presence it has, it's hard to believe that it is just evolving and not to be used.

deforciant 9y ago
Swarm is used but I have heard many companies migrating from swarm to k8s and openshift. Swarm is just unstable, network connectivity is flaky, not sure how can you run it in prod (maybe you can't?). As for k8s - would recommend it for anything from hobby projects to large prod deployment. Easy to set up anywhere. This article is indeed very shallow and clearly author hasn't bothered to do some research.
- likelynew 9y ago
  > This article is indeed very shallow and clearly author hasn't bothered to do some research. Well, yeah, but the thing concerning here is HN upvoted it to the top. I have nothing against the author. > As for k8s - would recommend it for anything from hobby projects to large prod deployment That's what I am saying. IMO, the reputation that it has to be used only if somewhat wanted to manage very large number of servers is a little misleading. I think Kubernetes can feel very intimidating at the start but it's not that hard.

meddlepal 9y ago

Seriously why is this anywhere near the top of the page? It's basically two to three sentences about each and barely scratches the surface of each technology.

johnsmith21006 9y ago

You want to invest into what will win including ones own skills. K8 is the winner, IMO. Writing is already on the wall.

CrankyBear 9y ago

So much is wrong here it's hard to know where to begin. First, PaaS is not container orchestration. Second, this is extremely superficial. Third, some things are flat out wrong. For example, Docker Swarm has been depreciated. Swarm's capability is baked into Docker as of 1.12. For a better overview see: https://insights.hpe.com/articles/the-basics-explaining-kubernetes-mesosphere-and-docker-swarm-1702.html https://insights.hpe.com/articles/the-basics-explaining-kube...

alixaxel 9y ago

Flynn looks very interesting nowadays (it's been a while since I last checked it), I specially like the fact that they are trying to handle stateful (databases for instance) environments too. But after reading through the website and the Go code, I'm still a bit lost regarding what kind of guarantees/architecture this implies. Has anyone had any experience deploying database appliances with this?

tylerflint 9y ago

Some of those aren't PaaS, but container orchestration frameworks. If you're reading this list of comparisons out of genuine interest, I would suggest also looking into Nanobox: https://nanobox.io https://nanobox.io

technologyvault 9y ago

One of the engineers from my company, Nanobox (a micro-PaaS), compares a few of these tools and others in context of how well they cover the development to production workflow: https://content.nanobox.io/development-to-production-workflow-coverage-solution-comparison/ https://content.nanobox.io/development-to-production-workflo... Tools included on this chart include: - Heroku - Kubernetes - Flynn - Nanobox - Openshift - Dokku - Rancher - Convox - Mesosphere - Hyper.sh