Given the diversity of operating systems supported by Docker and the differences between .NET Framework and .NET Core, you should target a specific OS and specific versions depending on the framework you are using.

For Windows, you can use Windows Server Core or Windows Nano Server. These Windows versions provide different characteristics (IIS in Windows Server Core versus a self-hosted web server like Kestrel in Nano Server) that might be needed by .NET Framework or .NET Core, respectively.

For Linux, multiple distros are available and supported in official .NET Docker images (like Debian). In the image below  you can see the possible OS version depending on the .NET framework used.

You can also create your own Docker image in cases where you want to use a different Linux distro or where you want an image with versions not provided by Microsoft. For example, you might create an image with ASP.NET Core running on the traditional .NET Framework and Windows Server Core, which is a not-so-common scenario for Docker.

When you add the image name to your Dockerfile file, you can select the operating system and version depending on the tag you use, as in the following examples:

You should use .NET Core, with Linux or Windows Containers, for your containerized Docker server application when:

•  You have cross-platform needs. For example, you want to use both Linux and Windows Containers.
•  Your application architecture is based on microservices.
• You need to start containers fast and want a small footprint per container to achieve better density or more containers per hardware unit in order to lower your costs.
  

In short, when you create new containerized .NET applications, you should consider.NET Core as the default choice. It has many benefits and fits best with the containers philosophy and style of working. An additional benefit of using .NET Core is that you can run side by side .NET versions for applications within the same machine. This benefit is more important for servers or VMs that do not use containers, because containers isolate the versions of .NET that the app needs. (As long as they are compatible with the underlying OS.)

You should use .NET Framework for your containerized Docker server application when:

•  Your application currently uses .NET Framework and has strong dependencies on Windows.
•  You need to use Windows APIs that are not supported by .NET Core.
• You need to use third-party .NET libraries or NuGet packages that are not available for .NET Core.

Using .NET Framework on Docker can improve your deployment experiences by minimizing deployment issues. This “lift and shift” scenario is important for containerizing legacy applications that were originally developed with the traditional .NET Framework, like ASP.NET WebForms, MVC web apps or WCF (Windows Communication Foundation) services.

After being in preview for quite some time, Azure Storage Explorer is now available in general availability (GA).

You can get it from:

• For Windows https://go.microsoft.com/fwlink/?LinkId=708343&clcid=0x409
• For MacOs https://go.microsoft.com/fwlink/?LinkId=708342&clcid=0x409
• For Linux https://go.microsoft.com/fwlink/?LinkId=722418&clcid=0x409

With Azure Storage Explorer you can directly access your Azure Storage from your preferred client to download/upload content, manage you blobs, files, queues, tables or even your Cosmos DB Entities.

To connect to your Azure tenant (covering all public, government or China) you can use either your credentials, a connection string or shared access URL or the storage account key.

​You can add multiple accounts to connect to your Azure Storage using the View\Account Management menu.

​For the past few weeks a lot has been spoken, written and talked about is GDPR Compliance. I have always retained the view that Europeans are much more intelligent when it comes to compliance and regulatory of Personal Data then Americans.  I am not going to use the word privacy because its been the most mocked around word in some quarters and of course in USA we all know how well its protected and implemented. :D

I'll start with first highlighting some key aspects of GDPR - like

​Its not something new and before GDPR we had Data Protection Act so if you had it implemented then you will go through less pain since a lot of elements are partially covered by it. The whole idea and concept is to know how the data is collected, where the data resides, stored, processed, deleted, who can access it and how its used for EU citizens. This means that organizations will be required to show the data flow or lifecycle to minimize any risk of personal data being leaked and all required steps are in place under GDPR.

In short, GDPR is to have common sense data security  ideas, especially from the Privacy by Design school of thought: minimize collection of  personal data, delete personal data that’s no   longer necessary, restrict access, and secure data through its entire lifecycle and also by adding requirements for documenting  IT procedures, performing risk assessments under certain conditions, notifying the consumer  and authorities when there is a breach, as well as  strengthening rules for data minimization.

A few weeks back, me and  Pelle (Niteco, CEO) had a call with Microsoft Azure Support based in Singapore. We discussed some of the challenges we were facing and one of the critical issue was to have invoicing more structured.  Its not always easy to have your customers have Hosted Apps or backups on your environment  under a different Resource Group and then share billing details internally with the Accounting Team for invoicing. 

Lets face it, not everyone in an IT company has  a technical mind and people in finance only care about numbers. They ideally like to see how the billing gets calculated and how it matches with the invoice they receive from Microsoft every month.  Ahhhh its really a pain at times to break down everything and present it to them , the time and effort it took was just too much. If you are a CSP then its a different story all together and i guess CSP Tier 2 partners also have a much more simpler dashboard to get the invoicing details.

After a few back and forth calls and some initial testing i was told by Microsoft Support that  they would be adding a new User Role in the coming weeks. Well was excited about it and  on Tuesday  25th of May this was released at least for our environment and the new Billing Reader role allows you to delegate access to just billing information with no access to services such as VMs and storage accounts. Users in this role can perform Azure billing management operations such as viewing subscription scoped cost reporting data and downloading invoices.