Comment by edejong | Hacker News Reader

Comment by edejong | Hacker News Reader

Parent Full thread

Yes, we've all used that abstraction. And it is a lousy one. For starters, the novice interpretation of a PC are peripherals (mouse, screen, keyboard, wifi) with a GUI and then down from there. Your abstraction starts without a screen, without a terminal even.

It's a bad interpretation because the abstraction level is arbitrary. GUI applications? No. Terminal, yes, but we need to automate. Wifi? No, we virtualize the network. DNS? Depends, in k8s it is used for service discovery. Tooling? Package manager: yes. Network Center? No. Firewalls? I don't think so.

So, what constitutes a 'fresh linux install'? Why are there different distros (archlinux, ubuntu, alpine)?

What are the contracts for such a Docker image? Should it be secured? How is input and output arranged on the Docker image? What if I want to use a smarter way for logging (using UDP packets to a discoverable logging provider), can I tell all my Docker images to start using that?

How about monitoring and reliability? What constitutes a failed docker image? How do I detect it?

An abstraction is only good when it covers 99% of the underlying complexity. This abstraction is so leaky, it is more of a burden. Especially to beginners, who now are tasked with understanding Docker and understanding the limits of the abstraction.

Good technologies are explainable through solid abstractions. They are not 'leaky'. For me, Docker and k8s are so complicated because they are based on leaky abstractions and not hiding the underlying complexity sufficiently.

>For me, Docker and k8s are so complicated because they are based on leaky abstractions and not hiding the underlying complexity sufficiently.

Bingo. Ive worked with so many Docker houses of cards slopped together that like to pull the latest docker images regularly in their docker compose and, surprise, something changes in that images structure and assumptions they were leveraging that breaks the rest of the application. As the number of containers increase, the failure rate also increases. You can lock in versions but for trendy users, "then why are you using docker, bro!?"

Containers aren't bad, they're actually great and useful technology, but using them for rapid development just to hope you're going to manage complexity often only makes things worse. Theyre far too often misused and abused than they are used for sane development purposes.

The reason for this is because Docker still doesn't have a lockfile like every (other?) dependency manager ever. Pinning a hash dooms you to use that hash forever, because there's no easy way to update under controlled circumstances.

Well it depends on your audience, in my case it is sufficient but I agree if one really wants to learn this just makes you ask questions about horrible overkill, and then you have to explain layers and indeed, it is a rabbit hole, I agree.

Still, you understand it ones you can build on that. But tbh I agree that there are now students that lack basic sysadmin skills needed to understand docker images from the inside. That said, I don't understand Kubernetes very deeply, so we complement each other nicely.

> It's a bad interpretation because the abstraction level is arbitrary. GUI applications? No. Terminal, yes, but we need to automate. Wifi? No, we virtualize the network. DNS? Depends, in k8s it is used for service discovery. Tooling? Package manager: yes. Network Center? No. Firewalls? I don't think so.

You can absolutely run all of the above in Docker containers. Just because most don't doesn't mean you can't or shouldn't!

For a user who is not concerned with the difference between kernel and userland, I think the analogy is good enough. Just throw in that it has to be a Linux system and you can get away with explaning it the same way you would VMs, just being more lightweight and reuses some of the "base system".

Reply on news.ycombinator.com