1988: Containers

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

Containers

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

Explanation

Docker is a computer program that performs operating-system-level virtualization also known as containerization. White Hat notices that many people are using Docker for "everything," implying that he does not understand what all the fuss is about. Cueball then explains the fundamental idea behind Docker with a simple story.

He notes how difficult it can be to combine two programs and have them work together as one. This is something all programmers can relate to. His specific example is to get two separate programs to display side-by-side on a tablet. The main joke is that Cueball's solution is a surprising twist to solving the problem. Instead of writing a lot of complicated code to deal with the problem at hand, he sidesteps the problem by using two separate devices, literally gluing them together. Containerization software, like Docker, uses the same general idea but the "glue" and the "multiple computers" are done in software, instead of literally gluing two computers together.

Cueball states that he achieved "software enlightenment" when he "solved" the problem by sidestepping it.

White Hat's initial confusion comes from the fact that Cueball did not write any software, yet achieved "software enlightenment." A good programmer doesn't necessarily need to be able to write programs or even understand how they work, provided that they have the skills needed to combine existing programs to solve tasks. An alternate interpretation is that someone with little programming experience is able to create a working program simply by copy/pasting code snippets from a coding site such as Stack Overflow and "gluing" them together without really understanding how they work.

The title text makes a joke about developers writing code for use in a containerized environment. The ideal is to only write "microservices" which are modules that do just one thing and do it well. The joke here is that even when a module does many different things, you can pretend it is a "microservice" by just ignoring all of its features but one (hopefully one that it does well).

Transcript

[White Hat is sitting at a laptop. 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 with two applications open side by side. The app on the left is "LiveCam". The app on the right is Google Calendar.]

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 smartphones glued together side by side, held on a backing board. The same two applications shown earlier are open on different phones.]

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 still facing each other, with White Hat's arm resting on the back of the chair.]

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)