M
Microsoft Windows Server
Guest
This post was authored by Andrew Mason, Principal Program Manager on the Nano Server team.
There has been a lot of press on Nano Server and Containers as new technologies coming in Windows Server 2016. In this blog post we’ll discuss how these two technologies are core pieces of the Windows Server 2016 developer/DevOps solution, discuss the full inbox stack, and provide links to additional resources to get you started. In addition to this post, at Build 2016, Taylor Brown and I presented a session with demos on this topic. The recording is available on Channel9.
Windows Server development projects generally follow a common set of tenants with a corresponding set of artifacts for the resulting app or service. These are develop, package, configure, deploy, run, test and secure. For each of these there are a common set of best practices:
The challenge has been that in previous releases of Windows Server, there was no clear choice, guidelines, or even opinion on how to accomplish these and what artifacts you should produce.
For example, for packaging you could use an MSI, xcopy deployment, WebPI, etc. and for configuration you could use a config file (in a variety of formats), registry entries, a custom database or binary file like the IIS metabase in IIS 6 and earlier and so on.
With Windows Server 2016 we have a clear point of view for developers and operators, using two models:
With these, Windows Server 2016 resolves the interface between devs and ops.
Let’s look at the Traditional model first, where for the first time Windows Server 2016 provides inbox solutions across each area:
In addition to developing your app or service code, you need to produce the artifacts necessary to use the above solutions so that ops can take advantage of the benefits these provide as well as have consistency across apps and services.
As noted above under Run, these concepts apply to containers as well if you plan to run them using traditional ops models. For example, if you plan to make your app or service available for your customers to deploy and run either physical, guest, or container then WSA is the correct packaging solution to use.
However, for apps or services that are fully container based, there is a container only model that can be used as well:
With the container model you can leverage the capabilities of the container infrastructure and integrate the artifacts you need for your app or service directly into your 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 you to achieve the best practices for your app or service. As mentioned above, the traditional model can be applied across physical, guest, or containers, providing the flexibility for you or your customers to run your app or service in any configuration. If your app or service will only be delivered as a container and it will be managed fully using the container model, then you can use only container artifacts. Which set of artifacts you deliver with your app or service will depend on which model you and your customers prefer.
Continue reading...
There has been a lot of press on Nano Server and Containers as new technologies coming in Windows Server 2016. In this blog post we’ll discuss how these two technologies are core pieces of the Windows Server 2016 developer/DevOps solution, discuss the full inbox stack, and provide links to additional resources to get you started. In addition to this post, at Build 2016, Taylor Brown and I presented a session with demos on this topic. The recording is available on Channel9.
Windows Server development projects generally follow a common set of tenants with a corresponding set of artifacts for the resulting app or service. These are develop, package, configure, deploy, run, test and secure. For each of these there are a common set of best practices:
- Develop: Minimize your dependencies so you can run on the smallest OS configuration possible.
- Package: Know your dependencies so that at deployment time ops can easily deploy on the smallest OS configuration possible. If ops has to guess at the configuration needed, the default will likely be the largest configuration so they don’t have to worry about 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, componentized deployments expressing your dependencies rather than rolling them into a large monolithic install that deploys outdated components.
- Run: Use physical hosts, guest VMs, or containers to run your app or service.
- Test: Use unit tests to ensure quality.
- Secure: Don’t let security be an afterthought or add-on, ensure security is part of your app or service from the beginning.
The challenge has been that in previous releases of Windows Server, there was no clear choice, guidelines, or even opinion on how to accomplish these and what artifacts you should produce.
For example, for packaging you could use an MSI, xcopy deployment, WebPI, etc. and for configuration you could use a config file (in a variety of formats), registry entries, a custom database or binary file like the IIS metabase in IIS 6 and earlier and so on.
With Windows Server 2016 we have a clear point of view for developers and operators, using two models:
- Traditional ops model
- Emerging model with Containers
With these, Windows Server 2016 resolves the interface between devs and ops.
Let’s look at the Traditional model first, where for the first time Windows Server 2016 provides inbox solutions across each area:
- Develop apps using the SDK targeting Nano Server or your favorite 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 so that you have a declarative, intent based installer.
- Configure apps using Desired State Configuration (DSC).
- Deploy apps and dependencies using Package Management (aka OneGet).
- Run apps on physical machines, in guest VMs or containers (both Windows Server Containers and/or Hyper-V Containers).
- Test your PowerShell cmdlets using Pester.
- Secure apps using Just enough Administration (JEA).
In addition to developing your app or service code, you need to produce the artifacts necessary to use the above solutions so that ops can take advantage of the benefits these provide as well as have consistency across apps and services.
As noted above under Run, these concepts apply to containers as well if you plan to run them using traditional ops models. For example, if you plan to make your app or service available for your customers to deploy and run either physical, guest, or container then WSA is the correct packaging solution to use.
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 your favorite Framework supported on Nano Server so you can use Nano Server as the base of your 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 your test frameworks.
- Secure apps using multiple containers and JEA.
With the container model you can leverage the capabilities of the container infrastructure and integrate the artifacts you need for your app or service directly into your 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 you to achieve the best practices for your app or service. As mentioned above, the traditional model can be applied across physical, guest, or containers, providing the flexibility for you or your customers to run your app or service in any configuration. If your app or service will only be delivered as a container and it will be managed fully using the container model, then you can use only container artifacts. Which set of artifacts you deliver with your app or service will depend on which model you and your customers prefer.
Continue reading...