Skip to main content

.NET Core or .NET Framework together with Docker and Containers on Azure

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:

  • 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

Popular posts from this blog

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

Azure AD and AWS Cognito side-by-side

In the last few weeks, I was involved in multiple opportunities on Microsoft Azure and Amazon, where we had to analyse AWS Cognito, Azure AD and other solutions that are available on the market. I decided to consolidate in one post all features and differences that I identified for both of them that we should need to take into account. Take into account that Azure AD is an identity and access management services well integrated with Microsoft stack. In comparison, AWS Cognito is just a user sign-up, sign-in and access control and nothing more. The focus is not on the main features, is more on small things that can make a difference when you want to decide where we want to store and manage our users.  This information might be useful in the future when we need to decide where we want to keep and manage our users.  Feature Azure AD (B2C, B2C) AWS Cognito Access token lifetime Default 1h – the value is configurable 1h – cannot be modified

What to do when you hit the throughput limits of Azure Storage (Blobs)

In this post we will talk about how we can detect when we hit a throughput limit of Azure Storage and what we can do in that moment. Context If we take a look on Scalability Targets of Azure Storage ( https://azure.microsoft.com/en-us/documentation/articles/storage-scalability-targets/ ) we will observe that the limits are prety high. But, based on our business logic we can end up at this limits. If you create a system that is hitted by a high number of device, you can hit easily the total number of requests rate that can be done on a Storage Account. This limits on Azure is 20.000 IOPS (entities or messages per second) where (and this is very important) the size of the request is 1KB. Normally, if you make a load tests where 20.000 clients will hit different blobs storages from the same Azure Storage Account, this limits can be reached. How we can detect this problem? From client, we can detect that this limits was reached based on the HTTP error code that is returned by HTTP