Geographically distributing an Azure based service - azure

I have an Azure based web service. The service contains a web based front end that communicates through JSON and Ajax with a WCF service running in the same web role. This in turn communicates with another WCF service that serves as our mid-tier in a separate web role. This communicates with the back-end that consists of two SQL Azure databases and some blob storage. When deployed all of these were placed in the Western Europe region (I'm in the UK). Part of the web service involves uploading multiple potentially large photos. It would make sense if our users in America uploaded to data store and database in America, using a front end and mid-tier hosted in America. Does Azure provide a solution whereby I can replicate my infrastructure across continents and have Azure handle the redirection required? If so, how do I set it up?

Yes, you can do this in Windows Azure using the Traffic Manager where you can set it up in 3 different modes:
Performance (name says it, will try to redirect you to the closest hosted service)
Failover (redirect in case of an error)
Round Robin (equally distribute)
Here is an overview of how the performance load balanching method works:
Note that this only applies to hosted services (not for storage, SQL Azure, ...)

Related

Deploying multiple web Apps on Azure App Service.. Is there any implications of this

I have a client coming on board to Azure from other cloud service provider. They would like to host up to 10 web apps on Azure and cost is really an issue for them.
Normally I'm suppose to create VM's that would host each of these web Apps; but they can't afford the price. Hence the choice of deploying all of them on the same Azure App service plan.
I think Azure App service offers only 50gb storage. The 10 Web Apps would require storage capacity far more than 50gb; is it scalable or can we link each of these Apps to an Azure storage account. And also is there any implications for deploying multiple web Apps on an Azure App Service plan
An App Service Plan is capable to run multiple Web Apps, each in its own sandbox. It's like a VM but as a PaaS service. Note that the storage included in the plan will be shared across all Web Apps so you'll have to use Azure Storage if you want to store more data.
An App Service Plan is designed to handle multiple web apps/Function apps, use BLOB Storage or similar for your data it will scale to whatever you need, depending on your needs you can add further services like Azure Front Door to load balance multiple apps on multiple app service plans
One important thing to remember is that the app service plan has limitations with outbound connections so even if each of your webapps are not so busy the sum of them all might bring you over the limit so be very careful how you handle your outbound connections.

should I choose azure application gateway or load balancer or front door or traffic manager?

I have a SaaS web app developed with Angular 8 and Asp.net Core Web API. I have deployed web api to a azure web app and deployed angular front-end web app to another azure web app as well.
The users are from China and Australia and other countries. I want to have region load balance like Chinese users uses web app on china azure region and australian users use Australian azure region web app so that it has best performance. Azure SQL DB will be in one place (in australia).
In addition, i want to prevent attacking to web front app and web api like d-dos, web scraping and SQL injection. For web scraping, i want to add access rate limitation from one ip.
Can you please advise what service i should use? I saw the blog talking about azure application gateway, azure load balancer, azure front door and azure traffic manager. It is a bit confusing to me. I need a best practise based on my this real world scenario. Should I use one of the service or should I use multiple services?
Based on your requirement:
Since the Backend Resource is Web App, you can ignore Load balancer (Layer 4) where you can only add VMs or VMSS
Your another requirement is WAF, and it is only available in AFD and AppGW. But you can use Traffic Manager as first Tier Load balancing and have AppGW in the different regions to provide high resilience.
As you want users from specific country to reach nearest backend resource, it seems like, the best solution for you is AFD.
AFD is a global Load balancer. It has WAF capability. It can Cache the data and provide quicker responses(CDN functionality). AFD uses an intelligent probing mechanism, through which it chooses the endpoint which is closer to the client who is making the request.
Hope this helps.

Geo-distributed Azure App's vs One-region

I'm using Azure App Service to setup my website. I have 2 Azure App Service instances and 2 Azure SQL.
1 App Service instance is in the Central US and 1 App Service instance Central India. 1 SQL instance is in the Central US and the other is in Central India.
I use Traffic Manager to route traffic to either region.
What confuses me is that, when I access the Indian server directly the page seems to load at pretty much the same speed as the server in the US.
And both seem to load relatively quickly. Around 250-350ms each to load a page with no styling that performs one database query.
Does this mean that deploying in multiple regions is overkill? Would I be better deploying a larger instance in a single region?
A multi-region architecture can provide higher availability than deploying to a single region.
If a regional outage affects the primary region, you can use Traffic Manager to fail over to the secondary region.
This architecture can also help if an individual subsystem of the application fails.
Also, when you configure you Traffic Manager, create a health probe endpoint that reports the overall health of the application and use this endpoint for the health probe.
The endpoint should check critical dependencies such as the App Service apps, storage queue, and SQL Database.
Otherwise, the probe might report a healthy endpoint when critical parts of the application are actually failing.
For more details, you could refer to this article.

Azure region based WebApi for mobile app

I'm currently developing a mobile app which will be pushed world-wide across the app stores. This app uses a WebAPI REST service as the backend which I currently have running on MS Azure in Europe (which backs onto a database also in Europe).
My problem is, I'd like to create multiple Azure WebApi endpoints (i.e. Australia, US, etc for latency reasons), each with their own database which has geo-replication enabled.
Does anyone know a method/product/service I could use which allows me from the app to either:
Connect to a single domain which behind the scenes picks the closest server to the user.
OR
The app itself is able to determine based on a given list the closest server and connect to that?
I've looked at Azure CDN but this is for static content which is great but I need something for dynamic content.
What you're looking at is Traffic Manager. Traffic manager enables that exact scenario, of finding the closest service that hosts your REST API.
Keep in mind though, that the database replication is (for the time being) a thing you have to do yourself, although we do provide you with the tooling and guidance on how.

Place a WCF service in the CDN endpoint?

Is it any way of placing a WCF service in an Azure CDN Endopint? Or is it only valid to place static content?
It would be useful becasue I have a web frontend that constantly communicates with the WCF service.
If not, any suggestion on how to decrease delay?
If you want to run redundant WCF services in Azure, you create a WCF Service Web Role project and deploy it. Within the configuration, you can scale the deployment up to meet load. You can create and deploy multiple roles per package with each role having its separate instance count.
If you want the service to be distributed across multiple regions, you have to use the Azure Traffic Manager which handles directing traffic based on location or in a round robin format.

Resources