[No Audio]
[Music Playing]
Containers are an abstraction at Application layer which packages
codes and dependencies together.
[Music Playing]
Let's reiterate and expand this definition further.
Containers are an abstraction at Application layer
which packages codes and dependencies together.
It means instead of just shipping the applications,
containers ship the application and the runtime environment as well,
and they still manage to remain small sized.
How? Let's compare them architecturally with VMs.
In a traditional VM architecture, we have a Hypervisor like
Hyper-V or KVM on top of hardware infrastructure.
These are also called Type 1 Hypervisors, since they don't
need a host operating system.
The Guest OS are provisioned on top of Hypervisor and they
acquire their isolated virtual environment.
In some cases we get Type 2 Hypervisor like Oracle's VirtualBox
where we do need a host operating system and the rest of
the part plays out pretty much the same.
And this is how VMs function in a very broad sense.
Coming back to containers, the biggest difference compared
to VMs is, they don't have guest operating systems.
Container runtime environment is used instead of Hypervisor.
What is it you may ask?
For now, let's say it is software
which manages and runs containers.
Containers contain the application code and the dependencies,
as we have just seen. The dependencies don't only mean external
or third-party libraries,
it also means OS-level dependencies.
The logic behind such implementation is all of the Linux
variants share the same Linux kernel.
Well, more or less.
So there is no point in duplicating the same set of files
over and over in multiple VMs if all containers can just
access them in their own isolated environment.
With that said, what about the files which are uncommon,
or to be precise, the files which are specific to the OS?
Well, containers will contain them along with the application.
And since the process of making the containers and running them
are done by the same container in the environment,
there will be no conflict of environment.
If this information is too sudden for you, don't worry.
The intention of mentioning all of this is just to let you know
that how containers can attain same level of isolation as VMs.
But while sharing the resources with host OS instead of duplicating them
and what happens because of that?
Well, containers consume less storage and memory
without stretching the facts at all,
gigabytes literally turn into megabytes.
This way, shipping them is easier as well.
We don't ship the whole VMs or a long list of instructions,
we just ship ready to run containers.
And since all of the necessary dependencies are also packed
with the containers, if it worked on the developer's environment,
it will work on your machine as well.
Since we have reduced the resources, scaling becomes easy and cheaper.
Even though you need to create ten more replicas of a backend containter,
you probably won't have to spend money on buying
or renting a new server.
In fact, if you need to roll out updates, you can still keep
your applications running by extending your number of replicated
containers and you may achieve zero downtime.
All of this sounds attractive and groundbreaking.
But if we relate this to industries, who are actually using containers?
Well, Google pioneered using orchestrated containers
years ago, when they started facing overwhelming amount of data.
These days, companies like Expedia, PayPal and Glaxosmithline
are voluntary providing themselves as references and case studies.
Apart from them, educational institutions like Cornell University
and gaming giants like Niantic, which became a
huge success after Pokemon Go are all using containers.
Companies are gradually migrating to containers.
As many of you might already know, DevOps jobs are increasing rapidly
and containers are an essential part of the whole DevOps movement.
In the next lecture, we will finally introduce ourselves with Docker
and we'll get started with learning it.