Hi

I'm pretty sure many blog posts on internet will bring more details about this, but since this scene has moved a lot in 2017 and the answers in January 2017 were different than mid 2016 and are different today, here's my quick personal view on this.

First, it's interesting to "restrict" the comparison to Kubernetes (k8s) and swarm. If you're ready for some easy to get started solution but with some vendor lock-in, you can also include AWS ECS in your list. Then you also have many other solutions which might be worth looking at, if you have some specific requirements: Hashicorp's Nomad, and Rancher both came to mind.

Without further ado, and without knowing much more about the specific details of your project, my recommendation would be to go with Kubernetes. (See below for the rationale)

I try to do small comparison here by features family, trying to be generic, feel free to ask question for more details or items I might have overlooked.

Philosophy/concepts

Kubernetes is all about :

• being declarative
• abstracting the infrastructure from the code

To give more details, the declarative (rather than imperative) approach is all about telling Kubernetes what you want the cluster state to be, not what are the actions to perform. (But you still have a lot of control, and you can give him hints on how to perform actions if something has to be done). In the end, it's fully idempotent, and really nice to manage/review/audit. It makes the configuration very easy to read (and therefore maintain and debug)

About the abstraction, to give an example, you don't directly use a volume mount: you first create a k8s object to control a volume (a PersistentVolume object). But your container (the pod running your container in fact) does not use this PersistentVolume directly. You need an intermediate layer: the PersistentVolumeClaim, which is a way to ask for some storage (I want this size, ...) without having to deal directlly with the details of the actual storage technology. (The PersistentVolume config will change depending on your hosting solution: EBS, metal ... but the claim will be the same, so the concerns are clearly separated)

Finally the labels and tags k8s uses to search/filter/identify resources (containers, services, anything) are simple but powerful (different from Docker's images labels).

This has an impact on the learning curve, but the additional layers that k8s brings are really worth.

Feature set

For a common use case, both have very rich feature set and should meet your needs. That said, k8s momentum has gained so much traction than new features are coming at an incredible speed. (many different Function-as-a-service solutions, jobs, crons, ...), and the momentum is such that I expect k8s to be a clear winner soon.

Furthermore, k8s supports third party APIs. To try to give a high-level view, you can add any payload which register itself to your k8s api server in the control plane. Then other payloads can use these new resources you add through the same API and declarative approach. In the beginning, you probably won't write your own extension, but this mechanism lets you use many extension as if it was built-in the system. (In fact new features are introduced this way too). This let the kubernetes teams have different velocities for the core and still let people introduce new features at their own rate, with their own QA and requirements.

To sum it up, Kubernetes extension model is very well thought and has proven very useful, so that tons of specific-use-cases are addressed with features delivered as extensions, and you don't have to wait for the next k8s update to get this or that feature (schedules are independant)

Scalability

One of the most famous example is Pokemon Go which was running on Kubernetes in Google Cloud.

I don't have the numbers for Swarm butI think it scale in a decent fashion too. (but don't have any big names on the top of my head)

Without more details, I assume your project is medium-size enterprise grade stuff (ie a decent application, but not twitter or netflix). As with any technology, scale will come with challenges, but the core technology has been proven to work at this scale (which does not imply your network setup, or the thing you'll be doing in the cluster will work at scale)

Learning curve

From what I remember Swarm is not that complex if you have already some Docker (and compose) experience.

Kubernetes has definitely a bigger learning curve, since it introduces new concepts, with new terminology. But that learning curve is not steep. There are many books and online training available by now (I can point you to some if you will). And in my experience many of the k8s architectural decision make a lot of sense and feel natural, and everything fit well together in a consistent fashion, so that you quickly become familiar with it and the benefits very quickly become apparent.

Observability/Ease of maintenance

The ease of maintenance really depends on how you'll host your stuff. I never used Swarm in production so I won't comment on this part. For Kubernetes, if you use a managed kubernetes (like Google Cloud Platform GKE, and probably new AWS service which I haven't tested yet), it should be easy. We hosted on own cluster on ec2 (using terraform+kops for the cluster level operations). Long story short, most of it was not difficult because of extensive documentation and good tooling.

The painful part was logs cleaning. The usual tool in the k8s ecosystem is fluentd, which has its own learning curve, and is awesome and powerful, but having a clean and meaningful log aggregation running was much more work than I expected. Many other stories don't mention any issues with their logs, so I suspect I missed some nice stuff, or maybe it was because of various log formats weren't standard enough (and hence required these custom parsing steps).

Lifecycle, ease of updates to the cluster

I mention it because when you'll do your homeworks, this point is important and you'll need to check it. But then, no matter if it's swarm of k8s, it depends if you manage the cluster yourself or use a managed service. And if you manage it yourself, it will depend on your tooling. The 2 upgrades I did for k8s on aws with kops went correctly (not as smooth as expected, but was fine)

Payload lifecycle, ease of updating your apps

Since I only played a little bit it swarm it would be difficult to compare seriously, but k8s deployment objects are awesome, really. And if you use Helm as a package manager, (or even just to have templates with variables for your custom deployments), it becomes really super easy to get clean updates, with rolling update and health check to stop the rolling update if anything goes wrong, without breaking the previous/current version.

Community/support/ease of finding a solution|template|sample

Both are well known solutions and you should have good support and help. Since I mostly used k8s I can witness than the community is really huge and welcoming.

Security

From my point of view, Swarm was a little bit ahead last Fall with a really good secret management built-in (whereas k8s secrets were a joke and you had to add a secure solution if you want to be serious about your secrets). But his changes and the latest k8s updates had a good focus on security. Today, I'd consider them pairs. No clear winner here.

Other tools

I quickly mentioned Helm, the k8s package manager, kops, the aws operation tool built for production. But there are a huge number of open source serious projects for k8s, and big players like Microsoft are investing massively in building such projects (Brigade for instance is a Microsoft project on top of K8s which is worth having a look at to get an idea of the momentum).

Finally, I think it's also worth mentioning that, as of today, k8s is the only orchestration solution which is supported by all the big cloud providers as a service (you can obviously run k8s yourself on any hosts, but having all the big players supporting the same tech is worth being mentioned). Obviously Google was the first one, Azure also had a great support (they hired one of the 3 kubernetes' creators btw), and AWS recently (during last re:Invent) unveiled their own managed K8s service. Even Oracle Cloud is investing in k8s! All to say that betting on k8s is future-proof, and it's unlikely you'll be maintaining a project in a few years than no one else uses any longer.

Another +1 for Kubernetes, it's the more mature solution of the two. Google Cloud now has free Kubernetes out of the box, you only pay for the instances used.