Digital Learnings in Sitecore & Cloud

I have been asked by a number of different people recently about when it is appropriate to maintain a number of different websites on a single Sitecore instance, versus deploying multiple Sitecore instances (on the same or separate hardware) to keep sites separate. As is usually the case, the answer is "it depends", but there are some key conditions that can lead to a clear choice between one over the other. Single Instance In the single instance approach, there is a single installation of Sitecore that hosts all of an organisations sites. This means that there is one IIS website hosting Sitecore per server all sharing the same Sitecore configuration and content. Pros Single set of user access credentials for access to all sites If you are not using LDAP integration for login to your Sitecore instance (or using some other customisation such as federated security through something like ADFS), having a single instance lets you use the same set of Sitec

This will form the second part in a two-post set outlining some of what we learnt whilst implementing xDB and Mongo for a client with enterprise grade availability and security requirements which dictated that a The first post dealt with configuring Mongo and Sitecore to use a replica set for high availability. In this post I'll review some of the options for meeting security requirements around the Mongo implementation for xDB. Security For this project, we had some quite stringent privacy requirements covering some of the types of data that were being stored in the analytics system.  These boiled down to ensuring that only authorised accounts could access the system and view information.  In my opinion the authentication/authorisation approach we've taken should be considered for any xDB installation as a good practice, however the explicit encryption requirements that we had to meet are probably a step further than a lot of organisations will want to go.

As you may already know, Sitecore v7.5 and above has replaced the SQL Server based DMS technology that it has been using for analytics and replaced it with a new approach that uses the No-SQL technology MongoDB for capturing analytics data. Sitecore has a cloud xDB offering available in some geographies (alas it hasn't come to Australia yet!) but we recently delivered an xDB implementation for a client who needed to house their analytics databases on their local hosting infrastructure. This meant that we had to consider how to meet some of the enterprise requirements with Mongo that we had been pretty comfortable dealing with in DMS with SQL Server.   In particularly our high availability and security requirements had to be addressed slightly differently. This will form the first part in a two-post set outlining some of what we learnt along the way.  The second post deals with configuring Sitecore and MongoDB for enterprise security requirements . High Availability  MongoDB

In the overwhelming majority of Sitecore installations that we deliver for clients, content authors want to use the Active Directory integration module to login to Sitecore -- understandable, who wants to have another login!  As outlined in my previous post about recursive AD synchronisation , it is actually quite simple to set up the Sitecore AD module to use your AD roles and user accounts to enable Sitecore login. One of Sitecore's little idiosyncrasies is that by default it will log you in to the content editor application, which I find is the least useful thing for most content authors.  Generally we want to log content authors into the Sitecore Desktop.  This is not a setting that you can set on a role, instead it is a setting of the user's profile. You can definitely go an individually update each of the users that have been created by the  AD module to by default log the user into the desktop, but we don't want to have to do that every time we create a new us

In my previous post in this series, I looked at how you can use cloud platform features to provide automated fail-over between onsite and cloud hosted Sitecore installations in the case of a disaster causing a complete site outage.  In this post I look at some of the key software design decisions that you need to consider when you are planning your cloud deployment. 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 - Disaster recovery What about my application logic?  In the majority of cases when we deliver Sitecore websites for our clients, the web aspect is just a part of the overall solution.  Most of the time there is complex application logic, potentially storing data provided by users and/or integration into back-end services usually fronting line of business systems that are located on hardware running inside the corporate networ