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.