1988: Containers

|< < Prev Comic #1988 (May 2, 2018) Next > >|

Containers

Title text: All services are microservices if you ignore most of their features.

Explanation

This explanation may be incomplete or incorrect: Created by SOME GLUED TOGETHER SERVERS - Please change this comment when editing this page. Do NOT delete this tag too soon. If you can address this issue, please edit the page! Thanks.

Docker is a computer program that performs operating-system-level virtualization also known as containerization. It is developed by Docker, Inc. White Hat was complaining about how everyone was using Docker, and then Cueball went on about how he wanted to use a tablet as a wall display. He went on about how he tried programming it, but he eventually gave up and glued two smartphones together. The joke is that he achieved software enlightenment, even though he didn't code any software.

Many (most? all?) programmers these days rely heavily on previously written code found online, eg StackExchange. This has the advantage that it takes less work, and if it's well written and documented, can be easily customised for the specific task and environment at hand. It has the disadvantage that it's also easy to incorporate it into other software without fully understanding how it works; in theory, an entire program can be developed from such code, by "gluing together stuff that you don't understand".

Transcript

This transcript is incomplete. Please help editing it! Thanks.

(White Hat is sitting at a computer. Cueball is standing behind him.)

White Hat: Man, Docker is being used for everything.

White Hat: I don't know how I feel about it.

Cueball: Story time!

(Cueball is standing by himself)

Cueball: Once, long ago, I wanted to use an old tablet as a wall display.

