Tuesday, April 20, 2021

Azure @ Enterprise - Tracing to Console in different Azure SDKs for .Net


Microsoft constantly improves the SDKs. As a side effect, we have to work with new SDKs. Earlier SDK names start with MicsoftAzure or WindowsAzure, next it was Microsoft.Azure. The recent one starts with Azure. Sometimes it's easy to migrate to the latest SDK, but sometimes it's difficult. There is one full post about the dilemma of choosing the Azure SDKs.

The best practice is to be with the latest and greatest version of SDKs

Every time the SDK changes, the logging mechanism also may change. This post is to discuss differences in SDK logging. For simplicity, we are going to look at the logging mechanism that outputs into the console. The same mechanism can be leveraged to write into any other persistent storage.

Why logging is important?

It really depends on the time developers are getting to release products in quality. But whatever the case today or tomorrow we as developers will end up debugging why our code failed in certain situations. The Azure works by HTTP WebAPIs and these SDKs are mainly wrapping that HTTP requests. If we are running in an unrestricted environment, we may not encounter any issues. But if it is from an enterprise environment that has its own hardening policies and restrictions, we will definitely encounter issues and end up debugging. If we are able to see the requests payloads in the console, it would be easy to debug at least in development time. Or just be use our friend Fiddler.


Let us start with the latest SDK as of today. Not sure if it's V12(Storage Blobs) or V4(KeyVault Secrets) or V7 (ServiceBus). The nuget packages are all starting with Azure. are the latest. It all starts from this GitHub repo where the source code lives. There is a documentation page that explains how the logging can be achieved using these SDKs. The essence of the approach is as follows.

Tuesday, April 6, 2021

SharePoint.com storage requirement due to versioning


Recently we were trying to migrate the document storage system from SQL FileStream to SharePoint.com. One of the criteria we are looking forward to in SharePoint.com is versioning. Since its SaaS model, we are sure the total storage is limited in SharePoint.com site. Obviously, we were interested in how the versioning affects the storage.


Our first understanding was that Microsoft will be doing some magic behind the scene to capture the delta and the storage will not be the ~size of document * no of versions. But need confirmation we cannot just go with assumptions.

The question basically is does SharePoint.com count each version as an individual document or it stores only the changes similar to Git?

We did a good amount of google. But didn't get anything great that confirms the behavior. Fortunately, we are lucky to have Microsoft Development Manager with us. He did a good job finding the right people and finally, we got the answer.


It was different than what we think. Almost all versions count towards total storage. ie if there is a file of 1 MB and edited 3 times the total storage is 3 MBs.

We can easily confirm by browsing to the storman.aspx page.

Tuesday, March 9, 2021

Mind map on SQL Server Performance

Below is the mind map. The mind map is not complete. These are some ideas I got while working closely in performance.
These are just pointers to quickly refer what are the things to check when someone reports SQL Server performance issues. Need to google for the details on how to really optimize the performance.

Feel free to click on it and explore. Below is the link to GitHub. Feel free to issue pull requests if there are important things missing.