1
00:00:00,000 --> 00:00:02,300
[No Audio]

2
00:00:02,300 --> 00:00:15,466
[Music Playing]

3
00:00:16,000 --> 00:00:20,666
Containers are an abstraction at Application layer which packages

4
00:00:20,666 --> 00:00:23,233
codes and dependencies together.

5
00:00:23,466 --> 00:00:26,933
[Music Playing]

6
00:00:26,933 --> 00:00:30,133
Let's reiterate and expand this definition further.

7
00:00:30,900 --> 00:00:34,133
Containers are an abstraction at Application layer

8
00:00:34,400 --> 00:00:37,633
which packages codes and dependencies together.

9
00:00:38,433 --> 00:00:42,400
It means instead of just shipping the applications,

10
00:00:42,400 --> 00:00:46,866
containers ship the application and the runtime environment as well,

11
00:00:47,166 --> 00:00:50,433
and they still manage to remain small sized.

12
00:00:50,666 --> 00:00:55,733
How? Let's compare them architecturally with VMs.

13
00:00:56,233 --> 00:01:00,400
In a traditional VM architecture, we have a Hypervisor like

14
00:01:00,400 --> 00:01:04,132
Hyper-V or KVM on top of hardware infrastructure.

15
00:01:04,500 --> 00:01:08,300
These are also called Type 1 Hypervisors, since they don't

16
00:01:08,300 --> 00:01:10,200
need a host operating system.

17
00:01:10,200 --> 00:01:14,666
The Guest OS are provisioned on top of Hypervisor and they

18
00:01:14,666 --> 00:01:17,266
acquire their isolated virtual environment.

19
00:01:18,166 --> 00:01:23,433
In some cases we get Type 2 Hypervisor like Oracle's VirtualBox

20
00:01:23,433 --> 00:01:26,700
where we do need a host operating system and the rest of

21
00:01:26,700 --> 00:01:29,166
the part plays out pretty much the same.

22
00:01:29,600 --> 00:01:33,000
And this is how VMs function in a very broad sense.

23
00:01:34,100 --> 00:01:37,666
Coming back to containers, the biggest difference compared

24
00:01:37,666 --> 00:01:43,000
to VMs is, they don't have guest operating systems.

25
00:01:43,166 --> 00:01:47,400
Container runtime environment is used instead of Hypervisor.

26
00:01:48,000 --> 00:01:49,500
What is it you may ask?

27
00:01:49,800 --> 00:01:52,733
For now, let's say it is software

28
00:01:52,733 --> 00:01:56,166
which manages and runs containers.

29
00:01:56,166 --> 00:02:00,233
Containers contain the application code and the dependencies,

30
00:02:00,233 --> 00:02:04,666
as we have just seen. The dependencies don't only mean external

31
00:02:04,666 --> 00:02:06,233
or third-party libraries,

32
00:02:06,300 --> 00:02:09,100
it also means OS-level dependencies.

33
00:02:09,100 --> 00:02:13,600
The logic behind such implementation is all of the Linux

34
00:02:13,600 --> 00:02:15,966
variants share the same Linux kernel.

35
00:02:16,166 --> 00:02:17,733
Well, more or less.

36
00:02:17,900 --> 00:02:21,800
So there is no point in duplicating the same set of files

37
00:02:21,800 --> 00:02:26,100
over and over in multiple VMs if all containers can just

38
00:02:26,100 --> 00:02:29,266
access them in their own isolated environment.

39
00:02:29,666 --> 00:02:33,733
With that said, what about the files which are uncommon,

40
00:02:33,733 --> 00:02:38,800
or to be precise, the files which are specific to the OS?

41
00:02:38,933 --> 00:02:43,033
Well, containers will contain them along with the application.

42
00:02:43,100 --> 00:02:46,966
And since the process of making the containers and running them

43
00:02:46,966 --> 00:02:49,966
are done by the same container in the environment,

44
00:02:50,066 --> 00:02:52,666
there will be no conflict of environment.

45
00:02:53,966 --> 00:02:57,366
If this information is too sudden for you, don't worry.

46
00:02:57,366 --> 00:03:00,966
The intention of mentioning all of this is just to let you know

47
00:03:00,966 --> 00:03:05,133
that how containers can attain same level of isolation as VMs.

48
00:03:05,266 --> 00:03:10,566
But while sharing the resources with host OS instead of duplicating them

49
00:03:11,100 --> 00:03:13,000
and what happens because of that?

50
00:03:13,400 --> 00:03:16,766
Well, containers consume less storage and memory

51
00:03:16,766 --> 00:03:18,766
without stretching the facts at all,

52
00:03:18,933 --> 00:03:22,800
gigabytes literally turn into megabytes.

53
00:03:23,466 --> 00:03:26,500
This way, shipping them is easier as well.

54
00:03:26,766 --> 00:03:31,033
We don't ship the whole VMs or a long list of instructions,

55
00:03:31,033 --> 00:03:33,366
we just ship ready to run containers.

56
00:03:33,566 --> 00:03:37,166
And since all of the necessary dependencies are also packed

57
00:03:37,166 --> 00:03:41,633
with the containers, if it worked on the developer's environment,

58
00:03:41,966 --> 00:03:45,033
it will work on your machine as well.

59
00:03:46,000 --> 00:03:51,300
Since we have reduced the resources, scaling becomes easy and cheaper.

60
00:03:51,900 --> 00:03:55,966
Even though you need to create ten more replicas of a backend containter,

61
00:03:55,966 --> 00:03:58,733
you probably won't have to spend money on buying

62
00:03:58,733 --> 00:04:00,333
or renting a new server.

63
00:04:01,433 --> 00:04:05,100
In fact, if you need to roll out updates, you can still keep

64
00:04:05,100 --> 00:04:08,800
your applications running by extending your number of replicated

65
00:04:08,800 --> 00:04:11,866
containers and you may achieve zero downtime.

66
00:04:12,400 --> 00:04:14,900
All of this sounds attractive and groundbreaking.

67
00:04:15,500 --> 00:04:20,233
But if we relate this to industries, who are actually using containers?

68
00:04:20,399 --> 00:04:24,533
Well, Google pioneered using orchestrated containers

69
00:04:24,533 --> 00:04:28,399
years ago, when they started facing overwhelming amount of data.

70
00:04:28,666 --> 00:04:33,566
These days, companies like Expedia, PayPal and Glaxosmithline

71
00:04:33,566 --> 00:04:37,866
are voluntary providing themselves as references and case studies.

72
00:04:37,866 --> 00:04:42,133
Apart from them, educational institutions like Cornell University

73
00:04:42,133 --> 00:04:45,266
and gaming giants like Niantic, which became a

74
00:04:45,266 --> 00:04:49,700
huge success after Pokemon Go are all using containers.

75
00:04:49,700 --> 00:04:52,633
Companies are gradually migrating to containers.

76
00:04:52,766 --> 00:04:57,400
As many of you might already know, DevOps jobs are increasing rapidly

77
00:04:57,400 --> 00:05:01,466
and containers are an essential part of the whole DevOps movement.

78
00:05:01,466 --> 00:05:06,066
In the next lecture, we will finally introduce ourselves with Docker

79
00:05:06,066 --> 00:05:08,400
and we'll get started with learning it.