Announced earlier this year, the first semi-annual release of Windows Server has finally arrived. At the heart of the Windows Server 1709 release is a major update of the Server Core variant of Windows Server, with new versions of both Enterprise and Data Center editions. The new Windows Server favors a devops-based organization and enhances its support for containers and cloud deployments.
But to get the benefits of the new release, you’re going to have to forego the Windows Server UI, shifting to managing your servers with the command line (especially via PowerShell) and with remote user interfaces like the familiar RSAT and the new browser-based Project Honolulu.
It’s not a surprising move; Microsoft has been signaling a step away from the server GUI for some time now, and its command-line tools offer significant advantages in terms of remote management of multiple servers, using scripts. Mixing PowerShell and Project Honolulu won’t make management harder, and it will bring it in line with Windows Server’s various Unix-based competitors. It’ll also give Microsoft a new management baseline on which to add support for containers and other new ways of working with server operating systems.
To install Windows Server 1709, you have to do a clean install, because it moves you to a new, twice-yearly release channel. By forcing a clean installation, Microsoft is trying to make it clear that you’re stepping away from the 5+5 support model of the long-term support Windows Server 2016 to a new world of twice-yearly releases and 18 months of support.
New container features in Windows Server 1709
Microsoft is clearly targeting application and container developers with Windows Server 1709. New container base images include both Server Core and Nano Server; Server Core for “lift and shift” scenarios with existing applications, and Nano Server for new apps building on either .Net Core or Node.js. The container base images are also significantly smaller—a 60 percent reduction for the Server Core image and 80 percent for Nano Server—making it a lot quicker to deploy new containers on top of these images.
The “lift and shift” option is an interesting one, because it lets you containerize existing code with minimal work. There are, of course, architectural issues with building apps to run in containers, such as ensuring that all your application data is stored outside the container, so you do have to do some reworking. But in practice, it shouldn’t be too difficult to make the appropriate changes – especially if you’re using Windows Server’s or Azure’s storage tools and APIs.
Windows Server’s new schedule fits the devops mentality
A new Windows Server release every six months won’t be to everyone’s taste. Although you’ll be able to skip a release (for example, jumping from 1709 to 1809, ignoring 1803), that won’t change the fact that Windows Server will get regular significant updates with only 18 months of support for each release. Windows Server’s new cadence is perhaps best suited to organizations that have already made the shift to a devops-driven process, where applications drive the overall strategy.
The devops approach is certainly one that’s in tune with cloud-first development. Windows Server has needed to compete with Linux’s rapid development schedule for some time, especially where container images are used. That’s the main reason for the bundled Nano Server’s rethink in Windows Server 1709; there’s no point in a container host supporting infrastructure roles, especially when the main operating-system builds are also getting more lightweight.
Still, Microsoft’s changes to Windows Server will be a challenge for system administrators used to three- or five-year releases. For them, there’s still the Long-Term Servicing Channel (LTSC), which will continue to be released the way Windows Server always has been.
You can even mix Windows Server releases in your datacenter, using LTSC for legacy applications and Windows Server 1709 and future releases for new builds and cloud use. Although the Windows Server 1709 and later releases do include infrastructure roles, you should use these twice-yearly releases for application hosting in VMs and as container base images. It makes sense to keep using Windows Server LTSC infrastructure servers for VM hosts, for storage, and for Active Directory. A mixed approach to server deployments makes sense because, after all, your infrastructure servers shouldn’t change once deployed, beyond getting security updates.
This split model makes even more sense if we separate infrastructure ops from devops. In the devops world, relatively rapid changes to base operating systems aren’t a problem, because they’re only another element of your continuous integration pipeline, along with your code and the rest of your software-defined infrastructure.
Also gone is the old system of betas and community previews. Some selected customers will still get access to TAP builds, but everyone else should join the Windows Insider program to get a head’s up on future changes. In the new twice-yearly update cadence, it’s more important than ever to participate in the Windows Insider program, because Windows Server’s new schedule will demand rapid testing to certify applications before each new release deploys.
Even so, testing shouldn’t be onerous. After all, there’s a big difference between twice-yearly incremental releases and big bang product launches every few years. With far fewer new features in each Windows Server new build going forward, their impact on existing applications is likely to be minimal.