[tannhaeuser]

K8s only gives you theoretical leverage in negotiations with "cloud providers". As long as you can't reasonably run it on your own hardware (because it's simply way too complex and you'll be having trouble finding experts, even at obscene salaries) you won't be realistically able to migrate to another "cloud provider" either.

It's an old trick from the playbook of ERP software vendors: make your software absurdly configurable so that all the meat is in the configuration.

Worse (and I know this isn't popular and will hurt) k8s for all intents and purposes just runs Docker images which are just pointless wrappers that don't add anything but point-of-failures and vulnerabilities.

[pests]

A container is just a linux process with special restrictions. Its not just a pointless wrapper.

[firebacon]

Don't think the term "container" is really well-defined.

The "container" that docker and others implement is actually a collection of different kernel namespacing features. I assume the one you are referring to are cgroups. I think a better description would be that each process in a linux system is part of (many) cgroup hierarchies. And you can have more than one process in each of the groups.

I think what parent meant is that you can actually get all of these really nice isolation features for your service without using "Docker". It is trivial to enable them using linux command line utils, or use something like systemd which can also do it for you.

[tannhaeuser]

Docker and cgroups/namespaces really only isolates you from mixed shared libraries situations, by essentially pinning your lib in the Docker image. That is, by ignoring the problem of stale/insecure shared libs, which is the entire point of using shared libs in the first place.

Docker doesn't isolate you from resource exhaustion (out of memory or files, infinite loops), from incompatibilities of the host kernel and Docker version bumps (so your shiny image isn't guaranteed to work on newer kernels and Docker versions), and makes it impossible to use host user identities and permissions. Thus projects tend to avoid plain regular file access, using databases and block devices and what not as workarounds.

IMHO Docker is an anti-pattern to "solve" an incidental problem of your own making.

[pests]

I meant all the namespacing features.

My main argument was against a container being something "more" than just a standard linux process in the sense that "more" is extra software that wouldn't otherwise be ran.

[pests]

Of course Docker is just the popular brand name for those isolation features and 'image' 'container' and all related terminology exist independently without Docker

[yoz-y]

Docker is also a cross platform command line tool that helps to manage said images and automate a lot of work that would otherwise need to be done. For me it is kind of like Dropbox: yes you can piece it together yourself, but using it is very convenient and you can spend your time elsewhere.

[pests]

In my opinion its on its way out. CNCF and k8s has already basically replaced it with the CRI initiative and containerd[0][1]. Runc, rkt, and a multitude of other tools run containers. img, ocra-build, and others can build them.

[0] I realize this is from Docker as well but I feel it supports my point that Docker, Inc themselves are shedding baggage to still stay relevant.

[1] https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-...

[yoz-y]

I'll have to look into it thanks. I'd like to not end up requiring different tools to run the same container on Windows/Mac and Linux. Currently my workflow is easy, I create my Dockerfiles on a mac, do all of the building and testing, and then just tell devs on Windows to pull a repo and do a docker-compose --build up. I hope in the future this will not grow into tool hunting.