Welcome back.


And in this part of the course,


I want to cover two main topics.


I'll start by stepping through container architecture


and then I'll cover


some of the high-level benefits of containers.


At this level, you can think of containers and Docker


as roughly the same thing.


A Docker container is a type of container.


The difference doesn't matter


until we go much deeper into the tech.


Now, before we move on, if you haven't watched my video


on physical servers versus virtual machines,


then go ahead and do that now


before continuing with this video.


At this point though, let's jump in and get started.


Now, as a reminder, with a virtual machine architecture,


we have physical hardware commonly referred to as a VM host.


On top of that, either the hypervisor is running directly


or a HOST OS and then the hypervisor.


This is the difference between say VirtualBox,


which runs on an operating system,


versus VMware, which runs directly on the host.


Then we have virtual machines,


each of which runs its own guest operating system


which could be the same operating system,


for example, old Debian,


or they could each be different guest operating systems.


And then running inside of the guest operating systems,


we have our applications as well as any libraries


or Runtime environments.


Now, you'll recall from the video where I covered this


I mentioned that running multiple guest operating systems


is actually very costly in terms of resources


and this can actually be the cause


of large scale duplication


if many copies of the same operating system are used.


It also means because each virtual machine


needs to start up its own operating system,


there's also added overhead


in terms of startup and restarts


although this is less than with physical servers.


Now, let's compare this to containers.


We start with the same hardware


and will refer to this as a Docker host or container host


and on top of this is a host operating system.


On top of this is a Container Engine.


In the case of Docker, this is called Docker Engine.


Now, so far this might look familiar,


but there are a few key differences.


First, the Docker or Container Engine by comparison


is generally lighter than a hypervisor


because it has less to do.


Secondly, any containers running on this Docker host


they share the same host operating system.


They run as a process in that operating system.


It means that containers don't need to run


their own individual operating systems.


They only need to run the libraries and Runtime environment


and the application itself.


Because of this containers are much smaller


and more lightweight versus the same application


running within a virtual machine.


It means that on a given piece of physical hardware


running containers versus virtual machines


results in more free capacity.


It means you can run a smaller host or use the same host


but pack in more containers resulting in better utilization


and thus more value for a business.


Now, from a high level perspective


that's the main differences


between how you run virtual machines and containers.


Let's finish up by stepping through


some of the main summary points


that you'll need to understand.


Now, some of these are repeats


but I just want to make absolutely sure


that you a 100% understand them.


First containers run on a container host.


This is the physical hardware


and they run via a Container Engine.


In the case of Docker, this is called Docker Engine.


Now, a container only contains an application


its libraries and any Runtime environments required.


They don't contain any operating system


because they share the operating system


running on the container host.


Each container runs as a process


within this host operating system.


Now, this means containers are super lightweight


and can be densely packed


onto a host and started or restarted quickly.


Not having to start or restart an entire operating system


for each container is a substantial amount of overhead


which is removed.


Now, containers can be impacted by other containers.


This is a downside of sharing


the container host operating system.


It's just a process within that operating system.


While the container HOST OS might have ways


to control the amount of resource allocation a process gets


it's never going to be as tightly controlled


and isolated as virtual machines.


If one container is noisy,


i.e. consuming a massive amount of CPU or memory,


other containers can be impacted.


Just imagine somebody playing loud music


at 2:00 AM in a neighboring apartment.


If you live close to this apartment


you'll be able to hear this music


and this is the same with containers


because they're not strongly isolated from other containers


any container aggressively using resources


on the container host can impact other containers.


Now, there are some ways on modern Container Engines


that this is minimized


but it's something that you should keep in mind.


Now, the best explanation that I've heard


to understand containers is this.


They were created to fix an application shipping problem


where an application was developed on a developer's machine


but didn't work when deployed into production.


This led to the famous line of, it works on my computer


and well, containers are a way to ship that very computer.


Containers are designed to hold an application


as well as everything that application needs to function.


This means specific, tested,


known working versions of libraries.


Once you know the container works,


you know it works anywhere that that container runs.


Okay, so that's everything I wanted to cover for now.


Thanks for watching.


When you're ready,


I'll see you in the next part of the course.