Difference between containers (Docker) and IIS

I am learning about containers (mostly Docker) since it is coming to windows. And the benefits seem very similar to IIS.

I work behind a firewall building apps for my company (Line of Business). We have a bunch of VMs that will each host a family of web services. One VM can have 20+ services running on IIS.

  • How To run from host machine bash script inside docker container and remain in bash in container [duplicate]
  • Is it possible to change the read-only/read-write status of a docker mount at runtime?
  • Why doesn't docker tomcat doesn't override a war properties file with a properties file from a shared dir?
  • Vagrant mount error after installing Docker
  • Connect from web app to Oracle DB docker container
  • Can't access docker url via curl or Postman
  • In that scenario what does deploying my services via Docker get me that I don’t already get using IIS?

    NOTE: I am completely new to Docker and only have developer level experience in IIS.

  • Docker: ENTRYPOINT can't execute command because it doesn't find the file
  • How does the container use more memory than the limit?
  • Have Concourse only build new docker containers on file diff not on commit
  • cannot generate a service account token in kubernetes v1
  • connecting to local mongodb from docker container
  • Docker Private registry - access registry images after container is removed
  • 2 Solutions collect form web for “Difference between containers (Docker) and IIS”

    Docker is not a replacement for IIS – it can run an application like IIS within a container (I assume – not sure how this is going to work on Windows).

    Docker is more like a replacement for a VM – the biggest difference between a VM and a Docker container is that the Docker container is MUCH lighter than a full VM. The usual claim that you see is that you can run many more Docker containers on a host than VMs (but your mileage may vary – some of the claims out there are bit… overstated).

    Basically, the idea is this: a VM is a full virtual machine – a real OS running on top of virtual hardware (that looks real enough to the OS). Thus, you’re going to get all the bells & whistles of an OS, including stuff you probably don’t need if you’re running IIS or another HTTP server.

    Docker, on the other hand, just uses the host’s OS but employs some useful features of the OS to isolate the processes running in the container from the rest of the host. So you get the isolation of a VM (useful in case something fails or for security) without the overhead of a whole OS.

    Now you could run “20+ services” in a single Docker container, but that’s not generally recommended. Because Docker containers are so lightweight, you can (and should!) limit them to one service per container. This gives you benefits such as

    • separation of concerns: your database container is just that – a database. Nothing else. And furthermore, it only handles the data for the application that’s using it.

    • improved security: if you want to set it up this way, your database container can only be accessed from the application that’s using that database.

    • limited stuff installed: your database container should be running MySQL only – no SSH daemon, no web server, no other stuff. Simple & clean, with each container doing exactly one thing.

    • portability: I can configure my images, pull them to a new host, and start up the container and I will be guaranteed to have the exact same environment on the new host that I have on the old one. This is extremely useful for development.

    That’s not to say you couldn’t set something similar up using VMs – you certainly could – but imagine the overhead of a full VM for each component in your application.

    As an example, my major project these days is a web application running on Apache with a MySQL database, a redis server, and three microservices (each a simple independent web application running on Lighttpd). Imagine running six different servers for this application.

    Docker containers add support for .NET, SQL Server, and other workloads that would integrate with IIS. You also benefit from docker portability, as you could take your container images and run them on AWS or Azure,as well as privately. And, you get access to a large ecosytem of docker based tools . . . bottomline, the industry is moving to support the Docker API.

    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.