I was going to go into the concurrency axis from my Devoxx talk (slides)
this month, but I've been sidetracked by containerization from a slew
of articles I saw (a couple make it into this month's news and tools).
I fully understand how beneficial a container can be for providing you
with an abstraction away from your environment, after all the JVM is
itself a container. But you need to be aware that there is a cost to
every level of containerization, and you need to know that the benefits
you are gaining outweigh those costs.

A note from this newsletter's sponsor

When I say container, maybe you think Docker. But we already have
multiple levels of containers before you get there. Starting with the
hardware, you have the OS overlaying the hardware, so that's the first
container. High performance applications often try to bypass the OS:
applications that know exactly how they'll operate IO will use a raw
partition so that they avoid the filesystem overheads; applications
with the tightest latency constraints isolate cores so that they have
direct control of the thread running on a core; applications needing
to ensure that data transits with no delay lock the process memory
into RAM; there are specialist techniques to bypass the OS for the
tightest control over network IO. Most applications prefer to use the
"OS container" rather than bypass it because it provides a lot of
useful features that you don't need to implement yourself.

The next container if you're running on a virtual OS common to most
clouds would be the virtualization layer - and many enterprises have
to work around it's limitations. Very low latency applications avoid
it, instead using dedicated servers; seriously horizontally scaled
applications monitor the performance of each virtual server and
actually shutdown services when they detect sufficient contention for
resources from competing virtual containers using the shared hardware
(which means that if you're NOT doing that, your services are the ones
that are losing the battle for shared resources).

The JVM layer, whether running on a real or a virtualized OS, is
pretty efficient after 20 years of effort in making it efficient
primarily by trading more memory for optimal speed, but there are
still some things developers find they try to workaround: memory
layout at the cache-line level; reducing object copies; etc.
(you'll find many techniques in my previous newsletters)

So if you add another container layer like Docker, you should be aware
that you are trading whatever features you're getting for some type of
performance consideration - that should be an explicit decision, not
an "oh dear" after-the-fact one.

Now on to our usual links to articles, tools, news, talks, blogs. And
if you need the tips from this month's articles and talks, as ever
they are extracted into
this month's tips page.