(A picture of Cueball's imagined tablet)

Cueball: I had an app and a calendar webpage that I wanted to show side by side, but the OS didn't have split-screen support.

Cueball: So I decided to build my own app.

(White Hat and Cueball as before, but White Hat has turned to face Cueball)

Cueball: I downloaded the SDK and the IDE, registered as a developer, and started reading the language's docs.

(A picture of two phones glued together, held on a backing board)

Cueball: Then I realized it would be way easier to get two smaller phones on eBay and glue them together.

Cueball: On that day, I achieved software enlightenment.

(White Hat and Cueball as before, facing each other)

White Hat: But you never learned to write software.

Cueball: No, I just learned how to glue together stuff that I don't understand.

White Hat: I...OK, fair.

 add a comment! ⋅  add a topic (use sparingly)! ⋅  refresh comments!

Discussion

Pretty much a description of my social interactions ... Cosmogoblin (talk) 17:51, 2 May 2018 (UTC)

Pretty much a description of all my "useful" programs. -- Linker (talk) (please sign your comments with ~~~~)

I feel the thrust of this comic is partly “people use docker because they don’t know how to do things properly”; notably such people get tasks done easier and faster, but their work involves wasting a lot of computing reaources to do small tasks inside entire emulated systems. Agree? Disagree? 162.158.62.153 18:59, 2 May 2018 (UTC)

Agree. --Joshupetersen (talk) 15:55, 3 May 2018 (UTC)

Agree! 108.162.237.184 17:08, 3 May 2018 (UTC)

... it's been four years, but it's worth noting that Docker doesn't emulate an entire system - you're thinking of virtual machines. Containers are just isolated userspaces (they share the host kernel and hardware like normal processes!). 108.162.216.64 06:56, 30 April 2021 (UTC)

I don't know if its just docker, almost any time I've gone to build mobile anything the API needs new libraries, their "secure" connecting functions must be used, or some other blackbox MUST be /glued/ to my work. If I don't stay on top of every platform, this in and of itself is a head ache I can't imagine what it'd be like if I had to learn and comply with the content of these libraries. 172.69.90.40 (talk) (please sign your comments with ~~~~)

When did any tablet with a browser not support <frame>s and <iframe>s? And for that matter why are docker containers with kubernetes better than server images with a load balancer? I asked one large-shop sysadmin who had transitioned to the former from the latter, and he said, "There really aren't many differences but I feel like I'm ready for microservices." 172.68.34.52 22:50, 2 May 2018 (UTC)

The issue as I see it is to get the two apps to both run simultaneously and appear side by side, which probably involves either writing code to control the window manager or getting the existing apps to output to an image that can be drawn on screen. I'm not a mobile developer, but my guess is that this would be quite difficult for a novice programmer.Probably not Douglas Hofstadter (talk) 23:13, 3 May 2018 (UTC)

For some reason, this really, really, REALLY feels like it's a continuation of 1987. Agree? Disagree? Also, the 'wasting a lot of computing resources to do small tasks inside entire emulated systems' does not feel like valid criticism, since they are just walled-in processes sharing the same kernel (and everything below). Firing up full-blown separate VMs for things that could just as well run in containers is the real wasteful choice IMHO. 162.158.238.70 07:29, 3 May 2018 (UTC)

Agree. 1987 shows how problematic Python can be due to its lack of a well thought out version control. How can you avoid this mess? Docker! It isn't the only way, but IMHO the most elegant solution. And yes, I have created docker containers where the sole purpose was to avoid contaminating an existing Python installation. Epsilon (talk) 05:12, 4 May 2018 (UTC)

The (en)light(ening)est (co)processes are started with fork() and exec(). 172.68.34.52 22:20, 3 May 2018 (UTC)

Don't get mobbed by the docker marketers! I guess a lot of people use Docker today, but to me the comic reads as a criticism. I feel the real joy of programming is diving deep into components to learn how they work and connecting them in the most elegant, efficient ways possible (real 'hacking'). Using scripts, macros, and containers does not demonstrate to me an understanding of the real function of the components being used, and working without this understanding is inevitably going to lead to unexpected behavior somewhere later (problems, bugs, vulnerabilities) because you don't really know what your pieces are doing. I think the push for people to ignore these things is causing a 'dumbing down' of software workers that we should resist. I think a great use of containers is security isolation or build environment testing ... not software design. 172.68.54.106 10:51, 4 May 2018 (UTC)

I agree about the "real joy" of getting to understand how some software works. Just like with mountain climbing. Using a helicopter to get to the top is much simpler and much more convenient. It also has a higher chance of success. But it sort of removes the joy. On the other hand, if you do programming for a living you might need to choose the helicopter. Your comment about "really know what your pieces are doing" is absolutely true. But note the wording here: what and not necessarily how. If you need to know that module X and module Y are difficult to combine because they were built against different versions of library Z then you have gone too far. Epsilon (talk) 07:31, 5 May 2018 (UTC)

I like the helicopter analogy. Similar to the comic, it somewhat plays to both camps. The provider of the helicopter flight plans can tell people how to get to the mountaintop with little investment of effort to reach a high degree of success. However, people using this service take on the increased burden of providing for an expensive helicopter and its fuel. The provider of maps, instructions, and training to climb the mountain easily and reliably has invested in more effort, but the service they provide requires far fewer capital resources from the user to climb the mountain over and over. A difference here is that helicopters are very fast, whereas spinning up containers to execute a task will actually be slower than the alternative. Another thing those who code for the joy of it will talk about, is the value of investing one-time work up-front so that repeated tasks are made simpler later. But obviously people who need to reach deadlines that have been set too early to "do the work properly" will not be able to do this. Either module X or Y needs to be updated to work with the newer version of library Z. The older version likely has bugs and vulnerabilities. By not updating it, you are passing these problems on to your users. 172.68.54.22 10:55, 5 May 2018 (UTC)

Is it worth adding that "achieved enlightenment" is probably a reference to http://www.thecodelesscode.com/?

The idea behind docker is that you do not glue together small code snippets. Whether from StackOverflow or elsewhere. What you are gluing together is in effect entire machines with software already installed. You normally don't know or care about any details finer than that. Not even which operating system the code was written for, which computer language it was written in, or whether the software has some odd and specific requirements about what else is installed on that machine. It is true that many programmers that copy snippets from StackOverflow don't really understand what those snippets are doing. But if you view this comic as an explanation of what Docker is all about, a reference to "copying small code snippets" seems to miss the point. Epsilon (talk) 04:54, 4 May 2018 (UTC)

I've taken the liberty of removing the incompleteness notice and rewording some of the hail corporate passages. I don't think the explanation is too pro docker, it looks pretty neutral to me. //gir.st/ (talk) 10:02, 28 August 2018 (UTC)