0

I am trying to understand what is the difference between Docker Container Process and IIS Process? From Container perspective, it is not advisable to have more than one process in a single container and in IIS also you can not do that. Each application is executed in it's own process. So if IIS provides me the the same Process Isolation then why should I use Containers?

Mohit Jain
  • 61
  • 1
  • 6
  • If you have an existing non-Docker production workflow, I'd stick with it. I know there's significant overlap between what Docker does and higher-end Java application servers, and with Erlang's distributed-computing mechanisms, and it's probably easier to use these sorts of setups on bare metal or VMs than to try to add Docker in the middle of it. – David Maze Jan 20 '19 at 15:41
  • IIS isolation cannot help in advanced cases (such as .NET Framework isolation), but Docker container isolation can. Thus, what to use heavily depends on your requirements. – Lex Li Jan 20 '19 at 21:11

1 Answers1

0

Although it is process isolation per app on iis docker provides another layer of isolation where memory used and kernel access is also isolated. Bear in mind that containers contain all that is needed to run something including the os. Only thing is the physical os memory and kernel that is used together as is the case with vm-s for example. So in a way containers give you even higher isolation than just having a separate process for an application.

But that is not the main selling point of containers. The main selling point is that they are scalable solutions that are basically infrastructure as code and thus easier to manage and deploy on any environment. Also being that means that it will work the same wherever you deploy it to since you include all is needed in them. And if your apps have lots of traffic with load balancing you ca deploy multiples of the same container in a cluster and do not have those bottlenecks.

Second point is that during development there is historical data of what was added to the container and removed to have a stable environment. That and the ability to deploy dev instances alongside prod instances and just switching over makes it reduce possible downtime for unforeseen error minimal as you can just redirect to old prod container until the fix is out.

A bit of a rant there and yet there is more.

markorial
  • 425
  • 2
  • 12