The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,969 other subscribers

Containers, totally not a lightweight VM, and also not a hype.

Posted by jpluimers on 2018/05/08

If you start doing stuff with containers, be sure to read the below parts of a series “Containers, totally not a lightweight VM, and also not a hype.” by Kristian Köhntopp, Senior Scalability Engineer at

Be sure to read all the links below, including the comment threads as there is a wealth of information in them.

I’ve tried to summarise parts further below, but there is so much information in the links that you really should long read all the links.

Further reading, all by or via Kristian:

Some highlights of the parts

The TL;DR is: A program is a collection of instructions lying around passively somewhere. A process is a program in execution. It’s not just instructions, but also a program counter, registers, a stack, file handles, an effective UID and GID (rights associated with the process), and a few other things.There are four core system calls that are dealing with programs and processes: fork(), execve(), wait() and exec().

Source: Container I: Ten years ago I wrote a Text (in German) explaining how Unix sta…

Container II: What happens between fork() and execve() can be quite complicated

The TL;DR is that with namespaces you can make large parts of the system invisible to a process and this processes children.

basically docker: A fork() + stuff + execve(): A container is a process launch, fairy dust with limit setup, and a program launch. It’s fast. It’s not a VM. It uses your normal kernel, just like any fork() and exec() would. But it provides the execution environment for this process in a fancy loop mount on drugs, to the process does not care where it is, as long as a Linux kernel API exists. The programs and libraries needed are provided inside the weird limited universe of that process.

Source: Container II: What happens between fork() and execve() can be quite complicat…

We have essentially created a data center that runs without users – it does no longer care about users and what machine is suitable for an install.

The image declares resource consumption – 4 cores, 32 GB memory and the scheduler finds a space. The image travels to that location and is being run.

It can’t write. So if the image needs data to perform a useful thing, the data must come from elsewhere, an object store or a database: it talks to resources like remote object stores or databases.

It’s still a fork() and exec(), like any normal Unix process start, but we do not know on which machine.

Schedulers that are doing this kind of thing are Mesos/Marathon or Kubernetes (K8s).

Source: Containers III: One machine is booooring! Dockering on a single machine is t…

If your dockered instances are not talking to either ZK, etcd or consul, it is likely that you are not doing things properly.

Source: Container IV: Where am I and what is my purpose in life? Dockering on a mill…

we can provide endpoints for each of these services on each of the dockerhosts. Containers just drop log lines, metrics and other stuff locally, talk to the local queue endpoint for incoming or outgoing communication and will also find their local consul proxy – all at fixed ports on the IP of their physical host.

We probably want something like Kafka for such a queue.

Source: Container V: Here to stay In order to create a system of services, we have e…

Your data center network sucks and you can’t do state and containers and live at the same time, unless you rebuild from your core outwards.

Source: Container VI: Yeah, state. “So we do keep state outside of containers, becau…

Note that you still can’t scale up, only down from a known maximum value. That is because stateful components in your service do not scale up past a certain point at which they simply die in locking. In a properly designed system that is your bottleneck and you scale down from this

Source: Container VII: How do I deploy? There are various ways to inject requests to…
You have an image, which can be run as a container.

It’s not running.

A request comes in.

The container is being started and executes a “function”. The request is being processed.

20 years ago we have been calling this “CGI”.

Source: Container VIII: “Serverless”. You have an image, which can be run as a conta…

What you want is something that has been designed as one and not by a committee, and that is integrated, lean and mean. As a customer, this means you need to formulate your requirements, sort yourself into the right bin and then aggressively challenge vendors. Also, you need to be able and willing to do some integration work yourself. The result will be one to two orders of magnitude more agile than Openstack, though.

  1. The model is so attractive that there is a ruleset and school of thought for writing applications in a way that they fit it nicely,

Source: Container IX: What is it doing to us? With containering, we have a method to…
In the Scifi Series Babylon 5, the various factions had a way of asking humans four existential core questions: Who are you? What do you want? Why are you here? Where are you going?

Some examples at:

Source: Container X: B5 moments: Who are you? What do you want? In the Scifi Series …


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: