What are containers
A container image is a standalone, executable software package that brings all its dependencies (with the exception of the operating system). If an image is instantiated, a container is created that works according to the software it contains. An image can be instantiated as often as desired and thus any number of containers can be created.
The main advantages of containers are the abstraction of the operating system without, however, inserting a much slower hypervisor, such as Hyper-V or VMWare. And because of their portability and small size, container instances can be created quickly and thus scale large cloud native applications with many microservices.
Support for Linux and Windows containers on AWS and Azure
The above graphic depicts several services in AWS and Azure and checked if the services support Windows (left), Linux (right) or both containers (middle). In addition, it was analyzed whether the services require manual configuration and maintenance (below) or whether they are full managed services (above).
A brief classification of which services were examined is given in the following table:
A, B, C: Azure Container Services is a service to set up infrastructure for different Docker Orchestrators. They support DC / OS, Docker Swarm and Kubernetes. Kubernetes is offered with Linux and Windows containers. Managing the cluster and patching the operating system must be done manually. Also, the automatic scaling of the worker nodes of the cluster is not yet supported everywhere.
D: Service Fabric is a managed service for hosting and scaling microservices and containers. It is a full managed infrastructure created for .NET development. Many Azure services are internally based on this implementation.
It offers automatic installation, continuous deployment and automatic scaling capabilities. There is no need to configure or patch underlying infrastructure.
When setting up a service fabric cluster in Azure, you can choose between Windows Server or Ubuntu Server, which defines the supported container technology. For historical reasons, the support for Windows is slightly more extensive than for Linux. An on-premise installation for Windows or Linux is also possible.
E: Docker forms the basis for container technology. Swarm Mode extends the Docker system with an orchestrator that controls and monitors the interaction and replication of various containers. A conventional Docker installation delivers the Swarm Mode directly and only needs to be activated.
Since Docker works on Windows and Linux systems, Swarm Mode can also be used on Windows and Linux. The Docker web pages provide several scripts and instructions for installing on Windows or Linux VMs in Azure.
F, I: Kubernetes is one of the most well-known container orchestrators for productive use and development. Because of its distribution, it is supported in many cloud providers and offered by them more and more in recent weeks as a full managed service.
The Kubernetes documentation provides scripts for installing Kubernetes on Linux systems. It supports both Linux VMs in Azure and Linux EC2 instances in AWS. For historical reasons, the support for EC2 is a more extensive.
G: The Kubernetes documentation also provides instructions for setting up Kubernetes on Windows machines. It covers both Azure VMs and AWS EC2 instances. However, the manual is quite extensive and requires many manual steps.
H: Amazon Web Services offer Elastic Container Services (ECS), a self-developed container orchestrator. Both Linux Container and Windows Container are supported. The underlying infrastructure consists of EC2 instances and is created automatically, but it needs to be patched and maintained manual.
J: Similar to E, the Docker documentation and many other vendors provide automated installation scripts for installing Linux on EC2. Linux and EC2 are the oldest combination and therefore certainly the most discussed, documented and scripted. However, here too, as for E, the patching of the operating system and the networking of all nodes must be set up manually (or through scripts).
K: The support for installing Docker in Swarm Mode on Windows servers on EC2 instances rarely exists. Accordingly, this scenario requires maximum manual effort and does not support automation in the installation and maintenance of the EC2 instances.
L: Azure has recently been offering a managed Kubernetes cluster (AKS). This can be automatically upgraded to a new Kubernetes version and there is no patching of the operating system needed. New nodes can also be easily added.
The new service only supports Linux containers.
M: Since the Connect () 2017, Docker Swarm is also available in some Azure regions as a full managed service in the preview. As with L, it also supports automatic installation and upgrade to a new version. The patching of the node’s operating system is also eliminated.
Again, only Linux containers are supported.
N: With Container Instances, Azure offers another serveless service that allows users to instantly instantiate and use containers. Each container runs individually, without being in a cluster or an overall application with many containers. For example, the container instances can be used for build or deployment processes, or added as a worker to a Kubernetes cluster.
O: Since the re: Invent 2017 Amazon also offers a managed Kubernetes cluster (EKS) in the preview. Only the master node is fully managed, the worker nodes still need to be manually patched. This new service also uses EC2 instances as infrastructure and can currently only be used with Linux containers.
P: Fargate was also introduced at re: Invent 2017. This is a managed infrastructure for ECS (H). This decouples ECS from the underlying EC2 instances and works directly with the containers. Fargate currently only supports Linux containers. The next advancement is the support of Kubernetes Clusters (O).
As you look at the diagram, you immediately notice how bad Windows Container support is currently. The right area (Linux) is well filled and the automation is very high there. Whereas on the left side (Windows) yawning emptiness gapes, but there are at least some hyprid windings in the middle. Since historically everything began with Linux and there the existing technologies are gradually extended by Windows container, this distribution is also little wonder.
Also all new managed services of Amazon AWS like Fargate (P) and EKS (O) or the new services of Microsoft Azure like AKS (L) and ACS with DockerCE (M) aim for a higher degree of automation. However, no service will include additional support for Windows containers.
Therefore Windows containers are far from being among the first-class citizens, because the development goes in the further automation of the existing (Linux) technologies and only in support for Windows afterwards.
What should .NET developers do when they need containers?
Now the .NET developers are a bit abandoned and lonely in front of the beautiful new container world. But what are the ways to use .NET applications with containers?
Microsoft has overslept with its server products to offer small lightweight images. A Windows Server Core with 5GB space is not a good basis for a container. But a few years ago, the nanoserver came with about 400MB into the docker hub. The latest version (tag 1709) saves 80% more storage space and is currently
99MB 127MB. This makes the nanoserver as a container extremely attractive. Now only the additional services are missing. With ACS Kubernetes there is support for Windows containers and with Service Fabric even a managed service.
With .NETCore 2.0, the amount of functionality has increased significantly up to 70% of the .NET Framework. With .NET Core, the application can also run in Linux containers and so the decoupling of Windows containers succeeds and all services from the upper right corner of the diagram become usable.
With the Roslyn API Analyzer , Microsoft offers an additional analysis tool for .NET Core projects. It checks the used APIs for updates and offers a platform compatibility checker. Each feature will report if it is not supported on MacOS or Linux. This additionally facilitates development for Linux containers or is very helpful in migrating existing applications to .NET Core.
Serverless without container
Serverless architecture is the use of services without worrying about the underlying infrastructure. Some of these services are already serverless. Maybe one more step can be taken in the development and instead of packing microservices into containers, the C# code can be developed/deployed directly in Azure Functions or AWS Lambdas. Both mechanisms provide almost limitless scaling and pay-as-you-go billing when in use.
Although the container offerings for Linux are very extensive, there are also some possibilities for Windows Container. However, the detailed comparison is still clearly in favor of Linux. And wherever support for Windows Container is sufficient, there are interesting alternatives with .NET Core and serverless approaches.
This post is mostly automatic translated from the german version: http://www.thomas-zuehlke.de/2018/01/compare-container-citizen-linux-und-windows-container-im-vergleich/