Netherlands: Software

Introductie Windows Server 2016

Issue link: http://hub-nl.insight.com/i/692748

Contents of this Issue

Navigation

Page 138 of 173

129 C H A P T E R 6 | App Plat create the new application container, and it is provisioned almost immediately because all of the dependencies are already in place. If you have an application container that depends on a different application framework layer as well as on the original Windows Server Core base layer, you can simply pull the different application framework layer from an image store and start the new application container. Why use containers? Containers provide some distinct advantages over the traditional model of deploying an application into a VM or onto a physical host. The first advantage has to do with development. A general pain for developers when they are building applications revolves around moving the application from a development environment, to test, and then to production. Developers must spend a lot of time and effort checking the application's dependencies as it moves through the environments. However, when an application is deployed to a container, you can move the container between environments because it is isolated and all binaries are self-contained within the container itself. Another reason for using containers is to achieve higher scale versus deploying an application to a VM. To achieve the different environments of development, test, and production in a VM model, you need at least three VMs; in a container model you need only one. That single VM, running a container manager, can run three containers simulating development, test, and production environments. With containers, you need fewer VMs to run your environments and you can achieve significantly higher scale in your cloud environments. Containers also allow for rapid deployment and operation of applications. Unlike VMs, containers don't have an underlying operating system, as such. Think in terms of deployment. If you want to create a new application or scale the existing application to support more load, you just load a new container; the operating system is already in place. This means that the time spent waiting for a container to deploy or scale up is significantly shorter than with a VM because you are never waiting for the operating system to start up. Windows Server containers versus Hyper-V containers Two types of containers will be available in Windows Server 2016 Technical Preview: Windows Server containers Hyper-V containers You can consider Windows Server containers to be the equivalent to Linux containers. Windows Server container types isolate applications on the same container host. Each container has its own view of the host system, including the kernel, processes, file systems, the registry, and other components. In the case of Windows Server containers, they work between the user-mode level and the kernel-mode level. Hyper-V containers are based on a container technology that is rooted in hardware-assisted virtualization. With hardware-assisted virtualization, Hyper-V containers' applications are provided a highly isolated environment in which to operate, where the host operating system cannot be affected in any way by any running container. Figure 6-7 shows what the layout might look like in relation to the two container technologies that are available in Windows Server 2016 Technical Preview.

Articles in this issue

Archives of this issue

view archives of Netherlands: Software - Introductie Windows Server 2016