During the latest edition of DockerCon, Microsoft shared multiple improvements made in the .NET Core over the past year, all aimed at enhancing the experience of using .NET and Docker together.
All of the improvements focused on .NET Core 3.0. The most foundational change was the reduction of the memory the .NET Core runtime (CoreCLR) uses by default. The CoreCLR manages the execution of all .NET Core programs; the memory it uses by default is the amount of memory initially allocated when a .NET program is executed. Lowering the default CoreCLR memory usage means increasing the container’s memory usage efficiency without changing the default .NET Core configuration.
With the recent modifications, .NET Core 3.0 now also supports Docker resource limits (memory and CPU). Resource limits allow controlling how much memory or CPU a container can use. These limits are described in terms of amount for both memory and CPU (i.e., 128MB of memory, or two CPUs). When memory limits are set, .NET Core 3.0 changes its behavior accordingly: the garbage-collector heap size is capped at 20MB or 75% of the memory limit. In the case of CPU limits, the value set on Docker is rounded up to the next integer value. This value is the effective maximum number of CPU cores used by CoreCLR.
The improvements also affected the higher-level usability of .NET in Docker containers. As per community request, Microsoft added PowerShell Core as a self-contained application to the available .NET Core SDK Docker container images. In addition, .NET Core container images are now available via Microsoft Container Registry (MCR). This allows using Microsoft Azure as the official source of Microsoft-provided container images, and as a global content distribution network (CDN) to deliver container images according to the user’s geographic location.
While .NET Core is supported by multiple platform distributions and versions, the list of supported distributions for Docker is much smaller. At the moment, only specific versions of Alpine, Debian, and Ubuntu distributions are supported, along with all Windows Nano Server versions. The .NET Core team is in the process of adding support for ARM64 on Linux.
Richard Lander, program manager at the .NET team, said in the blog post about the improvements: “We are invested in making .NET Core a true container runtime. In past releases, we thought of .NET Core as container friendly. We are now hardening the runtime to make it container-aware and function efficiently in low-memory environments.”
The .NET community received well the framework performance improvements. In addition to the blog post, Microsoft and Docker speakers presented multiple sessions on DockerCon 2019 related to .NET development using containers. One of these sessions focused on containerization of legacy .NET applications, which is a theme of particular interest for companies with a long history of development using .NET . This session was hosted by a Docker representative, and it illustrates the recent company efforts of stimulating the use of containers by the industry and supporting the developers’ community.
Microsoft’s efforts seem to align with Docker’s intentions, as well as with other initiatives from different development communities. Other Microsoft product areas are following the same trend: earlier this month Microsoft released a new remote development extension for VS Code, which enables seamless development using remote containers in conjunction with a local instance of VS Code.
