In case one's website only targets a single geographical region, is there still benefit to serve the resource from Azure CDN instead of directly from Blob storage?
Would the CDN be better in handling high traffic condition (more parallel access to the resource)?
If you plan to grow the website or users have VPNs that could potentially alter network patterns, a CDN might be a good option. A CDN has to copy the files from blob storage and caches based on internal conventions or settings. Essentially you are adding additional instructions in front of a CDN.
Also note the Azure CDN API is pretty simple and not as robust as Akamai or other CDNs..you can compare the APIs. For example, if you want to serve the file from an in memory cache, it is probably better to have a service abstracted from it. This allows you to control how the bytes are sent down to the client explicitly..there is a huge difference in accessing small files, medium files or large files...which might provide much better performance depending on your needs.
In my opinion, I would not bother with a CDN.
A CDN (regardless of provider) won't help you that much if the edge servers are not near where your web consumers are. Will it provide better scale out of requests? Maybe. The only certainty is that it will cost you more :).
I'd recommend start off without a CDN, make your resource references easily updateable so you can switch to a CDN if need be (regardless of who provides the CDN service).
Related
This is regarding usage of Azure Front Door caching and Azure CDN. I have a Azure static website that will displaying the data (mainly office files and videos) from Azure blob storage. The files in blob storage will rarely change. I am looking for the best way and cheapest way to cache these files, so that files can be fetched quickly.
Recommendation or supporting links will be helpful.
Thanks in advance.
Caching static website content is a technique to improve user experience as well as reducing the load on webservers by offloading the delivery of static content to a dedicated cache service.
Azure CDN:
Azure CDN is globally distributed network of servers that can deliver content to the customers in a very large scale.
It is a video streaming platform where videos are delivered based on the customer’s nearest edge location.
Azure CDNs stores cached content on the edge servers which results in minimizing network latency.
Azure Front door:
It provides Scalable, secure and fast delivery of your global applications .
It enables you to define, manage, and monitor the global routing for your web traffic.
It provides best performance and instant global failover for high availability.
Based on your scenario, that best caching you can use is Azure CDN due to the following:
Azure CDN is best for delivering static content like Videos, Images and PDFs whereas Azure Front Door is for delivering sites, services and APIs.
Azure CDN is cost-effective whereas Azure Front Door charges per ruleset.
Azure CDN does all the functionality similar to Azure Front Door.
Azure CDN performs a good job at content delivery at a cheaper price!.
Update: As suggested by #silent, you can also make use of Azure Front Door Standard which is a combination of classic CDN and Front Door.
For more information, please refer below links:
https://techcommunity.microsoft.com/t5/azure-developer-community-blog/azure-on-the-cheap-azure-front-door-caching-vs-azure-cdn/ba-p/1372262
https://kishoregopalan.medium.com/azure-front-door-or-azure-cdn-what-solution-will-you-use-for-your-high-availability-sites-be26bb34aee7
https://walkingtree.tech/azure-front-door-azure-cdn-solution-will-choose/
I have a storage account in South Cental US Data center with images. I have a CDN (Verizon standard) endpoint for this storage account.I am using SAS key for accessing my storage account. While accessing contents from CDN, it actually takes more time than getting the data directly from storage account. I investigated and found that the CDN content is being downloaded from US Verizon POP location instead of my closet pop location. I am accessing from India and verizon has a pop location on my city.
Any suggestion what would be the issue?
Optimization choices are designed to use best-practice behaviors to improve content delivery performance and better origin offload. Your scenario choices affect performance by modifying configurations for partial caching, object chunking, and the origin failure retry policy.
This article provides an overview of various optimization features and when you should use them. For more information on features and limitations, see the respective articles on each individual optimization type: https://learn.microsoft.com/en-us/azure/cdn/cdn-optimization-overview
Try switching the optimization scenarios, it may resolve the latency issue you are experiencing. let me know if this helped.
In an Azure Web App I need to efficiently query the MaxMind GeoIP2 City Database (due to the volume of queries and the latency requirements we cannot use the MaxMind's rest API).
I'm wondering what's the best approach for storing the db (binary MMDB format, accessed via the official .NET api) so that it's easy to update with minimal downtime (we are going to subscribe Monthly updates) and still cost effective as to what regards Azure storage and transactions.
Apparently block blobs are the way to go, but I'm not sure about the monthly updates and the fact that the GeoIP2 api load in memory the whole db (I do not know if this would be a problem for the Web App, if I need a web worker to keep it up or I need something else), but actually I do not know yet how large the file is.
What's the most cost effective solution that preserve low latency over a huge volume?
According to the API docs you must have the database available in a file system (the API doesn't know anything about Azure storage and related REST API). So, regardless where you permanently store it, you'll need to have it on a disk somewhere.
I have no idea how large the database footprint is, but Web Apps, Cloud Services (web/worker roles) and Virtual Machines (whether Linux or Windows) all have local disks. And you have read/write access to these disks. So, you'd need to copy the database binary file (or csv) to local disk from somewhere. At this point, when you initialize the SDK, you'd create a DatabaseReader and point it to your locally-downloaded copy of the database file.
You mentioned storing the database in blob storage. There's nothing stopping you from doing so and simply downloading a copy to local disk. And there's nothing stopping you from storing multiple versions in multiple blobs. Note: You may also take advantage of Azure File storage (an SMB share). Which you choose is up to you.
As far as most cost effective solution: You'll need to do the pricing workup yourself to see what's most effective. You'd also need to evaluate how much RAM is available for the given size VM/role instance/Web App you choose. You mentioned Web Apps in your question: Web App instances scale from 0.5GB to 14GB, depending on the tier you choose (again, you'll need to evaluate this).
We plan to migrate the existing website to Windows azure, and i have been told that we need to store files to blob storage.
My questions is:
If we want to use blob storage, that means i need to re-write the file storage function(we use file system for now), call blob service api to store files, that's very strange for me just because we want to use windows azure, how about in the future we want to use Amazon EC2 or other cloud platform, they might have there own way to store file, then may be i need to re-write the file storage function again, in my opinion , the implementation of a project should not depends on the cloud platform(or cloud server)! Can any body correct me, thanks!
I won't address the commentary about whether an app should have a dependency on a particular cloud environment (or specific ways to deal with that particular issue), as that's subjective and it's a nice debate to have somewhere else. What I will address is the actual storage in Azure, as your info is a bit out-of-date.
One reason to use blob storage directly (and possibly the reason you were told to use blob storage) is that it provides access from multiple instances of your app. Also, blob storage provides 500TB of storage per storage account, and it's triple-replicated within the deployed region (and optionally geo-replicated). With attached storage (either with local disk or blob-backed Azure Disk), the access is specific to a particular instance of your app. Shifting from file system access to blob storage access does require app modification.
If you choose not to modify your app's file I/O operations, then you can also consider the new Azure File Service, which provides SMB access to storage (backed by blob storage). Using File Service, your app would (hopefully) not need to be modified, although you might need to change your root path.
More information on Azure File Service may be found here.
Why does it seem strange? You need to store your files somewhere and the cloud is a good a place as any IF it suits your needs. The obvious advantages are redundancy and geo replication, sharing files across multiple projects and servers, The list goes on. It's difficult to advise on whether it would be a good idea or not without hearing some specifics.
You could use windows azure storage with amazon in the future if you wanted to (you'd just need to set up the access for it), obviously with slighter longer delay. Then again that slight performance drop may be significant and you may end up re-writing it.
Most importantly, swapping over from one cloud provider to another is not trivial depending on just how much you use it or how much data you've got in it, so I would strongly suggest looking at the advantages / disadvantages of each platform closely before putting your lot in with either one and then fully learn that platform.
Personally, I went for Azure cloud services + storage etc even though it was slightly more expensive at the time, because i'm a Microsoft Person (not that I didn't do my research). It was annoying in the early days when key features were missing, but it's really matured now and I like the pace that it's improving.
It's cheap to test, why not try both and see which one suits you? A small price to pay when you have big decisions to make.
Disclaimer: I don't know the current state of Amazon web services.
Nice question. We are in the middle of a migration of an old PHP/MySQL/LocalShare to WebRole/SQLAzure/AzureStorage ERP application. We faced the same problem and decision. Let me write some thoughts about the issue :
It is a good option to just be able to switch the storage provider but is it reasonable? You can always build the abstraction but do you plan how to do the actual change of storage provider - migration/sync while in production? What kind of argument will exactly drive the transition to another storage provider? How much users and data do you have? Do you plan to shard-rebalance the storage in the future? How reliable must be this system during this storage provider switch? Do you want to totally move the data when you want to switch or you just want to shard it so that you start using this different provider? Does the cost development of these (reliable) storage layers and the cost of development of reliable transitions (or bi-directional syncs) outweighs the money difference between any two storage providers?
Just switching storage mechanism from Azure Blob to Amazon will incur heavy latency penalty if your other services are on Azure - When you create Storage and Services on Azure you set affinity groups by region so that you minimize the network latency.
These are only a few of the questions to answer before doing all the weightlifting. We have abstracted the file repository (blob) because we planned to move from local NFS to Blob transparently and gradually and it answers our needs.
I am using azure blob storage to store images in a public container and embedding them in a public website. Everything works fine, blobs are publicly available on xxxxx.blob.core.windows.net the instant i upload them. I wanted to use Azure CDN for their edge caching infrastructure and set up one at xxxxx.vo.msecnd.net.
But now, when i point my images to the CDN, it returns 404 for a good 15 mins or so, then it starts serving. It's mentioned on their documentation that we should not use CDN for high violatile or frequently changing blobs, but a simple CMS with image upload feature for a public site warrants a CDN isn't it?
I am in exactly the same situation at the moment for product images that are uploaded to my e-commerce site. I prefer to use Azure CDN on top of Azure blob storage for all of the obvious reasons but cannot wait 15 minutes for the image to be available.
For now I have resolved to store the blob storage URL initially but then later rewrite it to use the CDN domain via an Azure WebJob running once daily. It seems like an unnecessary amount of extra work but I haven't yet found a better option and really want to use the Azure CDN.
What I'm doing right now... for website related images and files I upload manually before deployment (https://abc.blob.core.windows.net/cdn) and If website User upload an image or file using my website, Internally I upload that file on blob storage (separate container not CDN) using CloudBlobClient
CDN is used for static content delivery, but in your case you need dynamic content delivery via CDN. You could use Cloud Service + CDN. This makes Dynamic contents delivered from CDN using ASP.net Caching concepts.
Please refer this link for more details: Using the Windows Azure Content Delivery Network (CDN)
CDN enables a user to fetch content from a CDN-POP that is geographically closest to the user thus allowing lower read latencies.
Without a CDN, every request would reach the origin server (in your case Azure Storage). The low latency offered by CDN is achieved when there are cache hits. On a cache miss, a CDN-POP will fetch the content from the origin server reducing the latency benefit offered by CDN. Cache hits are usually dependent on whether the content is static (results in cache hits) or dynamic (results in cache miss) and its popularity (hot objects result in cache hit).
Your choice of using a CDN or not depends on a) whether your files are static or dynamic, if dynamic then the benefit of using a CDN is lower b) whether low latency is important to your application and c) Request rate : With low number of requests your files are likely to be cached-out so a CDN may not be that useful and d) Whether you have high scalability requirements. Note, Azure storage has the following scalability limits. If your application exceeds the scalability limits of azure storage then it is recommended to use a CDN