Skip to main content

Azure CDN – Solutions for things that are not available (yet)

Last week I had some interesting discussions around payload delivery and CDNs. I realize how easily people can misunderstand some features or functionality, thinking that it is normal or making the wrong assumption.
In this context, I will write 3 posts about Azure CDNs, focusing on what is available, what we can do and what we cannot do.


Let’s see what we can when we need to do when we need the Azure CDN features that are missing in this moment in time. In the last post we talked about this features, we will not focus on explaining them – for this please see the previous post.

SAS Support for Blob Storage
If you need on top of Azure Store, a CDN system that has support for SAS, then you need to be inventive. The simplest solution is to replicate the content in multiple Azure Storage Accounts or even in the same Storage Account (if the problem is download speed) and create a web endpoint (that can be hosted as a web app), that will provide the locations from where the content can be downloaded.
This web endpoint, can have a Round Robin mechanism (the simplest thing) to serve different locations.

Using this approach, you will also need a mechanism that replicates the content in multiple locations. AzCopy might be a good out of the box solution.

HTTPS for Custom DNS Domains
The same store with Azure CDN is with Azure Storage. In this moment we don’t have yet support for HTTPS and Custom DNS Domains. In this case if you really need HTTPS, then the only solution is to serve the content from an Azure Web App. There not to many options for now.

HTTPS Client Certificates
The story is similar with the previous one. We don’t have to many options. The best way for now is to use an Azure Web App and serve your binary content from there.

HTTP/2
None. As above an Azure Web App.

Fallback to custom URI
For this situations, we have a simple solution. We can go with the approach presented in the SAS Support example. The additional thing that we need to do is to have multiple Azure Web Apps that can server the content location and add an Azure Traffic Manager in front of them.


Access logs of CDNs are raw data
If you really need this logs, then you need to use Azure Blob Storage. The above approach and activate logs in each Azure Storage Account.

As we can see, there are so many features support by Azure CDN. Of course we will not be able to find a perfect solution that supports all the things that we need. The same is happening with Azure CDN. But what is important to remember that a part of the features that we are missing are already marked as In Progress in the feedback portal of Azure. This means that soon, we will have support for them also.

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