Digital Learnings in Sitecore & Cloud

In my previous posts in this series, I looked at how you 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.  In this post I look at how you can use the benefits of the cloud to provide automated DR failover for your existing on-premise hosted website. Other posts in this series Cloud hosting Sitecore - High Availability Cloud hosting Sitecore - Scaling for peak loads Cloud hosting Sitecore - Serving global audiences Cloud hosting Sitecore - Cloud development patterns Pattern 4: Disaster Recovery Sometimes you don't need to have Sitecore running actively at multiple locations, and perhaps you are already providing hosting on premises and only want to use the cloud to provide a standby service in the event of an outage of the primary hosting environment.

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. Other posts in this series Cloud hosting Sitecore - High Availability Cloud hosting Sitecore - Scaling for peak loads Cloud hosting Sitecore - Disaster recovery Cloud hosting Sitecore - Cloud development patterns 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

In my first post in this series, I looked at options for automated deployment of Sitecore in the cloud to deliver high availability.  In this second post we take a look at how we can auto-scale these environments in and out to address different load scenarios. Other posts in this series Cloud hosting Sitecore - High Availability Cloud hosting Sitecore - Serving global audiences Cloud hosting Sitecore - Disaster recovery Cloud hosting Sitecore - Cloud development patterns Pattern 2: Scaling for peak loads One of the key benefits of cloud platforms is their ability to scale horizontally by adding new instances of application nodes.  In the case of a web site like those served by Sitecore this generally means adding additional content delivery nodes to the web farm. Sometimes you know when peak loads occur.  This could be a regular peak such as Monday morning or a planned occasion such as an event or even a large newsletter broadcast.   Other times you don't see a peak

The approach to hosting web facing systems has changed significantly over the last few years, with virtual machines almost completely replacing physical infrastructure.  These private cloud virtual server farms allowed server instances to be built and run on consolidated hardware, simplifying purchasing for IT departments.  This cloud computing pattern is generally known as Infrastructure as a Service (IaaS), and it simplified the way that physical hardware was purchased, whilst supporting the same approach to building and deploying applications that had been used before.  Public cloud hosted IaaS platforms remove the purchasing requirements, whilst providing a high degree of flexibility in how services are hosted, however IT teams still had to install and configure operating systems and other system software like content management and database systems the same way as with traditional environments.   Amazon Web Services and Microsoft Azure are currently the two leading IaaS cloud

As with any publicly (or internally) accessible web application, it is vitally important to make sure that your Sitecore installation is appropriately configured to protect it against attacks from malicious forces on the net. The primary reference to follow when configuring the security of your Sitecore instance is of course the Sitecore Security Hardening Guide .  However there are a few additional steps that you should consider following when configuring Sitecore to provide additional security against some known attack vectors where your Sitecore installation may be vulnerable.  All the recommendations and issues listed below appear to still be valid as of Sitecore v7.1 Extra restrictions on the /sitecore folder on delivery servers The Hardening Guide recommends restricting Anonymous user access to the /sitecore/admin , /sitecore/debug and /sitecore/shell/WebService folders.   My recommendation on delivery server instances is to go further and restrict anonymous access to al

Sitecore supports having multiple website stored within a single Sitecore instance.   This has a number of advantages for content authors including: It makes it easy to share content between the different sites, and  One DMS database is used for all the sites in the instance it is easy to gather information about users from across the multiple sites and use it to drive personalisation.   However there is a down-side to having multiple sites within the same Sitecore instance, there is one IIS web site containing all the code and configuration files for all the sites in the instance.  This can impact long term support of the Sitecore instance: When you make updates or perform deployments for one site you will impact the other sites in that instance. Whenever the \bin folder or web.config of your Sitecore (or any .NET) site you cause the worker process to recycle, and some deployments (e.g. those requiring breaking code and Sitecore changes across multiple delivery servers) can