I enjoy reading descriptions such as these that start with easily detectable problems and go into a level of debugging far beyond my skill level. Helps to illuminate some of those "unknown unknowns" that I didn't even ever consider before.
To me, debugging like this is something that should be far more important to people than slinging words like Docker and NodeJS around all day. (and then mostly on Discord, or to them, the older Slack, but not IRC because that is too hard for that crowd -- totally unfounded opinion/rant)
I'm old enough to also be frustrated with buzzword driven development, and it's pretty annoying that so many believe Docker invented containerization, but don't throw the baby out with the bathwater. Containerization is an awesome tool and orthogonal to config management.
upcoming ESXi Update releases will no longer enable TPS between Virtual Machines by default
https://kb.vmware.com/selfservice/microsites/search.do?langu...
Sounds like a sane change to the defaults, but anyone who isn't securing against 3rd party code can turn it back on (to return to much more Docker-like security/performance).
- slow (re)start times
- greater resource consumption
Granted, "too heavy" is relative, but starting a few hundred VMs on a single host (assuming commodity hardware) is not going to work very well.
Several things:
1. We may have a different definition of "commodity hardware", but you're missing the broader point.
2. The broader point is that VMs are significantly less resource-efficient.
3. 1 & 2 notwithstanding, you're conveniently ignoring the issue of (re)start time
4. It's fine to use VMs, but it's frankly bizarre to fight tooth-and-nail over the ridiculous notion that they should always be preferred over containers.
VMs are memory intensive because they duplicate the operating system. The starting point is around 500 MB per VM. That's the only meaningful difference in resources compared to containers.
I am not discussing that they have different starting and stopping time.
And that was never the point.
For instance, the guest operations generally assume they're running on physical hardware and use spinlocks for some small critical sections. Under a physical hardware assumption this can be the correct approach, because the contending thread will leave the critical section soon and this overall performs better.
However, if the contending thread's vCPU is scheduled away by the hypervisor, the other thread may spinlock until the other vCPU gets scheduled back in. This wastes cycles.
A single operating system that uses OS-level virtualization (i.e., containers) has a more complete view of the system and can better multiplex the existing resources. That said, OS-level virtualization is generally accepted to have less isolation than VM isolation and solving the VM problems with, for instance, spinlocks might be easier than solving the isolation problems with containers, which is near intractable given the size of the kernel.
Unikernels try to take this approach and have a lot of the benefits of containers. If you squint, what we're really looking at with unikernels is a microkernel that uses virtualization support in hardware for robust process isolation. What's interesting to me is the question that I never see asked, which is whether we should revisit the microkernel architectures instead of laying more crap on top of monolithic kernels. The problems with Mach in terms of IPC time have been largely mitigated/eliminated with the L4 branch of microkernel.
Resource consumption might be more, but it's not going to be dramatically more than a container. It's not like a container uses nothing, the management and resource constrainers take up resources too.
Containers simply solve nothing and aren't 'better' in general. Containerizing certain programs might be useful, but other than that they are being hyped by the 'shiny new thing' crowd more than it deserves. On top of that, the amount of people using it vs. the amount of people that actually need it is way more of an issue than a container vs. vm debate.
The issue described in this post has nothing to do with "config management vs containers." Its' odd that this article would have "reinforced" that view. How would configuration management have prevented a noisy neighbor?
From the summary:
"The core lesson of this story: just because you are using containers and you get the impression that your applications are perfectly virtualized and isolated, don’t assume the kernel is fully isolating every underlying resource at a container granularity."
and
"Luckily, the solution is there and rather simple: make sure to deeply monitor all your applications."
That's nothing to do with any "configuration management vs containers" argument and everything to do with proper metrics collection and monitoring, which should be part of every "operational readiness" checklist whether Docker is used or not.
Lastly saying that Docker "In most cases it doesn't solve anything" is an absurd statement. Do you believe that virtualization does't solve any problems? If so why do you imagine the Linux kernel supports it?
Anyone who believes in the first place this shouldn't be running production systems...
Nowhere did I state that or even remotely suggest that containers give you the level of isolation that VMs would. My comment was refuting the OPs suggestion that "configuration management" was relevant to the article. Maybe you should go back and re-read the thread.
Part of the debugging method has to do with "let's show our product".
Well written OP.