From virtual machines to containers

- [Robert] When deploying an application today, we have a number of choices on exactly how we manage and operate that application. Classically, we can start with the Bare Metal Server. This is a classic server, something that you could buy, place into a data center and turn on, and you would then manage the operating system, and potentially a number of applications, and their dependent binaries and libraries and components, and of course, you had to deal with potential collisions of different libraries, or different binary components, run on that same server. We moved, to make it simpler to deal with in a data center management perspective, when we went to a Virtual Server. We still have, at some point, the physical machine, the actual Hardware, and the Host Operating System, and then there's a new layer of management, called a Hypervisor, which abstracts away the physical resource, and acts as if there was a virtualized version of that physical resource. In this case, we're often just running a single application, the binary and libraries it requires, so we avoid the collision potential between the different applications that we might have seen in the Bare Metal Server, but we still have to manage, not just one operating system, the underlying physical operating system, but another one for the Virtual Server as well, and so, there are some security concerns that people have had, just because you have all these additional resources to have to manage, and that led to looking at an even more efficient model, which is the Container model. Now the Container model really focuses on the application itself, and what we want to look at is the application, and it's binaries and libraries, the resources it needed in order to run that application sitting on top of, usually an engine, a service that actually enable that Container to run. So, this is a little closer to the Bare Metal Server. We have one piece effectively removed from the equation, which is the virtual operating system, and we have still this inner section or interaction layer, the Docker Engine in this particular diagram, that enables our Container to run on top of the Host Operating System. What's missing from all of these stories, is the application management resource it sits on top. The Bare Metal Server, it was often a set of tools, things like Ansible and Puppet, that would actually manage the application. In the Virtual Server space, we were managing the Virtual Server, it's operating system and applications, again, also often using these same class of tools, plus the operations model that helps us manage the Hypervisor and the Virtual Server on top, and lastly we get to the Container world, where we're looking at a number of different tools, including the darling of the industry today, Kubernetes, but there are a number of services that just focus on simplifying the process of operating an individual Container, sometimes still giving us control at the Docker Engine level, or at that Container management layer, but often simplifying it to the point where we think of the Container as our application, and that's all we have to worry about. Somebody else is going to take care of that Hardware, Host Operating System, and even the Container management layer at that Docker Engine component. In our case, we're going to look at the Azure Container service, Azure Container Instance Management, ACI, as a way of managing those Containers.