Difference between containers (Docker) and IIS

Question

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.

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.

Answer 1

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.