WEBVTT 00:00.080 --> 00:05.420 Before we start exploring the intricacies of Docker and writing code, it's crucial to take a step back 00:05.420 --> 00:10.400 and understand the underlying reasons and benefits of using this technology. 00:10.430 --> 00:17.180 After all, truly effective developers don't just blindly follow trends or use tools without grasping 00:17.180 --> 00:18.800 their purpose and value. 00:19.040 --> 00:26.390 All right, so the inception of Docker in 2013 was a very big deal because it solved a significant problem 00:26.390 --> 00:27.590 that developers faced. 00:27.590 --> 00:34.580 The it works on my machine problem, whereby an application runs successfully on one machine but fails 00:34.580 --> 00:35.600 on another. 00:35.630 --> 00:40.370 The problem arises because the developer is running everything bare metal. 00:40.400 --> 00:46.550 A bare metal setup simply means that the application or software is installed and runs directly on the 00:46.550 --> 00:50.990 physical hardware and operating system of their computer of their machine. 00:51.230 --> 00:58.910 For example, installing a MySQL on a windows computer, or or running a Python app on a MacBook Pro 00:58.910 --> 01:04.850 in both instances, the application is running successfully on the machine's hardware and operating 01:04.850 --> 01:05.420 system. 01:05.420 --> 01:12.290 However, a Python app that runs smoothly on the on one MacBook Pro might fail inexplicably. 01:12.290 --> 01:13.130 On another. 01:13.130 --> 01:18.740 There could be something else in that computer's file system, or a process running in the CPU that's 01:18.740 --> 01:21.680 interfering with the application, causing it to fail. 01:21.950 --> 01:24.950 That's the challenge with running applications on bare metal. 01:24.950 --> 01:31.880 The app is, for lack of a better word, completely exposed to every disturbance in its environment, 01:31.880 --> 01:39.230 be it a conflicting dependency, uh, software, a troublesome library, or an intrusive system level 01:39.230 --> 01:42.440 process that keeps poking and prodding at the application. 01:43.250 --> 01:49.670 So to solve this problem, we need to isolate the application and shield it from any disturbances that 01:49.670 --> 01:51.740 may be present in its environment. 01:51.770 --> 01:58.220 The first solution in the early 2000 was to run applications inside of virtual machines. 01:58.250 --> 02:04.430 However, while virtual machines are capable of shielding the application they have, they they run 02:04.430 --> 02:10.580 their own separate operating system, which makes them very slow, heavy and very expensive to run. 02:11.210 --> 02:12.260 Enter Docker. 02:12.290 --> 02:17.120 Docker allows developers to run their applications inside of containers. 02:17.150 --> 02:23.630 A container includes the application source code and only the resources that the application needs in 02:23.630 --> 02:25.820 order to run nothing else. 02:25.850 --> 02:31.730 Just like we saw with virtual machines, this provides a level of isolation that ensures the application 02:31.730 --> 02:35.960 behaves consistently regardless of the ecosystem that it's running in. 02:35.990 --> 02:40.610 But unlike virtual machines, containers do not run their own operating system. 02:40.610 --> 02:46.040 All a container has is the source code, the dependencies that the code relies on, nothing else. 02:46.070 --> 02:52.220 Containers can still isolate the application while being small and lightweight, effectively solving 02:52.220 --> 02:58.400 the it works on my machine problem because you can only run a few virtual machines on a server, but 02:58.400 --> 03:02.780 you can run hundreds if not thousands of containers on that same server. 03:02.780 --> 03:08.000 So it comes to no surprise that containerization is very quickly being adopted by some of the biggest 03:08.000 --> 03:13.400 companies out there and running applications inside of containers has become a very crucial skill for 03:13.400 --> 03:14.300 developers. 03:14.330 --> 03:20.600 Docker currently is the de facto standard for container technology, which is why this course is going 03:20.600 --> 03:26.150 to teach you how to run many different types of applications inside of Docker containers, which we 03:26.150 --> 03:29.000 can do by opening up the lesson starter projects. 03:29.000 --> 03:32.570 So go to your VS code window and let's get started.