Cloud hosting Sitecore - Serving global audiences
In my previous posts in this series, I looked at options for automated deployment of Sitecore in the cloud to deliver high availability and how to use the features of AWS and Azure to auto-scale your environments. In this third post we take a look at how we can use the global reach and deployment automation capabilities of the cloud to provide Sitecore installations that support users located at various points around the globe without compromising on the analytics and personalisation capabilities of the Sitecore platform.
Many organisations, even those that do not themselves have a global footprint, need to serve a global audience. One of the key issues servicing users coming from multiple places across the globe is that network latency can start to impact the perceived performance of your site based on where a particular user is located, and even a one second degradation of page performance can significantly erode the use of your site.
One way of addressing this issue is the use of Content Delivery Networks (CDNs) to cache parts of the website closer to these global users, however using this approach can affect the usefulness of Sitecore's personalisation and analytics functionality. An alternative option is to have multiple global delivery farms and direct users to the closest one.
The release of Sitecore 7.5 makes this an even more attractive approach, as the new xDB architecture specifically supports local analytics collection databases in each of several different delivery server clusters in different locations, with aggregation of the data to a central reporting server on the fly.
The Sitecore Azure module will automatically provision a traffic manager instance using the Performance balancing method, and associate all production Sitecore delivery farms created to it, so all you need to do to take advantage of this feature is deploy your site to data centre locations close enough to you users to achieve sufficiently low latency. The module creates separate connection strings and publishing targets for each of the delivery farms, allowing content Authors to publish content to each of the different farms and keep them synchronised.
As noted previously, a Sitecore delivery farm will need to be provisioned and installed for each location from which you want to serve requests. This is an example of where CloudFormation can be useful as you can create a template for a delivery server farm, and then use CloudFormation to deploy it to multiple AWS locations. Sitecore will need to be updated to add publication targets for each farm.
Each DNS record can have a routing policy applied, and the geolocation policy allows a geographic location, either a continent, country or US state, to be specified for that record. The DNS record returned for a particular user will be depend on a lookup of the source location for the IP address requesting the DNS record, and a record configured to map against the Default geolocation record needs to be provided for the case where the system doesn’t have a location mapping for an address.
Other posts in this series
Pattern 3: Serving global audiences
Many organisations, even those that do not themselves have a global footprint, need to serve a global audience. One of the key issues servicing users coming from multiple places across the globe is that network latency can start to impact the perceived performance of your site based on where a particular user is located, and even a one second degradation of page performance can significantly erode the use of your site.
One way of addressing this issue is the use of Content Delivery Networks (CDNs) to cache parts of the website closer to these global users, however using this approach can affect the usefulness of Sitecore's personalisation and analytics functionality. An alternative option is to have multiple global delivery farms and direct users to the closest one.
The release of Sitecore 7.5 makes this an even more attractive approach, as the new xDB architecture specifically supports local analytics collection databases in each of several different delivery server clusters in different locations, with aggregation of the data to a central reporting server on the fly.
Microsoft Azure
Microsoft Azure provides a global Traffic Manager capability which allows you to host multiple Sitecore delivery farms in different Azure data centres across the world, and then route page requests for globally distributed users to the closest servers. This is the behaviour of Traffic Manager’s “Performance” load balancing method.The Sitecore Azure module will automatically provision a traffic manager instance using the Performance balancing method, and associate all production Sitecore delivery farms created to it, so all you need to do to take advantage of this feature is deploy your site to data centre locations close enough to you users to achieve sufficiently low latency. The module creates separate connection strings and publishing targets for each of the delivery farms, allowing content Authors to publish content to each of the different farms and keep them synchronised.
Amazon Web Services
AWS provides DNS via the Route 53 service which includes support for geolocation routing. This allows you to specify which Sitecore delivery farm will serve requests for a user based on their location in order to reduce the latency incurred.As noted previously, a Sitecore delivery farm will need to be provisioned and installed for each location from which you want to serve requests. This is an example of where CloudFormation can be useful as you can create a template for a delivery server farm, and then use CloudFormation to deploy it to multiple AWS locations. Sitecore will need to be updated to add publication targets for each farm.
Each DNS record can have a routing policy applied, and the geolocation policy allows a geographic location, either a continent, country or US state, to be specified for that record. The DNS record returned for a particular user will be depend on a lookup of the source location for the IP address requesting the DNS record, and a record configured to map against the Default geolocation record needs to be provided for the case where the system doesn’t have a location mapping for an address.
Up next...
In the next installment of this series, we'll have a look at how you can use the cloud to host your Sitecore Disaster Recovery environment and provide automated failover in the case of an outage to your primary hosting environment.
Comments
Post a Comment