In the first post of this series I highlighted that with Windows Server 2016 there are some feature differences between the Standard and the Enterprise Editions that might get lost in some of the messaging, so in this series of posts I’m going to be highlighting the feature set of Windows Server 2016 Standard, and will include information from a few different resources, but the primary one is the Windows Server 2016 Technical Preview 5 Feature Comparison. As mentioned in the first post of the series, these will focus on what’s new from a Windows Server 2012 R2 perspective, rather than Windows Server 2008 R2 or Windows Server 2012 perspective. I will focus on those later if needed.
Following on from the previous post in the series, which was on Management Remote Desktop Services, today’s topic is Application Development, and following you will find the information from the Feature Comparison Guide.
Please note that these are subject to change and are based on Windows Server 2016 Technical Preview 5. If any adjustments need to be made, please leave a comment.
Windows Server 2016 resolves the interface between developers and operators by enabling both traditional and container models for application development, with prescribed solutions and artifacts to achieve best practices for developing and operating the application/service.
- The traditional model can be applied across physical, guest, or containers, providing the flexibility to run the application/service in any configuration.
- The container model requires the application/service to be only delivered and managed as a container.
In addition to developing the application/service code, each development and operational model requires a set of artifacts so that operations can benefit from the Windows Server 2016 Cloud Application Platform.
|Phase||Traditional Model||Container Model|
|Develop||Nano Server SDK allows targeting the smallest server footprint.||Nano Server SDK allows targeting the smallest server footprint.|
|Package||Windows Server App (WSA) installer||Container Images|
|Configure||PowerShell Desired State Configuration||Container Images|
|Deploy||Package Management (OneGet)||Container Images|
|Run||In physical, guests, or containers (Windows Server and/or Hyper-V)||Containers through orchestrators|
|Secure||Just Enough Administration (JEA)||Multiple containers, and JEA|
Microsoft, Docker Inc and the Docker Community have partnered to provide Docker with support for new container technologies in Windows Server 2016. Developers and organizations that want to create container applications using Docker will be able to use either Windows Server or Linux with the same growing Docker ecosystem of users, applications and tools. Windows containers provide operating system level virtualization enabling multiple isolated applications to be run on a single system. There are two different types of container runtimes included with this feature, each with different degrees of application isolation. Both Windows container runtimes are managed by the same API layer providing the same management primitives and utilizing the same configuration format thus enabling customers at runtime to choose the level of isolation required for the specific container instance being started. Both container runtimes can be managed with PowerShell or Docker and Windows Server 2016 Nano Server is the recommended container operating system for Windows.
Windows Server Containers
Windows Server Containers provide operating system level virtualization that allows multiple isolated applications to be run on a single system. Windows Server Containers address density and startup performance scenarios and achieve isolation through namespace and process isolation.
Process Grouping (known as Job objects in Windows) is a mechanism of classifying and operating on a set of processes, as single unit. Job objects have existed in Windows since Windows 7/Windows Server 2008 R2 largely as a mechanism for applying basic resource controls on processes/sets of processes, this functionality was part of the foundation for Windows Server Containers.
Namespaces isolation describes a form or virtualization where operating system wide or global configuration can be instanced or virtualized to a given set of processes, as referenced by job objects. In order for applications inside containers to work properly there are a number of namespaces that must be virtualized, some of the major ones include: storage, registry, networking, object tables and process tables. Each container has a virtualized view of these namespaces limiting its ability to see global properties of the container host or other containers running alongside it.
Hyper-V Containers support the same features as Windows Server Containers and additionally addresses isolation and kernel variation, lending itself to complex application development and hostile multi-tenancy scenarios. Hyper-V Containers encapsulates each container in a lightweight virtual machine.
Shared kernel container environments are not designed for “hostile” multi-tenancy scenarios while Hyper-V Containers are naturally designed for this type of multi-tenancy and have their root in hardware isolation properties. Examples of “hostile” multi-tenancy scenarios include:
- Highly regulated environments.
- Hosting environments.
- Competing workloads.
Hyper-V Containers encapsulate each container in a lightweight virtual machine, providing the same level of isolation provided to virtual machines, addressing kernel isolation and variation requirements while providing the same density and startup performance associated with a container.
Docker Engine for Windows
Docker has emerged as the de facto container experience for customers and Microsoft has partnered with Docker Inc to provide Docker with support for new container technologies in Windows Server 2016. Windows containers is crosscomplied with Linux to provide the same experience and common Docker engine. For customers this means that Windows containers supports the Docker experience including the Docker command structure, Docker repositories, Docker datacenter and Orchestration. In addition, Windows containers extends the Docker Community to provide Windows innovations such as PowerShell to manage Windows or Linux containers.
Emulated Domain Join
In a build after Windows Server 2016 Technical Preview 5, Windows Server will support Emulated Domain Join for Windows containers. Emulated Domain Join allows services within a container to run using an Active Directory identity through the use of the same Group Managed Service Account (gMSA) experience customers use today. Emulated Domain Join allows the container to provide applications the ability to authenticate to Active Directory using a gMSA without the overhead of startup, object and management overhead traditionally associated with Group Policy or full domain membership. This allows in-house or web applications to use Windows Integrated Authentication and supports integrated authentication for SQL workloads. Domain credentials are not stored in the container image (data at rest). Since the identity is being provided to the container image as its deployed, it can be safely stored within a repository and deployed to multiple Active Directory domains and environments, supporting development, staging and production scenarios.
Nano Server Developer Experience
Nano Server is the recommended application platform for all new Server applications. Targeting Nano Server will allow applications to take advantage of all of the Nano Server benefits at runtime, including running physical, virtual, or in a container.
Nano Server has the same API surface available for running applications. The Nano Server API surface is a subset of what is available in Server Core and Server with Desktop Experience. As a subset, any application, tool, or agent that is written to run on Nano Server will run without modification on Windows Server 2016 Core or Server with Desktop Experience. Nano Server also supports .NET Core for running managed code and ASP.NET Core for web apps.
Nano Server offers a great developer experience through a Visual Studio C++ project template, which provides IntelliSense and error squiggles support. Full remote debugging from Visual Studio complete the developer experience.
There are also two tools available that can be used to scan existing binaries to identify APIs not included in Nano Server:
- Nano Server API Scan – Scans native code to identify Win32 APIs that are not included in Nano Server. In many cases, this tool will suggest replacement APIs. For more information:
- API Portability Analyzer –Scans managed code to identify which .NET profile the APIs are included in. For Nano Server you need to use the .NET Core profile. For more information: https://www.microsoft.com/enus/download/details.aspx?id=42678
Windows Server App (WSA) installer
The Windows Server App (WSA) installer is based on declarative APPX. In addition to Nano Server support, WSA will be available on Server Core and Server with Desktop Experience to help deliver more consistent and reliable
installs/uninstalls. With WSA, developers declare install actions, intra-package dependencies, and Server extensions in the WSA manifest. WSA does not allow custom code during install and requires online install. With WSA, you can deploy applications and their dependencies via APPX PowerShell cmdlets or Package Management.
WSA is not suitable when the install process requires a GUI, interactive user input, custom code.
The Pester test framework was initially developed as an open source project. It is now built into Windows Server 2016 and Windows 10
Just Enough Administration (JEA)
Just Enough Administration (JEA) provides a Role-Based Access Control (RBAC) platform through PowerShell. It allows specific users to perform specific tasks without giving them administrator rights.
Internet Information Services 10 (IIS 10)
IIS on Nano Server
IIS 10.0 is supported on Nano Server in Windows Server 2016 with support for ASP.NET Core.
- Individual IIS features can be added to a Nano Server installation of IIS 10 using the PowerShell IISAdministration module commands (remotely), the AppCmd.exe utility (remotely) or editing the IIS configuration store directly.
- Web sites and related configuration tasks like binding HTTPS certificates can be performed using PowerShell or remote command-line tools.
Wildcard Host Headers
IIS 10.0 now supports Wildcard Host Headers, enabling admins to setup a webserver for a domain, e.g. contoso.com and then have the webserver serve requests for any subdomain.
IISAdministration PowerShell module
IIS 10.0 introduces IISAdministration, a new PowerShell module for managing IIS.
- IISAdministration will scale better in scripts that take a long time to run with WebAdministration.
- You can now get a direct reference to an instance of Microsoft.Web.Administration.ServerManager object and do anything that you can do in Microsoft.Web.Administration namespace alongside your scripts.
- PowerShell pipeline compatibility was the driving force behind the design of many cmdlets. As such, IISAdministration works much better with PowerShell Pipeline.
Windows Server 2016 adds support for HTTP/2 protocol. This allows numerous enhancements over HTTP/1.1 such as more efficient reuse of connections and decreased latency, improving web page load times. HTTP/2 support in Windows Server 2016 is added to the Networking stack (HTTP.sys) and integrated with IIS 10.0, allowing IIS 10.0 websites to automatically serve HTTP/2 requests for supported configurations.