WEBVTT 00:00:00.000 --> 00:00:07.320 Imagine sitting down at a fancy $50 a plate restaurant and tearing into a 16 00:00:05.320 --> 00:00:10.720 oz steak with your teeth instead of cutting it. Not only would this be a 00:00:09.040 --> 00:00:14.920 pretty frustrating experience, but you'd probably be getting a look from your 00:00:12.680 --> 00:00:19.320 boss as he wonders why he's still letting you expense dinner. And as with 00:00:17.000 --> 00:00:24.480 steak, software becomes much easier to manage if you split it up into smaller 00:00:21.560 --> 00:00:28.720 chunks before eating, or rather using it. This approach is actually used by 00:00:26.200 --> 00:00:32.640 lots of larger services today, where they split whatever it is they're 00:00:30.480 --> 00:00:36.960 providing into lots of small microservices. And our friends at IBM 00:00:35.160 --> 00:00:40.760 sponsored this video so we could tell you all about it. To explain what a 00:00:38.640 --> 00:00:45.320 microservice is, let's imagine you're using a site like Netflix. Every time 00:00:43.320 --> 00:00:50.240 you perform some small action on the website, skipping forward, logging in, 00:00:48.160 --> 00:00:55.240 paying a bill, all of these functions are handled by different dedicated 00:00:52.400 --> 00:01:00.120 microservices, a concept that Netflix actually pioneered. And all of them are 00:00:57.440 --> 00:01:05.000 held in virtual containers. You see, the traditional way for a site to handle 00:01:01.920 --> 00:01:07.600 tons of users at once was to run lots of 00:01:05.000 --> 00:01:12.400 separate instances of the same code in virtual machines or VMs. You can learn 00:01:10.400 --> 00:01:16.880 more about virtualization in this video, but the basic idea is that a VM is a 00:01:14.520 --> 00:01:22.280 separate session of an operating system running inside another OS. And a typical 00:01:19.880 --> 00:01:27.040 server can run many VMs at once, which helps a great deal when many people are 00:01:24.480 --> 00:01:30.800 accessing a site. But running a full VM and the associated software that you 00:01:28.560 --> 00:01:35.760 need typically requires millions of lines of code, and oftentimes a user 00:01:33.360 --> 00:01:40.000 wanting to complete just a simple task might require the server to open up more 00:01:38.160 --> 00:01:44.960 full VMs, which is pretty inefficient and can end up hogging CPU cycles and 00:01:42.800 --> 00:01:50.880 other resources. Microservices in containers, by contrast, only contain 00:01:47.840 --> 00:01:52.280 the code for a specific task. So we 00:01:50.880 --> 00:01:56.000 could be talking about just a few thousand lines of code instead of 00:01:54.120 --> 00:02:00.760 millions. Going back to our Netflix example, you might have one container 00:01:58.280 --> 00:02:05.480 for credit card authentication, another for the review system, another for the 00:02:02.680 --> 00:02:10.960 volume slider, and so on and so forth. So if lots of people are using certain 00:02:08.360 --> 00:02:15.600 microservices, the system can just create more instances of that specific 00:02:13.440 --> 00:02:21.920 container instead of having to open up more full fat VMs. In fact, Google runs 00:02:19.320 --> 00:02:26.240 about 2 billion containers at any given time because they're so easy to scale, 00:02:24.640 --> 00:02:30.600 thanks in part to a system called Kubernetes, the Greek word for captain, 00:02:29.200 --> 00:02:33.480 which Google developed to manage containers automatically. And although 00:02:32.320 --> 00:02:37.520 this sounds like it might only be relevant to network engineers, it 00:02:35.320 --> 00:02:42.160 actually has real benefits for you, the home consumer. If there's a problem with 00:02:40.040 --> 00:02:46.440 a service, or if the developers want to add a new feature, they don't have to 00:02:44.360 --> 00:02:50.560 search through 10 million lines of code to find the issue and then possibly 00:02:48.480 --> 00:02:54.880 break the entire thing in the process. Instead, they can just change the one or 00:02:52.720 --> 00:02:58.520 two microservices that they want and leave the others untouched, meaning that 00:02:56.520 --> 00:03:02.840 fixes and new features can be pushed out quickly with less risk of causing other 00:03:00.480 --> 00:03:07.240 problems. The container paradigm also offers speed enhancements, as servers 00:03:05.080 --> 00:03:11.680 can run smaller microservices much more easily without tons of VMs slowing them 00:03:09.160 --> 00:03:15.320 down. This has back-end reliability implications, too, because it usually 00:03:13.600 --> 00:03:18.840 takes mere seconds to deal with a problematic container, meaning that the 00:03:17.280 --> 00:03:24.000 potential for lengthy amounts of downtime is lower. So all this means 00:03:21.920 --> 00:03:28.040 that containers are being used for tons of applications. Games like League of 00:03:25.920 --> 00:03:32.720 Legends and Fortnite rely heavily on containers to reduce lag by easing the 00:03:30.240 --> 00:03:36.960 load on their servers. And Pokémon Go also used containers to fix issues 00:03:34.880 --> 00:03:39.880 shortly after the game's launch and add new features without disrupting the 00:03:38.440 --> 00:03:43.840 millions of users who were playing the game at the time. Banks are also using 00:03:41.960 --> 00:03:48.400 containers with Kubernetes to handle loads of transactions at once without 00:03:45.920 --> 00:03:52.120 slowdowns. And even IBM's supercomputer Watson, which has been heavily utilized 00:03:50.600 --> 00:03:56.160 in the healthcare industry, has transitioned to using containers instead 00:03:54.200 --> 00:04:00.080 of monolithic virtual machines. So it turns out that small containers have 00:03:57.880 --> 00:04:04.280 actually made life a lot easier. It's kind of like digital Tupperware. A big 00:04:02.000 --> 00:04:08.800 thanks to IBM for sponsoring this video. IBM's LinuxONE is one of their 00:04:06.480 --> 00:04:11.920 incredible business machines. That's what IBM stands for, you know. No, I'm 00:04:10.440 --> 00:04:16.200 just kidding. It's It's International. Doesn't matter. Anyway, the LinuxONE is 00:04:13.960 --> 00:04:20.280 their ultimate container and Kubernetes platform using Red Hat OpenShift. 00:04:18.239 --> 00:04:23.280 LinuxONE comes with all sorts of great security gizmos like hardware 00:04:21.799 --> 00:04:27.880 encryption, so your containers are going to be much better protected from all 00:04:24.920 --> 00:04:33.680 sorts of nasty attacks. And LinuxONE can handle loads of containers, up to 2.4 00:04:31.360 --> 00:04:37.920 million on a single system. And it can even handle really big containers, which 00:04:35.600 --> 00:04:42.600 is useful if you are containerizing your existing monolithic applications before 00:04:40.200 --> 00:04:46.280 you refactor them into microservices. This means that your apps run more 00:04:43.960 --> 00:04:50.520 reliably, especially when lots of people are using them. Finally, your containers 00:04:48.440 --> 00:04:54.640 can run on the exact same system as your data, so you don't suffer delays while 00:04:52.640 --> 00:04:59.800 data travels across the network. This means faster games and happier Cyber 00:04:57.400 --> 00:05:03.520 Monday shoppers. So go check that out right here at the link in the video 00:05:00.920 --> 00:05:06.840 description. Just try to contain your excitement. So thanks for watching, 00:05:05.080 --> 00:05:10.200 guys. Like, dislike, check out our other videos. Leave a comment if you have a 00:05:08.400 --> 00:05:14.680 suggestion for a future video, and don't forget to subscribe and follow.