WEBVTT 00:00:00.000 --> 00:00:03.520 Imagine sitting down at a fancy $50 a plate restaurant 00:00:03.520 --> 00:00:06.800 and tearing into a 60-ounce steak with your teeth 00:00:06.800 --> 00:00:10.400 instead of cutting it. Not only would this be a pretty frustrating experience, 00:00:10.400 --> 00:00:16.400 but you'd probably be getting a look from your boss as he wonders why he's still letting you expense dinner. 00:00:16.400 --> 00:00:19.760 And as with steak, software becomes much easier to manage 00:00:19.760 --> 00:00:24.720 if you split it up into smaller chunks before eating or rather using it. 00:00:24.720 --> 00:00:28.520 This approach is actually used by lots of larger services today, 00:00:28.520 --> 00:00:33.960 where they split whatever it is they're providing into lots of small microservices. 00:00:33.960 --> 00:00:37.920 And our friends at IBM sponsored this video so we could tell you all about it. 00:00:37.920 --> 00:00:42.840 To explain what a microservice is, let's imagine you're using a site like Netflix. 00:00:42.840 --> 00:00:46.160 Every time you perform some small action on the website, 00:00:46.160 --> 00:00:49.360 skipping forward, logging in, paying a bill, 00:00:49.360 --> 00:00:53.840 all of these functions are handled by different dedicated microservices, 00:00:53.840 --> 00:00:59.800 a concept that Netflix actually pioneered and all of them are held in virtual containers. 00:00:59.800 --> 00:01:03.560 You see, the traditional way for a site to handle tons of users at once 00:01:03.560 --> 00:01:07.480 was to run lots of separate instances of the same code 00:01:07.480 --> 00:01:12.480 in virtual machines or VMs. You can learn more about virtualization in this video, 00:01:12.480 --> 00:01:15.640 but the basic idea is that a VM is a separate session 00:01:15.640 --> 00:01:19.160 of an operating system running inside another OS. 00:01:19.160 --> 00:01:22.200 And a typical server can run many VMs at once, 00:01:22.200 --> 00:01:25.680 which helps a great deal when many people are accessing a site. 00:01:25.680 --> 00:01:31.880 But running a full VM and the associated software that you need typically requires millions of lines of code. 00:01:31.880 --> 00:01:37.040 And oftentimes, a user wanting to complete just a simple task might require the server 00:01:37.040 --> 00:01:40.600 to open up more full VMs, which is pretty inefficient 00:01:40.600 --> 00:01:43.880 and can end up hogging CPU cycles and other resources. 00:01:43.880 --> 00:01:47.000 Microservices in containers, by contrast, 00:01:47.000 --> 00:01:50.680 only contain the code for a specific task. 00:01:50.680 --> 00:01:55.040 So we could be talking about just a few thousand lines of code instead of millions. 00:01:55.040 --> 00:01:59.280 Going back to our Netflix example, you might have one container for credit card 00:01:59.280 --> 00:02:05.680 authentication, another for the review system, another for the volume slider, and so on and so forth. 00:02:05.680 --> 00:02:09.720 So if lots of people are using certain microservices, 00:02:09.720 --> 00:02:15.120 the system can just create more instances of that specific container instead of having 00:02:15.120 --> 00:02:21.400 to open up more full-fat VMs. In fact, Google runs about 2 billion containers 00:02:21.400 --> 00:02:24.680 at any given time because they're so easy to scale, 00:02:24.720 --> 00:02:30.280 thanks in part to a system called Kubernetes, the Greek word for captain, which Google developed 00:02:30.280 --> 00:02:34.000 to manage containers automatically. And although this sounds like it might only be relevant 00:02:34.000 --> 00:02:38.960 to network engineers, it actually has real benefits for you, the home consumer. 00:02:38.960 --> 00:02:43.480 If there's a problem with a service, or if the developers want to add a new feature, 00:02:43.480 --> 00:02:46.520 they don't have to search through 10 million lines of code 00:02:46.520 --> 00:02:50.640 to find the issue and then possibly break the entire thing in the process. 00:02:50.640 --> 00:02:53.920 Instead, they can just change the one or two microservices 00:02:53.920 --> 00:02:59.280 that they want and leave the others untouched, meaning that fixes and new features can be pushed out quickly 00:02:59.280 --> 00:03:04.600 with less risk of causing other problems. The container paradigm also offers speed enhancements, 00:03:04.600 --> 00:03:07.760 as servers can run smaller microservices much more easily 00:03:07.760 --> 00:03:12.960 without tons of VMs slowing them down. This has backend reliability implications too, 00:03:12.960 --> 00:03:16.920 because it usually takes mere seconds to deal with a problematic container, 00:03:16.920 --> 00:03:21.080 meaning that the potential for lengthy amounts of downtime is lower. 00:03:21.080 --> 00:03:25.160 So all this means that containers are being used for tons of applications. 00:03:25.160 --> 00:03:29.680 Games like League of Legends and Fortnite rely heavily on containers to reduce lag 00:03:29.680 --> 00:03:34.880 by easing the load on their servers. And Pokemon Go also used containers to fix issues 00:03:34.880 --> 00:03:39.360 shortly after the game's launch and add new features without disrupting the millions of users 00:03:39.360 --> 00:03:43.280 who were playing the game at the time. Banks are also using containers with Kubernetes 00:03:43.280 --> 00:03:46.760 to handle loads of transactions at once without slowdowns, 00:03:46.760 --> 00:03:51.920 and even IBM's supercomputer, Watson, which has been heavily utilized in the healthcare industry, 00:03:51.920 --> 00:03:55.960 has transitioned to using containers instead of monolithic virtual machines. 00:03:55.960 --> 00:04:00.040 So it turns out that small containers have actually made life a lot easier, 00:04:00.040 --> 00:04:03.320 kind of like digital Tupperware. So thanks for watching guys, like, dislike, 00:04:03.320 --> 00:04:06.920 check out our other videos, leave a comment if you have a suggestion for a future video, 00:04:06.920 --> 00:04:09.960 and don't forget to subscribe and follow.