Multisite CMS vs Multiple Websites - Comparison, Advantages, Drawbacks
Multiple websites can be operated with a single multisite instance or as multiple individual websites. The two approaches are technologically different and have advantages and drawbacks. In the following we will compare both to allow decision makers take a informed decision how to best operate a fleet of websites. The comparison applies for Drupal, Wordpress, Typo3, and all other CMS systems that provide a multisite feature.
Technological differences between multisite and multiple websites
Many CMS systems offer multisite functionality. Prominent Open-Source CMS Systems that offer this feature are:
The idea behind multisite is simple: You install a single CMS instance and use it to serve content for different domain URLs.
All websites are run on the same source code in the same installation. In order to separate the content all websites use separate databases or have separate tables in the same database. For uploaded files all websites have separated folders.
The CMS is configured to use a different database and files folder based on the URL of each request. The following graphic shows a typical setup using this mechanism.
The alternative to multisite is operating multiple websites instances that re-use the same source code. The approach is also referred to as operating a website fleet.
With a website fleet all websites are installed individually, but the source code of the CMS is the same.
In most modern CMS systems code dependencies are managed with package managers. Drupal and Typo3 use Composer for this. In such a setup the CMS it self is also a dependency. Because all source code can be installed automatically it does not matter if it is installed on one or many web servers.
Operating multiple websites is a newer and more modern approach. The logic of separating websites is handled in the environment (with routing requests to separate instances) and not in the application (the CMS).
A typical setup with multiple websites is shown in the graphic below.
Both approaches have advantages and drawbacks, that we will analyse in the following sections.
Ease of maintenance and updates
Multisite
Updating a multisite instance is no different from updating a single instance. The new source code is deployed, and update scripts are executed.
However, when very many websites in a multisite instance are updated, this can lead to long downtimes. Example: When an update script takes 1-4 minutes to execute for a website, and these scripts cannot be run in parallel, updating 90 websites takes between 1,5 and 4 hours. This can only be overcome with a powerful infrastructure.
Multiple Website
For multiple websites the downtime is only as long as for the individual website, because they can be updated independently from one another. But if a large fleet of websites needs to be updated, procedures need to be created to automate the process, which requires a deeper devops knowledge.
Risk of updates
Multisite
Multisite has a higher risk when updating. When one update fails all updates need to be rolled back, because the websites cannot run on different versions of the source code.
Multiple Website
For multiple websites, this risk does not exist, because websites for which the update fails can be rolled back and run on the previous source code.
Time to create new websites
Multisite
In a multisite setup new websites are created by adding a new database and a file folder. This is a simple procedure that can even be done manually.
Multiple Website
With individual websites a new environment needs to be created to which the new website is installed. This requires the possibility to create new environments quickly and to automate this. Again, devops knowledge is required.
Infrastructure requirements
Multisite
For a multisite setup a single server instance is required. This is easy to set up and operate.
Multiple Website
Operating a fleet of websites requires the possibility to create new environments for each website.
Scalability
Multisite
In a multisite setup, the sites cannot be scaled individually. The whole infrastructure needs to scale according to the overall load. In a single machine environment, this will be limited by the available hardware.
Multiple Website
With a fleet of websites, each instance can be scaled individually and even moved to a more performant environment. This is a common scenario, as often only a few sites have a lot of traffic while most others only have little.
Developer experience
Multisite
In a multisite setup it is harder to work on changes that only affect some of the websites, because the changes are rolled out to a single server instance. This makes development and testing harder.
Multiple Websites
For a fleet of individual websites this is much easier, because new functionality can be rolled out to some websites and not to others.
Individualisation of websites
Multisite
In a multisite setup the source code is installed for all websites and the availability is handled by the application (the CMS). This requires expert knowledge of the application.
Multiple Website
In a fleet environment with multiple websites extending the source code is a standard procedure that is handled on the environment level (either the source code is added or not).
Final thoughts
If the time and ease to create new websites is the most important factor a multisite approach can be a good option. In our experience manually creating a new Drupal multisite website can be done in around 1 hour.
If modern hosting capabilities and devops are available it can be better to separate websites into several instances. However, provisioning a new environment manually can take several hours based on our experience.
With modern devops, containerization and infrastructure as code, the setup time for a new website in a fleet can be equal or lower than manual multisite. Of course multisite can be automated, too. Therefore, with professional hosting the same deployment times can be achieved.
If the developer experience is important operating different websites is better. Some of our clients have many websites and different teams creating functionality for different websites. Orchestrating such a scenario is easier with individual websites.
If short downtimes are important it is usually better to separate many websites into individual instances. Then only the downtime of the individual websites counts and not the sum of all downtimes.
If individualisation of single websites is important or different teams work on the websites, it is better to work with a fleet of individual websites.
Related blogposts
Transgourmet - Multi-site solution
Transgourmet's corporate websites and microsites were previously implemented and maintained by different teams using different CMS solutions. For a homogeneous brand experience, it was necessary to use a technical style guide. In this case study you can find out how we worked with Transgourmet to solve this problem with them.
1xDXP - Digital Experience Platform (DXP)
1xDXP the enterprise digital experience platform (DXP) for all your digital properties.
This solution is the foundation for all our web projects.
Headless applications with Drupal and React in 2020
Last year we launched more than 20 new webprojects based on Drupal 8 and/or React. Most of the projects have one thing in common: they combine standard Drupal server-side rendering with client side React applications.
DrupalCon 2019 session: Decoupled Drupal Commerce with React Native
This years DrupalCon in Seattle was again a great experience. It was the biggest DrupalCon in terms of number of attendees.
This blogpost is about Drupal Commerce with React Native