Sitecore - multi-site or multi-instance?

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 Sitecore managed users to access all of your sites.  If the logins live inside Sitecore then they will be different per Sitecore instance.

Easier to share content between sites

Having a single Sitecore instance means that all content is directly accessible and addressable through Sitecore.  You can  share content items as data sources in renderings across sites, or even address them in item buckets as I outlined in a previous post on sharing item bucket pages between websites.   Furthermore Sitecore functionality like clearing HTML caches on publish work natively as expected. 

If instances are separated, then content on the other instance is treated more like content on any external sites, and you would need to consider approaches such as RSS feeds, Item Web API or even Data Providers if you want a more Sitecore integrated approach.

Easier tracking of visitors

All websites in a Sitecore instance share a single xDB database, so it is easy to capture web analytics information across the different sites and see it in a consolidated view.  

Cons


Deployments


The major drawback to having all your websites in a single Sitecore instance comes with making changes to your site.   Any time you make a code change you are effectively making a change that could impact all the sites running on the instance.

There are a number of ways that you can mitigate this risk:
Firstly you need to do some more planning of your architecture upfront, to reduce the coupling between code of multiple sites, and to allow sites to be taken offline independently.  I outlined this approach in a previous blog about maintainable multi-site Sitecore instances.

Even with these mitigations , deployments  to multi site instances will always have a higher risk of regression across sites, particularly as there will inevitably sometimes need to be or changes to the underlying platform effecting all sites at once (such as upgrades).

Multiple Instances

In a multi-instance configuration, websites are implemented in separate IIS websites, with separate installations of Sitecore, separate code bases and separate underlying content.


Pros


Complete separation of websites


This approach gives you complete separation of the websites.  There are two completely separate code bases that can be deployed absolutely independently.  If the sites are hosted on different hardware, this also gives separation down to that level so rebooting a server in one environment won't impact other sites.  This allows you to absolutely confirm that there is no cross-effect on other websites when you do a deployment.


Cons


xDB and Analytics


As of v8.1 Sitecore doesn't support sharing a single xDB between more than one Sitecore instance.  If you need to get a shared view of analytics information between sites in this architecture, you need to export the data fro the individual xDB instances and use a BI tool or data warehouse to get a shared view.  Sitecore does provide some tools to address this, notably the Experience Extractor, and in some enterprise environments there is a need to do this sort of extraction and raw data manipulation anyway,  but it does mean that the analyics story is more complicated.

Sharing content or navigation


As noted above, sharing content is more difficult when sites are separated onto multiple instances, with approaches like RSS feeds, Item Web API or even Data Providers needed.  One thing which is often difficult is where there is a shared navigation across the multiple sites (for example, when there are two sites owned by different business units, but the organisation wants  to present the illlusion of them being a single site to end users.  In these scenarios building a unified navigation is much more complex, as site structure information needs to be obtained from both sites (RSS, Xml sitemap etc) and then merged.

Sharing search


Most of our clients are currently either using Lucene.NET or Solr for their website search, however Sitecore doesn't currently support indexing of sites from multiple instances into a single index on either of these products.  This means that search cannot scan across the multiple sites in a single query.

This can be addressed by providing Web API endpoints for search on each instance, calling these and combining results (although this often makes logic like calculating paging and sorting difficult).  Alternaticely an external search approach like Funnelback or GSA which crawls websites rather than integrating into Sitecore directly can be used.

Licensing


Always the elephant in the room, Sitecore licensing has long been a significant restriction on the multiple instance approach for organisation who do not already have an all-you-can-eat enterprise Sitecore license. 

 Traditionally Sitecore licenses based on the number of instances installed - this means that even having two separate IIS websites with separate Sitecore installs and databases on a single delivery server counts as two.  Sitecore 8.1 has introduced some new licensing models that give an options more heavily weighted to usage (contacts/interactions), however the number of instances still has some impact on licensing even in this model.

In conclusion...


The correct choice of architecture is really going to be a matter of how significant you feel the risk is for deployments, against the number of trade-offs that you need to make to move to a separate instance architecture.

We generally find that the risks of a multi-site setup on a single Sitecore instance are far out-weighed by the benefits of easier sharing of content, search and analytics information (and of course lower licensing).  That said there are definitely instances where separation of instances is clearly warranted.  These are usually the cases where an organisation has a main, mission critical website that is very self contained, and a number of smaller websites which are less important overall. 


Comments

  1. I like your summary Cameron. These scenarios are never straight forward - so, as you point out, it is a matter of weighing up which scenario fits your business model and of course your sitecore licensing arrangement too.

    ReplyDelete
  2. Have you looked at single CM with multiple separate CD setup as different publishing targets?

    Guessing that would let you share content, potentially web publish functionality separately (although that could end up complex on CM). No idea what that would do with xDB though.

    ReplyDelete
    Replies
    1. Yes, have seen something similar to this, where the code base was separate for separate sites but served from same content database. This helps with separation of code base but means you need more licensing (e.g. 2 sites with two CDs ends up requiring 4 CD instance licenses instead of 2) - also still need to have a good way to separate Sitecore items (e.g. shared templates) to ensure deployment doesn't introduce regression.

      Also looked at an approach based on publishing targets. However this seemed like it would get overly complex to maintain quite quickly particularly where content or templates were shared. I think the best use of publishing targets is really for pushing local copies of content to geographically separate CD clusters (as is the case with the Azure module).

      I suspect that the xDB stuff would work fine in these scenarios, as there isn't any risk of things like Item IDs colliding (which seems like the main risk preventing support of xDB across instances). It isn't too dissimilar to the architecture of having separate session storage on remote CD clusters all flushing back to a single xDB.

      Delete
  3. http://stackoverflow.com/questions/33799801/sitecore-share-monbodb-db-for-multiple-sitecore-instances suggests an xdb can be shared, maybe not officially?

    ReplyDelete
    Replies
    1. I'm not sure Richard has really addressed the original question about sharing xDB across instances in his answer - the way I understand it he is talking more about multi-site rather than multi-instance. His suggestion about having a Mongo replica set member on the processing server with a readpreference to optimise performance is interesting though.

      Delete
  4. I was confused until I came across your blog, brilliant explanation.

    Thanks Cameron.

    ReplyDelete
  5. Nice explanation, Cameron. Thanks !

    I want to share my scenario -

    One of our client has multiple websites in .net and we need to migrate all the websites to Sitecore . Client has 3 brand websites and 3500 dealer websites which needs to be create and host on Sitecore platform. We also needs personalization across all the websites.

    Whic approach is better and why ?

    ReplyDelete

Post a Comment

Popular posts from this blog

Cloud hosting Sitecore - High Availability

Setting up TDS to work with Azure DevOps