Containerization Explained

hi everyone my name is Sai Benin and I'm a developer advocate with IBM today I want to talk about containerization whenever I mentioned containers most people tend to default to something like docker or even kubernetes these days but container technology has actually been around for quite some time it's actually back in 2008 that the Linux kernel introduced C groups or control groups that basically paved the way for all the different container technologies we see today so that includes docker but also things like cloud foundry as well as rocket and other container runtimes out there let's get started with an example and we'll say that I wasn't developer and I've created a node.js application and I want to push it into production well take two different form factors to kind of explain the advantages of containerization so let's say that first we'll talk about VMs and then we'll talk about containers so first things first let's introduce some of the things that we've got here so we've got the hardware itself just big box we've got the guest or rather the host operating system as well as the hypervisor hypervisor is actually what allows us to spin up VMs already we've let's take a look at this shared pool of resources with the host OS and hypervisor we can assume that some of these resources have already been consumed next let's go ahead and take this JSON and push it in and to do that I need a Linux VM so let's go ahead and sketch out that Linux VM and in this VM there's a few things to note here so we've got another operating system in addition to the host OS is going to be the guest OS as well as some binaries and libraries so that's one of the things about Linux VMs that even though we're working with a really lightweight application to create that Linux VM we have to put that guest OS in there in a set of binaries and libraries and so that really bloats it out in fact you know I think the smallest node GS VM that I've seen out there is 400 plus megabytes whereas the the the node.js runtime and app itself would be you know under 15 so we've got that with and we go ahead and let's push that Jay s application into it and just by doing that alone we're going to consume a set of resources next let's think about scaling this out right so we'll create two additional copies of it and you'll notice that even though it's the exact same application we have to use and deploy that's that's separate guest OS and libraries every time and so we'll do that three times and by doing that essentially we can assume that for this particular hardware we've consumed all of the all of the resources and there's another thing that I haven't mentioned here but this jeaious application I developed it on my macbook so when I pushed it into production to get it going on the VM and noticed that there were some issues and incompatibilities this is the the kind of foundation of this big he-said she-said issue where things might be working on your local machine and work great but when you try to push it into production things start to break and this really gets in the way of doing agile devops and continuous integration and delivery that's solved when you use something like containers there's a three-step process when kind of doing anything container related and pushing or creating containers and it almost always starts with first some sort of a manifest so something that describes the container itself so in the darker world this would be something like a docker file and Cloud Foundry this would be a manifest yamo next what you'll do is create the actual image itself so for the image you know in again if you're working with something like docker that could be something know be a docker image for working with rocket it would be an ACI or application container image you know so regardless of the different containerization technologies this process stays the same and the last thing you end up with it's an actual container itself you know that contains all of the runtimes and libraries and binaries needed to run an application that application runs on a very similar set up to the VMS but what we've got on this side is you know again a host operating system the difference here instead of a hypervisor we're going to have things like a runtime engine so if you're using docker this would be the docker engine and you know different different containerization technologies would have a different engine regardless it's something that runs those containers again we've got this shared pool of resources so we can assume that that alone consumes some set of resources next let's think about actually container izing this technology so we talked about the three-step process we create some you know a docker file we build out the image we push it to a registry and we have our container and we can start pushing this out as containers the great thing is these are going to be much more lightweight so deploying out multiple containers since you don't have to worry about a guest OS this time really just have the libraries as well as the the application itself so we've scaled that out three times and because we don't have to duplicate all of those operating system dependencies and create bloated VMs we actually will use less resources so she's a different color here and scaling that out three times we still have a good amount of resources left next let's say that my coworker decides hey for this j/s application let's take advantage of a third party you know let's say a cognitive API to do something like image recognition so you know let's say that we've got our third party service and we want to access that using maybe a Python application so he's created that service that accesses that third party API and with our node.js application we want to access that Python app to then access that that service if we wanted to do this in VMs I'm really tempted to basically create a VM out of both the JSO plication and the Python application because essentially that would allow me to continue to use the VMs that I have but that's not truly cloud native right because if I wanted to scale out the the j/s but not the Python app I wouldn't be able to if they were running in the same VM so to do it Trulli cloud native way essentially I would have to free up some of these resources basically get rid of one of these VMs and then deployed the Python application in it instead and you know that's not ideal but with the container based approach what we can do is simply say since we're modulars we can say okay just deploy one copy of the Python application so we'll go ahead and do that there's a different color here and that consumes a little bit more resources and then you know with those those remaining resources the great thing about container technology that actually becomes shared between all the processes running in fact another advantage if something if these container processes aren't actually utilizing the CPU or memory all of those shared resources become accessible for the other containers running within that within that hardware so with container based technology we can truly take advantage of cloud native based architectures so we talked about things like portability of the containers we talked about how it's easier to scale them out and then overall with this kind of three-step process and the way we push containers allows for more agile devops and continuous integration and delivery thanks for tuning in for this broad overview of container based technology as always we're looking for feedback so definitely drop a comment below and be sure to subscribe to stay tuned for more videos in the future thank you

Channel: IBM Technology

Views: 305,496

Rating: 4.9477706 out of 5

Keywords: containers, containerization, Kubernetes, Docker, Rocket, Linux, Linux kernel, c-groups, control groups, cloud foundry, runtimes, developer, node.js, application, app, vms, virtual machines, host os, operating system, hypervisor, libraries, guest os, agile, devops, portability, scalability, ibm cloud kubernetes service, manifest, yaml, image, runtime engine, docker engine, cognitive api, watson, python, cloud-native, architecture, continuous integration, continuous delivery

Id: 0qotVMX-J5s

Length: 8min 8sec (488 seconds)

Published: Mon Mar 18 2019