[koz_]

I think Google's interests are aligned with developer interests here. The main benefit to GCP that k8s success brings is that migration between clouds becomes easier (e.g. moving from EKS to GKE would presumably be easier than moving from Elastic Beanstalk to App Engine). Less lock-in benefits everyone except the current market leader.

[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-...

[sporkland]

The stateless services (and cloud native stateful) become portable, the new lock-ins are their value added data-stores (spanner, aurora, cosmos).

[firebacon]

Well I agree that the interests are aligned insofar as Google is trying do dethrone AWS which currently has a near-monopoly on cloud. But I'd still rather live in a world where the compute fabric of the internet is not centralized in the hand of a few corporations. I'd much rather get paid a salary from money that would have otherwise gone to a monthly *-Cloud payment. And I believe that in a lot of cases, the non-Cloud version of the product would actually be a better, cheaper, more reliable solution. But that will become a harder and harder sell the more successful the marketing from cloud providers is.