Announcing the Windows 2016 stack on Cloud Foundry
A William Martin
With the recent cf-deployment version 1.22, I’m pleased to announce the general availability of Cloud Foundry’s support for Windows Server 2016 (actually, version 1709) and its native Windows container technology.
Cloud Foundry developers can now use the windows2016 stack to push .NET applications, use more CF features (i.e. cf ssh), and expect a more elastic, scalable, stable experience on Cloud Foundry, due to the advantages afforded by Windows Server Containers. This is an important step for a sustainable runtime and platform experience for .NET.
Operators can upload a Windows Server version 1709 stemcell from bosh.io and bosh deploy with the windows2016-cell.yml ops file. Developers can then cf push with the windows2016 stack and hwc_buildpack.
A Giant Leap for .NET + Cloud Foundry
This effectively brings the .NET and Cloud Foundry technology ecosystems closer together, giving .NET apps a sustainable opportunity to leverage the full benefits of CF’s evolving runtime while consuming the Windows and IIS capabilities they also need. One can even use cf ssh to debug a cf-pushed .NET app remotely from Visual Studio – to be demoed at CF Summit NA this week!
With the previous 2012 R2 stack (powered by IronFrame) and older Diego MSI, the experience for .NET apps and Windows deployment was rather sub-par. To address this, the CFF Windows teams have been working towards a level of “pragmatic parity” between the capabilities available for apps hosted on Linux and those on Windows. We think we’ve finally achieved the right foundation to serve many more CF features in the future in both worlds.
As more is now possible for .NET on CF, at the same time, the Windows runtime has become simpler. For example, it now uses the same app lifecycle as Linux-hosted apps, which means multiple buildpacks landed for .NET apps without extra work. This shows an important aspect of sustainable “pragmatic parity” between Linux and Windows moving forward.
What can .NET apps use on Cloud Foundry now?
The latest features are cf ssh, accurate application CPU metrics, full container file system, context path routing, and multiple buildpacks. However, the benefits afforded by Windows containers are more than in the list of working features, but shine in the actual behavior of the platform while running .NET apps.
For example, on the 2012 R2 stack, greedy apps could easily starve others of CPU and even consume the cell itself. Now, since CPU shares are available, apps on the windows2016 stack don’t suffer from noisy neighbors and are as elastic and scalable as Linux apps (but with a bit more memory overhead on Windows of course).
How was this made possible?
The new Windows has containers! (They’re analogous to those on Linux but naturally not quite like them.) Fortuitously, this means the new Windows stack can now use the same Garden infrastructure as Linux Diego cells, in which it swaps out runc for winc, an OCI-compliant container plugin for Windows, authored by the CF Garden Windows team. The stack also ships with groot-windows, a Garden image plugin. For details, there’s a CF Summit session coming up about it this Friday.
What is Windows Server version 1709?
This is a derivative of Windows Server 2016, delivered as part of Microsoft’s “Semi-Annual Channel” (SAC) releases of Windows Server. You can think of them similarly to the non-LTS versions of Ubuntu (16.10, 17.04, 17.10, etc.). While they may seem merely another version schema, the advances in the containerization characteristics in each SAC release are quite significant.
Pinning first to “version 1709” aims to deliver to CF the best isolation and networking available from Windows containers. To continue along this track, the CF Garden Windows team has started to develop against “version 1803” with an eye towards the upcoming Windows Server 2019. We hope these versions will have what’s needed to implement container-to-container networking and more.
What about AWS?
If you look on bosh.io, you’ll notice the AWS stemcell (under “Windows 2016”) is conspicuously missing. Unfortunately, AWS doesn’t yet publish a Windows Server v1709 AMI, but Azure and GCP are good to go. (For vSphere, you still need to build your own stemcell, but CF BOSH Windows continues to work on improved ways of doing so.) While we’re lobbying for AWS to ship a 1709 AMI, Amazon still hasn’t given any timeline for its availability, and for that we could use your help.
There are so many Cloud Foundry contributors to thank in this year-long effort. To call out a few:
CFF Garden Windows / BOSH Windows project lead