But the automation comes with the downside that we're forgetting how to build simple systems at all.
Put differently: Try explaining your docker compose setup to a beginner that only knows how to use normal desktop software.
It a mind numbing number of abstractions but one can understand the high level if one understands what an OS (or a computer) is.
It IS easier, but I agree it's much more complex under the hood. I don't think that has to have downsides. A human can only comprehend so much, we must build on the skill-sets of our fellow humans.
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.
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.
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".
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.
"Back in the days", you installed one package, edited one config, started the service, and it "just worked". Now i need to install a docker, type some docker install command, that pulls who-knows how many files, puts them in some 'weird' location, including the config file (which belongs in /etc), so instead of having a 2mb service, I now have a 1gb docker image sitting on my system, with a config file hidden somewhere, and I, the user, don't see any benefits, compared to just 'apt-get install'-ing something.
I mean, I understand, daling with dependencies are hard for some developers, but sometimes is just overkill.
The "whole computer" analogy works because I can drag it anywhere, plug it in and it runs exactly as intended. I can even copy it and run in 1000 times in parallel. When people complain about overkill I start talking about shared layers.
I understand it's easier to ship software as a "almost VM", but imagine everyone doing it... need a browser, download firefox docker image. Video player? docker image! Text editor? Docker image!
If firefox can make it 'just work', and whole (eg.) lamp-stack can 'just work', why not others?
Docker is a relatively new thing, and software worked for decades before that, without any real issues.
Sure, as long as a third party did all the hard work of integrating the package into the system first. Have to install something outside the repo? Clear your schedule...
Having them all in containers and a docker-compose.yml file makes it easier to quickly start an environment for a specific project.
Ofcourse like everything in life, it's a tradeoff, and in this case we're trading in diskspace and some overhead for ease of use and portability.
For me, it frequently didn't. Sure, nginx will work out of the box, but I've had some difficult Apache installs, and less mature software? Often a dependency/configuration nightmare, and then, sometimes, it still would die with an opaque error message. And then something breaks and getting to a clean slate can be challenging.
That's one of the huge upsides of Docker for me: Stuff finally "just works" on my machines, too! And it actually "just works" on others' machines as well, which it has all along as they tell me, but it even does so when I'm watching. Amazing, really.
I think the config situation has improved as well – the most frequently used configuration options usually can be passed in as environment variables, so I don't have to pin things to non-default values just because the config file I copied and edited had that default value in its config at that particular version, only to break five versions later – neat. If I do need a config file, I keep it in git and bind-mount it in – the location is usually easy to find (e.g. in the docker run one-liner on the DockerHub page).
Image sizes can be crazy, that part needs work, many people don't write space-efficient Dockerfiles. I try to use alpine or scratch images where possible, that makes the problem quite manageable; and, frankly, the amounts of network, storage and ram needed for the overhead of an alpine image are a very fair bargain for the time and headspace I gain by being able to treat applications as a way darker-gray box than otherwise.
Well you see, Linux culture doesn't really consider the concept of "system" and "application" to be independent. Everything has to be built to work together or the whole thing catches fire and explodes. Consequently, its easier to build entirely different systems for every single application and package them all up together than it is to try and get them to work on the same system.
Weirdly, they seem to think this is a good thing.
Nix is just another overengineered solution to the problem that doesn't really exist on other platforms that are actually, you know, platforms.
Most images have environments variables you can set that will control the config, or you can bind mount a config file from anywhere on your hard drive.
> Now i need to install a docker, type some docker install command, that pulls who-knows how many files, puts them in some 'weird' location, including the config file (which belongs in /etc), so instead of having a 2mb service, I now have a 1gb docker image sitting on my system, with a config file hidden somewhere, and I, the user, don't see any benefits, compared to just 'apt-get install'-ing something.
On the other hand, I can `docker-compose up -d` on practically any platform in existence. I don't have to worry about what package manager this host uses, or whether the version they have supports the config flags I'm using. It's the same everywhere. I don't have to deal with the pain that is 3rd party apt repositories, and handling pinning when they want to ship a newer version of a library than the main OS does (I believe Salt does this).
That, perhaps, is worth less to you than to other people. I would _far_ rather handle setting up another couple Docker containers in Compose than I would handle figuring out which Apt repository they actually publish to, and handling the installation, and fixing the configs (because many services ship with broken configs, because they have no idea what your Postgres password is, for example. Not true of Docker, their docker-compose.yml typically includes setting the password).
This is especially true of multi-component systems, or systems that I'm testing out or using in dev. If I want to enable the Jaeger built into an application, it's one command to run it. In apt, that would have to install 4 or 5 daemons that I would then need to configure.
I also think complaining about disk space is rather disingenuous at this point. Yes, disk space costs money. No, you are unlikely to have Docker make a significant difference in the price to build your PC. 1GB is huge for a Docker image (but many people are bad at trimming them down, so I'll accept it). In 2017, storage cost roughly $0.03/GB on an HDD. You're paying 3 cents to store that Docker image. Probably less at this point, I saw an article about WD releasing $15/TB HDDs in the near future. The moderate performance impact seems more important to me.
Try running an OS off a USB back when Windows 2000 was around. It was very very difficult. These days I just run my OS off Samsung SSDs plugged in externally 24/7 on nearly all non cloud hosted machines.
If I go to a friends house or bring my laptop around I just boot off that external flash devices. Seperating your data from the machine is very flexible.
This is simple now because the hard work has been done. Also way easier to learn programming these days with StackOverflow and virtually infinite resources of the modern internet. Even 80s or 90s internet had some advantages over today but holistically it's just really been getting better and bigger. Learning programming back then require decent manuals and access to other people with expertise.
And on the flipside: Try explaining to people that running stuff on hardware is still viable, that they don't need to break their software up in a dozen containers when, if you look critically, it's just another CRUD app with authentication.
I work with go (system programming) and containers today (I'm 40+, working since 94 with Unix) and the whole development/deployment process is way easier/cheaper/better engineered, than it was before when i was writing and maintaining C based services running on Unix. I remember the staging environment was a physical machine (an expensive spare machine idling), the test suite was bad, we needed a huge QA team, we used to debug stuff in production, every deployment was a surprise. Software engineering best practices were almost 0.
> Try explaining your docker compose setup to a beginner that only knows how to use normal desktop software.
Which "beginner that only knows how to use normal desktop" is trying to run "docker compose setup"?
Simple example from outside of computing: if you have high quality steel available, the design of many machines becomes much simpler.
Accountants, financial managers, psychologists, chefs, any field that requires training has intricacies that can't be explained simply to a lay person