As one of the first CMS platforms to natively support Windows Azure, Kentico’s roots in the cloud are very solid. Since version 5.5R2 Kentico has allowed developers to leverage Microsoft’s cloud platform for hosting their applications in a highly available, scalable environment. In this blog I will be taking a closer look at some of the ways Kentico uses this architecture and what it means for applications and developers.
“Smart” Web Farm Support
All enterprise applications should be hosted in a load balanced environment to ensure site performance and availability. Kentico has long since supported running in this type of architecture, regardless of what hosting environment is used. With Windows Azure PaaS (Platform as a Service) all of the servers are managed by Microsoft. This affords developers the luxury to only needing to focus on their application without maintaining the physical server.
Microsoft continually updates Windows Azure and cycles servers routinely to apply hotfixes, patches, and make other improvements. Microsoft does this in a manner that always keeps the site available by updating/cycling servers individually. Because of this, Kentico CMS has to handle dynamic server names and unexpected shutdowns and reboots.
In a traditional Kentico web farm, each server is manually registered within the CMS so the system knows how to contact that server when a change needs to be propagated. Due the dynamic nature of servers in Azure, this process has been updated to eliminate the need to register these servers. As web roles are started in Azure, Kentico will identify the server as a “new” server and automatically register it as a web farm server (using the internal IP that Microsoft assigns). This method ensures that any new server added to configuration is automatically added to the system and synched accordingly. As servers are cycled down there are automatically un-registered by the system, cleaning up any previous roles.
Another feature is the ability to track changes per server and sync them to the other servers. In the traditional process, Kentico would contact each server via an internal web service and push out changes, In the “DB Web Farm Updater” method changes are logged immediately to the database by the server they were performed on. Every server is constantly checking that table for any changes and processes them as soon as it can. This is another change to accommodate the dynamic servers but actually provides a more stream-lined approach to synchronization.
Media Library / CDN Functionality
Microsoft has built an extensive network of data centers around the world for hosting Windows Azure applications. A big part of this network are the CDN data centers. As requests come in for a resource Windows Azure will route the request to the closest CDN data center to the user. If the resource is found it is served from there. If not, the file is served from the original data center where it was uploaded. At that point it then replicates to the CDN data center so the next request will be served from there. With this process each request increases performance as more and more resources are copied to the CDN data centers around the world.
Kentico leverages this capability via the Media Library. In an Azure deployment the media library files can be configured to automatically save to Windows Azure. If the CDN is enabled on the storage account, Kentico will insert the CDN path into any call for a media library to instantly utilize the CDN functionality. If the site is very image-heavy this is a great way to increase performance and get the most out of the platform.
TIP
We typically create a custom setting and macro to get this CDN path so we can use outside of the Kentico Medial Library functionality and to help implement the CDN where we want.
Web Analytics and Smart Search
One of the most common questions I get is exactly how does Kentico handle Web Analytics / Smart Search within Windows Azure? To answer requires a little background into how Windows Azure Storage and Kentico fit together. Windows Azure Storage (WAS) is a file (kind of) based system for storing files in the cloud, with a REST service in front of it to retrieve / update data. Because WAS is a global network of servers it has some restrictions in how content is accessed and updated. Only one entity can update a WAS-hosted file at a time so multiple requests have to be queued and executed individually so that only one system is connecting at a time.
Kentico’s Web Analytics and Smart Search features both leverage a file-based system for storing / maintaining data. Because of the web farm aspects of a deployment, these files need to in a central location so that all servers can access them and there is only one location to update. Windows Azure Storage is a perfect solution for this, however, special consideration had to be taken because of the access restrictions.
To resolve this issue, deploying Kentico in PaaS requires a separate Smart Search Worker Role (SSWR) for processing the analytic and search file changes. This worker role receives the tasks form the web servers and queues them for processing. In this way, only the worker role is accessing the WAS file for the updates. The process flows goes like this:
- A change is initiated on a web role (Web Analytic processing, Smart Search index rebuild, etc.)
- The change is sent to the SSWR.
- The SSWR queues the task for execution.
- Once available, the SSWR executes the task.
Because of the dynamic nature of Web analytics and Smart Search indexes, this is a constant cycle on the SSWR where tasks are being queued and executed. Because there is only one system accessing the WAS files at a time everything goes great.
Note
I know a lot of people have trouble with deploying to Azure.
Joel Dahlin asked for a blog on how I do my deployments to help with some of the common troubles. I'll be sure to get that blog written in Feb 2014!
Scheduled Tasks
Understanding how Scheduled Tasks run in Azure requires a little info into how they run in general. With Kentico, tasks are configured to run a specified assembly / class at specific intervals (or once, if needed). In addition, parameters ca be passed to this assembly so conditional logic can easily be implemented. With a scheduled task (one that runs more than once), what happens is a little interesting. Let’s say the task was going to run once a day at 1:00AM. When 1AM rolls around, the system doesn’t call the code and execute. Instead, it marks the task as “ready” to be run. Meanwhile, the site is constantly looking for any tasks in the “ready” state and then executes any of those that it finds.
In a web farm this process is the same. The only difference is which server actually executes the code. As the tasks are marked as “ready”, each server is constantly checking the tasks’ statuses. Whichever one happens to see the task as “ready” first then executes the code. As soon as the server starts executing the task it’s marked as “executing” and the system functions as usual.
This particular point isn’t all that ground-breaking, but I thought I would clear up any confusion about tasks in general, just in case.
Multiple Deployment Options
One of the greatest aspects of Windows Azure is its flexibility and extendibility. Applications can be hosted in Azure in a number of ways, each providing different levels of functionality and maintainability. PaaS allows for focus on the application with Microsoft maintaining the server. IaaS (Infrastructure as a Service) allows for full control of both the application and underlying server. Windows Azure Web Sites are just the opposite by allowing minimal server configurability and access, but providing a lower-cost solution and simplifying deployments.
Kentico recognizes that all companies / projects are different hosting needs vary. Kentico natively runs in all of the Windows Azure environments, taking advantage of functionality where it can. IaaS resembles traditional hosting models where companies have full server access so any change is easily configured and implemented. With Windows Azure Web Sites, traditional web site projects can be deployed easily via an FTP client or straight from Visual Studio. PaaS blends the two concepts and provides server level access with the focus on the application.
In addition to “client-maintained” solutions, Kentico also offers a SaaS (Software as a Service) solution in the form of Kentico+. This platform is a Kentico-maintained PaaS solution where all updates / hotfixes are applied by Kentico and companies just focus on their site. It’s a great solution for those not needing much custom code and want to simplify their Kentico EMS site as this is part of each Kentico+ subscription.
TIP
You can find more about Kentico+
here.
Each implementation has pros and cons and your project will determine which is the right fit. It is worth noting that only the Kentico Windows Azure Project type contains the built-in CDN functionality. Many of the other features (DB Web Farm Updater, Dynamic server generation, etc.) are configurable for all project types by adding some keys to the web.config file.
TIP
You can find more about custom web.config settings in the Developer's Guide
here.
As you see there are several benefits to running Kentico in Windows Azure. From integrated CDN functionality to dynamic, flexible deployment options, the combination of the platforms provide a great foundation for any enterprise system. I recommend you check both out and definitely let me know if you have any question about getting your site up and going in the cloud!