[MUSIC] Hi, my name is David Shade. I'm a senior Cloud Solution Architect at Intel, and I'd like to talk with you today about virtual machines and containers 101. This is part of the Cloud Technology module. So, we're going to cover the basics of virtual machines and containers. We're going to talk a little bit about some of the central qualities or aspects of both virtual machines and containers. We're going to talk a little bit about, image repositories, and some of the benefits we get from these technologies, and then we'll wrap up. All right, you may be wondering why we have virtual machines and containers, and in order to explain that, you need to do a little history lesson. And so, in the beginning we had applications that ran on servers, I won't do the voice the whole way through that would be annoying. But, we had one application running on a single server and they were pretty much dedicated servers. Along the way, Moore's law kicks in, and we have more transistors, 18 to 24 months. We doubled the number of transistors for server processors. We run that cycle a few times, and we now have incredibly capable server platforms. And they have a lot of extra capacity when you run dedicated applications on them. And so, really smart people came up with a great idea which was to figure out how to run more than one application on a single server. The first key technology in this space is that of a hypervisor and virtual machine. The hypervisor is a layer that sits on top of your operating system on the server, and allows you to load a file called a virtual machine. That fully describes, an operating system environment, the full set of run times, and the application environment for a server. From the outside looking in, it's a file running on a hypervisor, from the inside, it is a full virtual server. The application and the environment, thinks that it is a fully dedicated server, on the outside we see it as a virtual machine. The second key technology in this space for putting more than one application on a single server, is that is called containers. Now, the virtual machine environment, is this fully encapsulated server environment. And what people noticed is that they didn't need, for all applications that they wanted to pack onto a single server. They didn't really need every aspect of that server to be fully separate, right? You can share, a lot of the same environmental variables, like parts of the linux kernel etc. And so for a container, what you have instead is just the application, and some of the runtime environment for that application. And that gets translated by a container manager, and that sits on top of your of your operating environment. For both of these technologies, virtual machines and containers, the way you specify the amount of resources that a virtual machine or a container will use, is by specifying the number of virtual CPUs. The amount of RAM, the amount of storage, and the kind of networking that the virtual machine or container requires. For virtual machines, there's a few use cases we care about. The first of which I mentioned which was packing multiple applications onto a single server, to increase your overall server utilization. That's a great way to get better total cost of ownership. One of the other key factors for virtual machines, is related to application isolation. Because this virtual environment is complete for a virtual machine, we can operate things in a virtual machine that are completely isolated from everything else in the server environment. And that's a very handy feature, the third use case that we see a lot of use for virtual machines, is migrating legacy applications. Lots and lots of IT environments have a legacy application that requires an antiquated version of a database. Or an old OS, or a driver, that doesn't exist anymore or something like that. And so what we can do with virtual machine is we can encapsulate all of those legacy requirements for that application, package it up in a VM. The application still thinks it's running on that old version of hardware software, and we're able to move it and run it as a virtual machine on a brand new piece of hardware or in the cloud. So those are three key use cases for virtual machines. In terms of our typical compute environment, where typically a virtual host would be a two socket Xeon scalable. Maybe with 192 or 384 gigabytes of DRAM, our network and storage environment, we're usually looking at distributed storage here. That could be often with NVMEs, and or ss sorry, Optane SSDs for caching. When we look at popular vendors in this space, the number one enterprise vendor in the virtual machine space or hypervisors space is VMware. And they have years and years of enterprise IT trust and execution, very popular vendor in the open source space. We talk about Linux and the kernel virtual machine KVM, right is is a very popular hypervisor in that space. When we think about using virtual machines in a public cloud, or what services in a public cloud will give us access to virtual machines. We think about the AWS EC2 as your virtual machines, pretty much every infrastructure as a service. Cloud service provider will have a very strong offering related to hosting virtual machines. If you are looking for kind of the latest information on, advantages that Intel can provide in and around virtual machines, and VM hosts, please see the link for the latest intel select solutions content. Next let's talk about the essentials for containers, for container use cases, there are a couple that really stand out. One is, containers are the typical building block for cloud native applications. And so, when we think about a cloud native application, it's typically a set of containers that are, put together to, provide the functionality for a richer, more full application. The other use case for containers that's very popular is using them as functions. A function is something that is a short duration sort of application. It's triggered by an event, typically or perhaps a time of day, and it completes its job so to speak and then terminates. So, when we think about a container host, infrastructure to run containers on, that would typically be a Xeon scalable two socket server. With a fairly large amount of RAM, maybe 384 gigabytes for storage. Often times we'd be looking at a distributed storage environment that could be, fairly high performance with NVME drives for instance. And maybe even caching with an Optane SSD. So, popular vendors for containers would include Red hat, with their openshift products, which contain orchestration for containers. Docker is the most popular vendor by far, but there are also open source container runtime applications like container D. In terms of disruptive technologies in the container space, Optane PMEM is being tested and evaluated and is showing some real promise in this space. When we talk about using containers in the public cloud, oftentimes we're thinking about something like AWSs, elastic container service. ECS or the elastic kubernetes service EKS, Azure containers also is extremely popular in this space. And again for more information on kind of the latest for configuring a container host. And looking at some of the contributions that Intel has made in this environment, feel free to check the latest on the Intel Select Solutions link there. One key item that makes containers and virtual machines, so incredibly powerful, is the idea or the ability to reuse what you have done. So you can save a container or virtual machine image and restart that recipe again whenever you want. But, even more powerful, both for VMS and containers, there are image repositories of containers or virtual machines. That have been configured by somebody else and made available for others to use. Let me start with AWS first, in AWS for use in EC2, there are Amazon machine images. Thousands and thousands of pre configured operating system environments, with maybe development environments already installed and configured. And oftentimes applications like web servers like NGINX, or databases for instance Oracle or SAP. All have Amazon machine images pre configured with, the operating system environment as well as the applications installed and pre configured. And so when you go to use, those AMIs, it can give you a significant head start in terms of having a pre configured operating system. That you don't need to install from scratch, having pre configured runtime library and application environments. That give you a significant head start and getting to the thing that you want to do. On the container side, the most popular and probably the largest repository for container images, is the Docker Hub. I saw online that there are more than a million container images stored in the Docker Hub. The hub is really important because again, just like the virtual machine images that I described, these have run times. They tell you the operating system they're expecting, the host to be, and they they have runtime environments and applications pre configured. And allow you again a huge head start or a huge advantage in using and reusing container images that have been developed by either yourself or your organization, or by third parties. Let's talk for a second about the benefits of virtual machines and containers. Both virtual machines and containers are popular techniques for running multiple applications on a single physical server. However, virtual machines are typically preferred for, running applications in a multi tenant environment, where we want full isolation and security. For stateful applications that require snapshots and backups. And, as I mentioned the ability to move a legacy app, off of older dedicated hardware into a newer environment, is really great for virtual machines. And remember of course that the physical operating system environment could be Linux. And our guest OS for our virtual machine can be Linux or it could be any other operating system environment. So, we have a great deal of flexibility on the virtual machine environments. For containers, we typically prefer those if we're developing new applications in the cloud because they're lightweight. They load quickly and we can string together these small functions or small microservices together to form very powerful apps very quickly in the cloud. If we're looking at functions or stateless applications, that's a great use case for containers. Again if we are running either a single tenant or on prem, this is a great thing for containers. Because they are lighter weight, and faster to load and execute than virtual machines. And if we really want to maximize the number of applications that we can run on a single server. Because containers are lighter weight since they don't have to have the full guest OS, they tend to be more efficient. All right, let me spend a few minutes summarizing kind of our comparison of VMS and containers. I don't think I'm going to give you a lot of new information here, but I will reiterate some of the key attributes here. And this is a good reference chart to take away, and keep handy for references to virtual machines and containers as you're working with your customers. So when we talk about virtual machines, the boot time for a virtual machine it's not as long as a physical server, but it can be measured in a minute or minutes. Virtual machines execute in a hypervisor which sits on top of your host OS in terms of how much space they take. You've got a full guest Os image, plus the runtime environment plus the application environment and data, and so they're fairly large. In terms of isolation, virtual machines provide excellent isolation from other applications that are running. With respect to ease of deployment, virtual machines running in hypervisors, is a very mature technology, not considered risky, well proven. Most enterprise environments and all clouds offer hypervisors and virtual environments. In terms of code reuse, there are plenty of automation tools like Ansible, puppet etc that allowed for you to create new VMs. And especially when an existing image, it wouldn't be available in a repository. In terms of OS portability, our guest OS as I mentioned can be any operating system environment and doesn't need to be, the same as the host OS on the machine. With respect to maintenance and updates, you've got to maintain both the host OS and the VM specific environment to your standards. With respect to containers, they load faster usually the container loading time is measured in seconds. It runs on not a hypervisor but a container runtime engine. We don't have to store the full guest OS, we have just the libraries and run times and applications. With respect to isolation our containers are smaller and they share the OS kernel. So, only really appropriate for single tenant kinds of use cases. In terms of ease of deployment, Docker has this massive Docker Hub image repository. Which is widely used as a resource as a place to start for folks developing with containers. Again, lots of automation tools for developing, deploying the full code lifecycle for containers from Docker and others. In terms of scheduling, on the VM side of course we have vSphere, Openstacks, Nova and IS consoles like EC2. On the container side, popular ways to schedule containers, Mesos, kubernetes, Docker swarm, Openshift from Red hat. And of course I asked consoles like ECS would be a great way to schedule containers. More on that in the orchestration course, which Fulcan Fong will be sharing later. For OS portability, our containers need to be, running on essentially the same are expecting the same host OS environment that they're running on. And you have less to update in terms of keeping up with, application and runtime and library environments. All right, so in summary, virtual machines and containers are both great techniques, that allow multiple applications to run on a server. They allow us to, specify CPU memory and storage requirements for our application to run. They VMS provide better isolation, for multi tenant environments. Containers are smaller, and typically you can get more applications running on a single server. The Docker hub, as I had mentioned, provides thousands and thousands of pre configured container images, and there are virtual machine repositories that do that as well. They provide really rapid development for applications, and give you both community and commercial, contributed images to start from. As a provider of standard high volume servers, it's incredibly important to Intel. To make sure that our customers are getting, the best benefit from our hardware while running applications in VMS and containers. We have put a lot of energy into understanding how to optimize the performance as well as the TCO of these key environments. [MUSIC]
