Windows Server development projects usually go through a common sequence of stages with a corresponding set of artifacts for the resulting app or service, and for each of them there is a standard set of best practices:
- Develop: Minimize the dependencies so the product can be run on the smallest OS configuration possible.
- Package: Make the dependencies known so that at deployment time ops can easily deploy on the smallest OS configuration possible. Otherwise, the default will likely be the largest configuration designed to avoid hitting a missing dependency in production.
- Configure: Use intent based configuration to avoid the need for special configuration, scripts, tools, etc., in order to get the OS and app or service properly configured.
- Deploy: Use modular, fragmented deployments meeting the dependencies rather than rolling them into a large monolithic install that deploys outdated components.
- Run: Use physical hosts, guest VMs, or containers to run the app or service.
- Test: Use unit tests to ensure quality.
- Secure: Ensure security is part of the app or service from the beginning.
In previous releases of Windows Server, there were no guidelines and instructions for how to accomplish these steps and what artifacts should be produced.
Windows Server 2016 clarifies this for developers and operators, using two models:
- Traditional ops model
- New model with Containers
Traditional model by Windows Server 2016 with inbox solutions across each area:
- Develop apps using the SDK targeting Nano Server or another Framework supported on Nano Server to enable deploying on the smallest installation option of Windows Server 2016
- Package apps using Windows Server App (WSA) installer in order to make a declarative, intent based installer.
- Configure apps using Desired State Configuration (DSC).
- Deploy apps and dependencies using Package Management (OneGet).
- Run apps on physical machines, in guest VMs or containers (both Windows Server Containers and/or Hyper-V Containers).
- Test PowerShell cmdlets using Pester.
- Secure apps with Just enough Administration (JEA).
These concepts apply to containers as well as to traditional ops models. For example, WSA allows developers to make the app or service available for their customers to deploy and run either physical, guest, or container. However, for apps or services that are fully container based, there is a container-only model that can be used as well:
- Develop apps using a Framework supported on Nano Server so that Nano Server could be used as the base of the container.
- Package apps as Container Images pushed to repositories.
- Configure apps using Container Images.
- Deploy container images from repositories.
- Run containers though orchestrators.
- Test apps using the test frameworks.
- Secure apps using multiple containers and JEA.
The container model allows leveraging the capabilities of the container infrastructure and integrating the necessary artifacts directly into the containers.
Windows Server 2016 resolves the interface between devs and ops by providing both a traditional and container model with prescribed solutions and artifacts for achieving the best practices for the app or service. Once again, the traditional model can be applied across physical, guest, or containers, providing the flexibility to run the app or service in any configuration. In case the app or service will only be delivered as a container and managed fully using the container model, then only container artifacts can be used.
This is the review of an article.
Source: technet.microsoft.com
