Using Kentico Cloud to make Regional Web Apps

The Problem

In a global age, many websites are no longer catering to a local market. And while the reach of websites is becoming more global, most websites and web systems are still forced to reside in a single data center. This gives rise to less than ideal response times and slow performance for those accessing your site from across the ocean or across the continent.

While CDN (Content Delivery Networks) help ease some of the strain by delivering static content (such as images, CSS, and JavaScript), the initial page visit and any related calls to the server for dynamic content is still funneled to the actual server where the website resides, causing delays. This is even more impactful when resource calls are dependent on other resource calls, thus multiplying the delay since you have to wait for the first response before you get the second.

Solution: Kentico Cloud to the rescue!

While your data still resides in a single location, Kentico cloud caches your calls (using Fastly currently) in CDN nodes all over the world. This means that the when you make an API call to Kentico Cloud, it is caching those calls and delivering your content close to your web app itself. It also has very fast cache invalidation, and checks that will server up slightly-old data if getting the new data would take too long, and then caches the new data the next time.

We’re going to do a proof of concept with this, making a very simple web API site that is geo-replicated to various regions of the world. While we are making a simple API call, you can also use this as a way to geo-replicate entire websites that use Kentico Cloud as their source of data.

The Setup

Now to get your web API site itself to be completely Geo-replicated, it’s going to take a couple pieces of Azure magic working together. We’re going to use Regionalized Resource Groups + Web Apps to provide the actual website in geographic areas (in our case, Australia, Europe and North America), and then use Azure Traffic Manager to create a single access url that will leverage whichever web app is close by.

The website/API on the Web App will run off of Kentico Cloud’s API, so it will get its calls cached to the nearest fastly regional node.

Resource Groups

Resource groups are a collection of apps and services.  For our example, we will create 4 Resource Groups. Three regional Resource Groups (located in North Central America, Northern Europe, and Eastern Australia), and one resource group for our Traffic Manager.

Azure Web App (Web API) Setup

Next we need to add a 3 Web App Services, 1 in each regional resource group, which will house our very basic Web API project. The content of the API will be the same. You will probably need to create new App Service Plans for each of these so they are located in the region applicable.

Once you have these created in Azure, next we need the actual web application that we will put in each of these. I created a basic .Net web application (type Web API or MVC), installed the Kentico Cloud Delivery NuGet Package, and used the Kentico Cloud Model Generator to create a strongly typed class for my content type.

To do this, I temporarily turned off the Secure API in my Kentico Cloud Project settings, and then used the Cloud Model Generator with this command line:

Then I made a blank MVC controller and added in a JSON Result method that would get a single item from Kentico cloud (called 10 times), and return that item (along with the IP address and how long the Kentico Cloud call took). This way we can see how much the regional caching impacts the API calls, where if we didn’t have that we would see some large delays in running it 10 times.

You can download my test project here.  Please note I did not include the full package as Kentico Cloud’s Delivery NuGet Package added about 300mb to the zip file.  Or, here's the actual code if you simply want to see an example:

Then I retrieved the publish profiles from each region, and used the “Publish Web App” feature in Visual Studio to publish my app to the 3 regions.  Below where are the 3 API calls that were created:

http://tfayascloudgeolocationapicode-na.azurewebsites.net/TestAPI/GetTestItem
http://tfayascloudgeolocationapicode-eu.azurewebsites.net/TestAPI/GetTestItem
http://tfayascloudgeolocationapicode-au.azurewebsites.net/TestAPI/GetTestItem

Azure Traffic Manager

Next I added an Azure Traffic Manager. This is how I set it up in Azure:

1. Add a Traffic Manager Profile app
2. Set its Routing Method to "GeoLocation" instead of performance
3. Assign it to your General Resource group.

Next I needed to add 3 End Points which would point the various Geographic regions to the corresponding regional Web Apps:

1. Create a new End Point
2. Set the Target Resource Type to App Service
3. Target your resource group that matches the region that your end point is for
4. Add one or more Regional Grouping to the closest country/region (I did just Regional Grouping, ex “Europe” but you can also specify down to the country). 
   1. For Australia’s, I did all of Asia and Australia
   2. For North America’s, I did all of North and South America/Caribbean
   3. For Europe I did Europe and Africa

With it set up, Azure will give you the URL of your traffic manager.  You should be able to take the DNS entry for your API calls now (for me it was http://tfayascloudgeolocationapi.trafficmanager.net/TestAPI/GetTestItem )

Results

After publishing our simple MVC call to all 3 regions, and using GeoPeeker.com to test hitting our API from different regions, here were my results:

Regional URL	Virginia Response	Virginia KCx10 call	Australia Response	Australia KCx10 Call	Ireland Response	Ireland KCx10 Call
US Central tfayascloudgeolocationapicode-na.azurewebsites.net	39ms	88ms	275ms	207ms	110ms	264ms
Australia East tfayascloudgeolocationapicode-au.azurewebsites.net	222ms	37ms	3ms	59ms	278ms	60ms
Northern Europe tfayascloudgeolocationapicode-eu.azurewebsites.net	84ms	170ms	341ms	157ms	2ms	179ms
Traffic Manager tfayascloudgeolocationapi.trafficmanager.net	37ms	211ms	8ms	113ms	2ms	107ms

 
As you can see, using the Traffic manager, the response times were about the same as the nearby regional site address hits. The Kentico Cloud 10x call was relatively sporadic on times as if there is no cache at all (not even an old one), it still had the initial call’s penalty, however from the speeds after we can see that the data is properly being cached and delivered rapidly beyond the first call.

Conclusion

Kentico cloud’s geo-caching is a huge asset to those who want to make your regional web application lightning fast in multiple regions. By using Azure Traffic Manager and Region Specific Web APIs, leveraging Kentico Cloud as their data source, we were able to accomplish this! While it’s not truly geo-replicating the data yet, it’s still providing a very solid automatic caching system which makes API calls speedy, and creates a great improvement to user experience around the world.