8 ms·

Nothing has become easier; everything is becoming more difficult as technology advances and we've just learned to automate the complexity. But the automation c

Nothing has become easier; everything is becoming more difficult as technology advances and we've just learned to automate the complexity. 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.

teekert 6y ago
I often have to explain Docker (or containers in general) to non-tech people. I tell them I take an entire PC, with all software on it and make it a single function package that I can give to anyone and they can run it anywhere. Almost nobody understands the minutiae of their OS or their CPU. We may understand it a bit more but a Dockerfile or a docker-compose file simply says, "take a fresh full Linux install, install some stuff and run it." 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.
- Un1corn 6y ago
  And what you answer when asked what is the difference between a container and a virtual machine? Because calling it a lightweight VM is obviously a lie and it costed me too much time at work
  - teekert 6y ago
    For the people I talk with that distinction is irrelevant. It's just management that wants to know how I can guarantee that the same code runs on our batch processing cluster and their cloud environment. And how I can develop one code base for both platforms.
- edejong 6y ago
  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.
  - teekert 6y ago
    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.
  - 3np 6y ago
    > 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".
- ajsnigrutin 6y ago
  But how do you explain the need for a "whole system" just to run one application? "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.
  - teekert 6y ago
    Did it just work? Were there never any dependency issues or unsolvable complexities? Or dependencies that were solved differently when run a second time leading to a different output of software? 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.
    - ajsnigrutin 6y ago
      To me, apt-get install always 'just worked'. Same for yum install, emerge etc. 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.
      - AnIdiotOnTheNet 6y ago
        > To me, apt-get install always 'just worked'. Same for yum install, emerge etc. 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...
Cthulhu_ 6y ago
> Put differently: Try explaining your docker compose setup to a beginner that only knows how to use normal desktop software. 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.
- kuu 6y ago
  I've this discussion with some friends AWS lovers: now it all has to be a lambda or a cloud container, even for a simple CRUD server for a side project...
eru 6y ago
No. Some things are genuinely becoming easier and simpler, just because we have the extra oomph to make different trade-offs between implementation complexity and performance. Simple example from outside of computing: if you have high quality steel available, the design of many machines becomes much simpler.
s_dev 6y ago
>Nothing has become easier; 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.
mstipetic 6y ago
Why would you need to? Would a battery engineer need to explain everything simply? Would a bridge engineer? Do you think a normal user knows anything about how a graphics card works? Accountants, financial managers, psychologists, chefs, any field that requires training has intricacies that can't be explained simply to a lay person
pelasaco 6y ago
IMO the things are not getting more difficult, we are just getting older and some of us don't want to adapt. 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"?

teekert 6y ago

I often have to explain Docker (or containers in general) to non-tech people. I tell them I take an entire PC, with all software on it and make it a single function package that I can give to anyone and they can run it anywhere. Almost nobody understands the minutiae of their OS or their CPU. We may understand it a bit more but a Dockerfile or a docker-compose file simply says, "take a fresh full Linux install, install some stuff and run it." 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.

Un1corn 6y ago
And what you answer when asked what is the difference between a container and a virtual machine? Because calling it a lightweight VM is obviously a lie and it costed me too much time at work
- teekert 6y ago
  For the people I talk with that distinction is irrelevant. It's just management that wants to know how I can guarantee that the same code runs on our batch processing cluster and their cloud environment. And how I can develop one code base for both platforms.
edejong 6y ago
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.
- teekert 6y ago
  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.
- 3np 6y ago
  > 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".
ajsnigrutin 6y ago
But how do you explain the need for a "whole system" just to run one application? "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.
- teekert 6y ago
  Did it just work? Were there never any dependency issues or unsolvable complexities? Or dependencies that were solved differently when run a second time leading to a different output of software? 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.
  - ajsnigrutin 6y ago
    To me, apt-get install always 'just worked'. Same for yum install, emerge etc. 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.
    - AnIdiotOnTheNet 6y ago
      > To me, apt-get install always 'just worked'. Same for yum install, emerge etc. 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...

Cthulhu_ 6y ago

> Put differently: Try explaining your docker compose setup to a beginner that only knows how to use normal desktop software. 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.

kuu 6y ago
I've this discussion with some friends AWS lovers: now it all has to be a lambda or a cloud container, even for a simple CRUD server for a side project...

eru 6y ago

No. Some things are genuinely becoming easier and simpler, just because we have the extra oomph to make different trade-offs between implementation complexity and performance. Simple example from outside of computing: if you have high quality steel available, the design of many machines becomes much simpler.

s_dev 6y ago

>Nothing has become easier; 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.

mstipetic 6y ago

Why would you need to? Would a battery engineer need to explain everything simply? Would a bridge engineer? Do you think a normal user knows anything about how a graphics card works? Accountants, financial managers, psychologists, chefs, any field that requires training has intricacies that can't be explained simply to a lay person

pelasaco 6y ago

IMO the things are not getting more difficult, we are just getting older and some of us don't want to adapt. 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"?