Multisite CMS vs Multiple Websites - Pros and Cons
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.
Other highlights
Why building on a preconfigured Drupal CMS is a wise investment
Drupal is a versatile CMS with extensive customization options. Configuring it correctly can be...
Using a MVP approach for web projects
At 1xINTERNET we use a MVP (Minimum Viable Product) approach for delivering successful web projects...