In this post, I will try to find answers and guidance for technical people that needs to decide if they shall use .NET Core or .NET Framework inside Docker containers on Azure. The same answer is applicable for on-premises, because Docker runs in the same way on Azure or on-premises.
The directions from Microsoft related to this topic are clear. The default option shall be .NET Core. From this way, .NET Core is design in a such a way that is align with container concepts. For example the footprint was reduced drastically in comparison with .NET Framework.
One interesting fact that people do not know is related to the type of Windows image that you need to use when you use .NET Core or .NET Framework together with containers. When you use .NET Framework you need to use a Windows Server Core. This image is heavier than Windows Nano Server. This can have a direct impact at infrastructure and resources requirements. There are many things to say why Windows Nano Server is better, a few things you can find below:
Now, let's see some cases when you should go with one or another.
.NET Core when you are using micro-services concept
First, when you design an application that is based on micro-services concept you will want to go with .NET Core. A micro-service architecture is based on a high number of services that runs in parallel. This requires you to have the footprint of the service as small as possible.
You do not want the container image to be 4.5GB, because of it.
.NET Core for cross-platforms
Secondly, if you know from the beginning that your containers use Linux also, not only Windows, then .NET Core is your only option. In contrast with .NET Framework, .NET Core can run on both platforms. There is not too much to do with .NET Framework on Linux. Do not even thing to try to use Mono, because you will end up in a situation where the only option is migration to .NET Core.
.NET Core for cost optimization
Each instance of a container consume infrastructure resources. It is not the same thing to have a container that has 4.5GB of disk consumed or 200MB. Even if your hosting your container inside the cloud, you will need to pay for each MB and for each CPU cycle that you are consuming. Because .NET Core is using less resources that .NET Framework, it is a much better candidate for containers.
Still, there are some things that can force you to use .NET Framework. But don’t be panic. Remember that you can have in the same deployment different types of containers. So, if you are required to use .NET Framework, you can use it only for the containers where it is strictly necessary.
.NET Framework for strong dependencies to OS (Windows)
When the application has strong dependencies to Windows, there is no other option that to go with .NET Framework. This kind of OS dependencies cannot be found on .NET Core and will not allow you to communicate with OS in the same way as would happen with .NET Framework.
.NET Framework for .NET libraries that are not available for .NET Core
Unfortunately, many libraries are not available for .NET Core. Just looking on Nuget, you'll found many packages that are not compatible with .NET Core yet and there are no signs that this is going to change. Beside this, if your application is using legacy libraries than you are stuck. Chances that this kind of libraries to be ported to .NET Core are almost zero. If you want a legacy library to be migrated to .NET Core than you might need to do it by yourself.
.NET Framework when you need to use Windows API
.NET Core is a cross platforms. In this context, there is no API that allows us to communicate with Windows API. If you find yourself in a situation when you need to make calls to Windows API, you should know from the beginning that .NET Framework is your only option.
.NET Framework for migration scenarios
If you find yourself in a situation when you need to do a migration to an existing application to container than you need to design a migration plane where risk are controlled and you have clear milestones. Do not jump and say that you need to rewrite the system. You can make small steps and even migration to containers together with .NET Framework might be enough to resolve the current problems.
.NET Framework when technology is not available in .NET Core
There are technologies that are not yet available in .NET Core. This kind of constraints can force you to go with .NET Framework. A part of the current technologies that are not yet available in .NET are:
Take into account that new versions of .NET Core might come with some changes in this area.
Conclusions
If you evaluate your projects requirements in the right way, I'm sure that you will find a way to go with Docker and .NET. Worst case that can happen is an hybrid solution that has both .NET Core and .NET Framework. More about this kind of solution I will talk in the next post.
The directions from Microsoft related to this topic are clear. The default option shall be .NET Core. From this way, .NET Core is design in a such a way that is align with container concepts. For example the footprint was reduced drastically in comparison with .NET Framework.
One interesting fact that people do not know is related to the type of Windows image that you need to use when you use .NET Core or .NET Framework together with containers. When you use .NET Framework you need to use a Windows Server Core. This image is heavier than Windows Nano Server. This can have a direct impact at infrastructure and resources requirements. There are many things to say why Windows Nano Server is better, a few things you can find below:
- VHD image is ~93% lower
- 80% fewer reboots
- 92% fewer critical bulletins
Now, let's see some cases when you should go with one or another.
.NET Core when you are using micro-services concept
First, when you design an application that is based on micro-services concept you will want to go with .NET Core. A micro-service architecture is based on a high number of services that runs in parallel. This requires you to have the footprint of the service as small as possible.
You do not want the container image to be 4.5GB, because of it.
.NET Core for cross-platforms
Secondly, if you know from the beginning that your containers use Linux also, not only Windows, then .NET Core is your only option. In contrast with .NET Framework, .NET Core can run on both platforms. There is not too much to do with .NET Framework on Linux. Do not even thing to try to use Mono, because you will end up in a situation where the only option is migration to .NET Core.
.NET Core for cost optimization
Each instance of a container consume infrastructure resources. It is not the same thing to have a container that has 4.5GB of disk consumed or 200MB. Even if your hosting your container inside the cloud, you will need to pay for each MB and for each CPU cycle that you are consuming. Because .NET Core is using less resources that .NET Framework, it is a much better candidate for containers.
Still, there are some things that can force you to use .NET Framework. But don’t be panic. Remember that you can have in the same deployment different types of containers. So, if you are required to use .NET Framework, you can use it only for the containers where it is strictly necessary.
.NET Framework for strong dependencies to OS (Windows)
When the application has strong dependencies to Windows, there is no other option that to go with .NET Framework. This kind of OS dependencies cannot be found on .NET Core and will not allow you to communicate with OS in the same way as would happen with .NET Framework.
.NET Framework for .NET libraries that are not available for .NET Core
Unfortunately, many libraries are not available for .NET Core. Just looking on Nuget, you'll found many packages that are not compatible with .NET Core yet and there are no signs that this is going to change. Beside this, if your application is using legacy libraries than you are stuck. Chances that this kind of libraries to be ported to .NET Core are almost zero. If you want a legacy library to be migrated to .NET Core than you might need to do it by yourself.
.NET Framework when you need to use Windows API
.NET Core is a cross platforms. In this context, there is no API that allows us to communicate with Windows API. If you find yourself in a situation when you need to make calls to Windows API, you should know from the beginning that .NET Framework is your only option.
.NET Framework for migration scenarios
If you find yourself in a situation when you need to do a migration to an existing application to container than you need to design a migration plane where risk are controlled and you have clear milestones. Do not jump and say that you need to rewrite the system. You can make small steps and even migration to containers together with .NET Framework might be enough to resolve the current problems.
.NET Framework when technology is not available in .NET Core
There are technologies that are not yet available in .NET Core. This kind of constraints can force you to go with .NET Framework. A part of the current technologies that are not yet available in .NET are:
- VB & F# (because of lack of support in VS2017)
- Workflow Foundation
- WCF
- ASP.NET SignalR
- ASP.NET Web Pages
- ASP.NET Web Forms
Take into account that new versions of .NET Core might come with some changes in this area.
Conclusions
If you evaluate your projects requirements in the right way, I'm sure that you will find a way to go with Docker and .NET. Worst case that can happen is an hybrid solution that has both .NET Core and .NET Framework. More about this kind of solution I will talk in the next post.
Comments
Post a Comment