-1

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?

  • Are you asking why to run X instances or why to run them in the same host? – Laiv Mar 22 at 6:31
  • why to run them in the same host? – alessandro Mar 22 at 6:41
  • Where in your cite are they talking about "5 instances of the same application"? – Doc Brown Mar 22 at 7:04
  • <quote>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.</quote> – alessandro Mar 22 at 7:05
  • 2
    @Alessandro, for good or for bad, SE is not meant not be a forum for discussion or opinions. That's why we put so many efforts on making questions to be very concrete and concise before giving an answer that otherwise would be opinionated, guesswork or vague. – Laiv Mar 22 at 7:30
2

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.

  • I did a prototype of having a Java app that would shut itself down when it got close to having a major garbage collection. The idea would be to stop routing requests to it, spawn a new instance, allow it to finish what it was doing, then shut it down. It didn't work perfectly but I'm sure it's doable with enough effort. – JimmyJames Mar 22 at 20:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.