[jeanvalmarc]

K8 specifically might not be the future, but containers are the past (chroot) present (docker) and future. Sure, containers are a hacky shell script... but a hacky shell script that always runs the same way. I put in my time chasing down RPM dependencies, and debugging weird behavior because of a different version of some shared library I previously didn't know existed. I think the arguments presented here are focusing on implementation details, while the higher level picture is that containers-the-concept save a TON of developer (and devops) time and pain.

[wahern]

> debugging weird behavior because of a different version of some shared library I previously didn't know existed.

Containers don't solve that issue, they simply allow you to ignore it. Not having to struggle to keep up with dependencies is the other side of the "containers are a security nightmare" coin.

I once returned to a company after several years of being away. Of course nobody had bothered to update the dependencies in the old build. When I was working to fix and update the old build somebody informed me that the problem had already been "solved" by another team, and directed to me speak with that team's lead.

They managed to get a new build with slightly updated dependencies working inside a container. They showed me the new build inside the Docker container. I asked some questions, they fumbled around to do a demonstration. It was clear that they hadn't solved anything. Instead of one problem, we now had two problems, as the new build environment couldn't be updated any easier than the old one.

But it simply can't be denied that productivity will usually win over X, where X is security, technical debt minimization, etc. And the improved productivity comes from unlinking dependencies, particularly process dependencies more than actual software dependencies.

I still prefer to package and bundle my projects, open source or internally, using RPM and Deb, or just the classic `make install prefix=/usr/local/foo` (support for the latter, with traditional GNU Make targets[1] and variables[2], makes building RPM and Deb infinitely easier). I know people will end up installing my projects into containers, but it's necessary all the same to ensure it's easier to keep those containers up-to-date.

[1] https://www.gnu.org/software/make/manual/html_node/Standard-...

[2] https://www.gnu.org/software/make/manual/html_node/Directory...

[asdfman123]

I haven't delved that deep into containerland but to me, it seems the main downside of using k8s is the complexity of set up and maintenance.

I'm not sure what's stopping people from developing tools to make the whole containerization process invisible to developers who don't need that much control. I'm sure stuff like that already exists/is being worked on, and I don't know why it shouldn't work.

[doctor_eval]

The thing is that k8s != containers. I’ve been using containers for years, but I don’t use k8s in any of my current projects (although that might change at some point)

That’s why I had to stop reading this article. They repeatedly conflate k8s with containers. From the users perspective, one is an extraordinarily complex orchestration framework, and the other is an incredibly simple packaging system.

[mtsr]

It’s a classic leaky abstraction, you will need that control at some point. And I say that as a heavy user of Docker and lighter user of Kubernetes.

[the_jeremy]

The article is arguing for super lightweight VMs that (I assume) would have the same build-once, run-the-same abilities as containers. Considering at my work we have hardware run VMs which contain clusters, I can certainly see the use case for removing one of these abstraction layers. I agree that containers were a step forward, and that the idea of run-the-same is a huge advancement, but I think we can get that feature from VMs just the same as containers, as soon as the infrastructure around developing unikernels / "nanoVMs" is as simple as Docker.