If by "the Angular of orchestration systems" (I'm going to assume Angular 1 because Angular 2 gives me headaches still) you mean that it's really easy to do what should be easy, and feasible to accomplish really complex things, then I would agree. But I don't think that's what you meant.

As far as security, that's now purely a property of the way you deploy it. Secrets can be encrypted (feature in alpha), RBAC is fully supported, TSL client certs are preferred for AuthN, and HTTPS is supported across the API endpoints. I'm not sure what more you could ask for on the security side.

I don't know that Google says they're using K8s internally, either. It's always been sold by Google as a ground-up rewrite of what the authors wish Borg would have been. Not only that, but it's supported (developed) by dozens of small companies, as well as Google, Red Hat, and an increasing number of large companies interested in its growth.

Finally, it's governed by the Linux Foundation. If there's another org that can help scale and properly govern one of the most popular modern OSS projects, I'm drawing a blank.

Well for one Swarm was released a year ago and Kubernetes went 1.0 two years ago, so there has just been more time for people to get familiar with k8s. I myself dug into kube before Swarm arrived and have put off getting into Swarm because constant framework hopping kind of defeats the purpose of getting familiar with a new framework in the first place.

While I agree to some extent re complexity, I'd be interested as to what you're referring to when you say kubernetes is insecure.

Framework hopping? With your knowledge in k8s you should be able to learn Docker Swarm and getting a swarm deployed in less than 60 minutes.

Sure, I could definitely get a swarm set up quickly and run something trivial on it, but then I'll be back to the docs for secrets, stateful containers, volume mounts, cert management, instrumentation, health checks, load balancing etc.

My point about 'framework hopping' was that I try to get some value out of the time spent digging into a new tool/library/framework, rather than trying to use something new for each new project. Knowing the pitfalls, useful configs, edge cases, best plugins and so forth goes a long way towards being able to focus on what you're actually building. I'm not against early adoption and I am always learning new tools, but I do try to leverage the ones I have deep knowledge of.

> I'll be back to the docs for secrets, stateful containers, volume mounts, cert management, instrumentation, health checks, load balancing etc.

Almost all of your points are on one page in the doc (just google 'docker-compose file') which is read and used in 5 minutes. Btw, load balancing is the default, no real config required (still you can but the defaults are sensible). Anyway, you are usually 5x to 10x faster than with setting up an k8s cluster. This should be a good enough reason to give it a try and to make your own picture of Swarm.

It is up to you but I think you have a wrong picture of Swarm. Something huge, conplicated and intimidating like k8s. Something you should spend your weekend and the week after to learn. This is wrong.

Just see is as another CLI tool which you can grasp in the next hour (instead of surfing the web).

Borg has so many knobs that Kubernetes still lacks (or always will, by design), but there are already unspecified Google projects running on Kubernetes.

So well framed! Docker Swarm is just great. Easy, batteries included (load balancer, secrets, etc.) and still people worhship Kubernetes.