OS tax in dockerized production environment

  softwareengineering

I am reading Docker deep dive since I am interested in this shiny technology.

I can read:

The VM model then carves low-level hardware resources into VMs. Each
VM is a software construct containing virtual CPU, virtual RAM,
virtual disk etc. As such, every VM needs its own OS to claim,
initialize and manage all of those virtual resources. And sadly, every
OS comes with its own set of baggage and overheads. For example, every
OS consumes a slice of CPU, a slice of RAM, a slice of storage etc.
Most need their own licenses as well as people and infrastructure to
patch and upgrade them. Each OS also presents a sizable attack
surface. We often refer to all of this as the OS tax, or VM tax –
every OS you install consumes resources!

The container model has a single kernel running in the host OS. It’s
possible to run tens or hundreds of containers on a single host with
every container sharing that single OS/kernel. That means a single OS
consuming CPU, RAM, and storage. A single OS that needs licensing. A
single OS that needs upgrading and patching. And a single OS kernel
presenting an attack surface. All in all, a single OS tax bill!

and then…

That might not seem a lot in our example of a single server needing to
run 4 business applications. But when we’re talking about hundreds or
thousands of apps (VM or containers) this can be game changing.

But in a production scenario why should I run for example 5 instances of my application on the same bare metal behind a load balancer to manage scalabilty and performance?
Probably I am missing something…
Could someone clarify to me the concept please?

14

It doesn’t sound to me like the quoted bit isn’t saying “4 instances of the same application”, rather it’s “4 different applications”. But the question of why you might want to run multiple copies of the same application is still valid!

One common reason is that you can shut down some instances while leaving others available. This is a common pattern for updating software without a user-facing “maintenance window” – you just remove one instance from the load balancer, update it, add it back in, and then remove the other instance, update it, and add it back in.

There are also some cases where running multiple separate instances can be beneficial for other reasons. For example, if an application is parallelizable, but wasn’t written to take advantage of parallelization, it running multiple copies can be significantly faster than running a single one. This can be dangerous (for example, if they are sharing the same database), but in some situations may be perfectly fine.

1

LEAVE A COMMENT