Hosting Kentico MVC Applications in Azure

When you’re talking about creating an application, you better be thinking of the cloud. And, if you want to ever find someone to help you build it, you should plan on using MVC. As the tech community leads the charge to scalable, flexible architectures and hosting, Azure and MVC are certainly at the front of the pack as more developers are looking to leverage both for their sites.

At this point, MVC is pretty much a certainty. It offers the flexibility for companies to have parallel development, full control of presentation, and easy integration with other systems. That’s why we at Kentico put so much work over the past few versions into beefing up our MVC-capabilities to give you the best experience possible. And with Version 12, we’re going to give you even more, like an MVC page builder, drag and drop forms, and a whole mess of other things. There’s really no reason to not use MVC for your sites moving forward!

But what about your Azure hosting? You may be wondering how this new architecture affects how your sites are configured and deployed. In this article, I’m going to show you how to host your MVC sites in Azure and leverage the most out of the platform. So, let’s take a look at how to get every bit of awesomeness out of your applications.

Architecture

At the core, Kentico MVC sites aren’t that much different than traditional, portal-method applications. Both are web applications that run on IIS. Both have global settings and modules, that allow you control routing, requests, and interacting with data. Because of these similarities, your Azure hosting should look familiar, as App Services will be your go-to destination for your sites. There are, however, a few important differences you’ll want to take note of to ensure your site runs optimally.

Here’s an example of hosting a Kentico MVC Site in Azure.

Seems pretty simple, right? Let me break down each section so you know why I have configured it how I did.

Resource Group

In this architecture, I have placed everything within a single resource group. How a company uses resources groups can vary from business to business, as they can affect utilization, availability, and categorization of resources. In this architecture, I have chosen to include all resources within a single resource group to allow me to manage them as a single unit. I can easily determine the cost (usage) of the entire group, create an automation script (ARM template) for it, and even delete it with a single Azure CLI command, if needed. This makes managing the resources very easy and clean, which is always a good housekeeping practice when it comes your Azure subscription.

App Service Plans

Moving down the diagram, you can see I have 2 App Service plans, one for the MVC site and one for the Admin portal. When developing with MVC and Kentico, you will have 2 separate web applications for these areas. By placing them in different app services plans, you can manage and scale them independently. In all likeliness, your MVC site will receive the bulk of your traffic, so you’ll want to make sure you can scale that easily and quickly. Your Admin site, however, will probably get much less traffic, so scaling it to multiple servers probably won’t be that common. By having 2 App Service Plans, you can define your own rules for each area of your site to get the best performance and cost savings possible.

I recommend at least an S3 of P1v2 for your MVC. For your Admin site, start with an S1/S2 and scale up, if needed.

Database

Both your MVC and Admin sites will access the same database. An Azure SQL Database is a great option for this, as you get a scalable SQL cluster for a fraction of the cost of a physical machine. Both applications will be updated with a connection string to the database, as the data will be flowing between them. This means your Admin site will be writing a lot of information and your MVC site will be retrieving it.  Be sure you scale your database correctly for the amount of traffic you’re expecting.

I recommend at least a P1 for your production sites.

REDIS

MVC sites are similar to traditional Web Forms applications in that they still rely on some core .NET principles: Requests, Routing, and Session. If your application requires a stateful environment (logins, forms, etc.) you will still need to manage users’ session information in a central location. Azure REDIS cache is a fantastic location for this data, as it’s extremely scalable and tuned specifically for this purpose. Even better, there’s a Nuget Package with everything you need to use it! By storing your session information in REDIS, you can easily scale your MVC App Service Plan to handle any amount of traffic.

NOTE

In this architecture, only the MVC site is using REDIS cache, as it has the potential to be served by multiple instances. With the Admin site in its own App Service Plan on a single instance, no centralized session storage is needed. If you do need to scale your Admin site to multiple instances, just update your application to use the same REDIS cache and increase the service scale, if needed. Just know that you will be using more resources of your REDIS cache, which may affect performance.

Storage Account / CDN

Because the Kentico Admin site will still be used to enter and manage content, you can take advantage of long-standing best practices when it comes to your media libraries and storage. By configuring an Azure Storage Account and CDN, you can take advantage of Microsoft’s CDN network for the delivery of your site images and assets. Because the MVC will be retrieving this content and displaying it, the CDN paths will be passed on to the user, so you still get the full benefits of centralized storage.

Other Stuff

In addition to the main points above, there are number of other settings / configurations you’ll want to take advantage of for your Azure sites.

Application Settings

Azure App Services allow you to configure application settings that can be pulled in dynamically for your site. This feature allows you to configure connection strings, Azure storage paths, and any other settings on an application-level. This can greatly simplify your deployments and hosting, as well keep things very secure as the information is only viewable through the Azure portal.

ARR Affinity

When hosting an application in a web farm, you have a choice of allowing the user to always be placed on a random server for every request or directing to a single server after the initial request. This is called ARR Affinity and it’s a setting you can have on your App Services. If you enable this setting, a user will always be directed to their initial server for the lifetime of their session on your site. In this case, you potentially would not need the REDIS cache, as the session never needs to be centralized.

I don’t recommend this approach as it goes against the high-availability mindset of every system being redundant. If an app service is taken off line for some reason, the user would be directed to another server, which does not have access to their session and would require them to login again. With the use of REDIS cache, this scenario is obsolete as their session information is available to every server in the farm. 

Azure Search

You knew that any article I wrote about Azure had to include Azure Search! It was just a matter of time… With Kentico VMC and Azure, you absolutely can use Azure Search for your site queries. You can create and manage your Smart Search indexes in your Admin site, as normal. Then, in your MVC application, create the necessary functionality to query your Search service and get results.

Auto scaling

Azure App Service Plans are one of the most powerful features of the platform., They allow you to configure a set of resources quickly, and replicate (scale) them, as needed. With Autoscaling, you can set limits for your CPU utilization or other performance metrics. This means your app can respond to user load automatically and increase the number of instances when things get busy. Then, when the storm calms down, the service will automatically scale back down to the initial state. This allows you to leverage the burstable scaling of Azure automatically and protect your wallet from unnecessary resources.

Wrapping up

As this blog hopefully showed you, hosting your Kentico MVC sites in a Azure is a great idea. By leveraging the best of what the platform has to offer, you can architect your hosting to scale dynamically and provide the best experience for your users. And with MVC, your development should be a MUCH smoother process, as your developers and designers will be able to work in parallel to crank out applications in no time.

Be sure to read up on all the great MVC features coming in Kentico 12. You’ll want to jump on this development methodology as soon as you can to keep things current and running smoothly. Good luck!