Separate Installations vs. Multi-domain vs. Multi-site
It’s not uncommon for online businesses to have multiple web properties other than their online store. Sites such as content portals (news, blogs, etc.), career microsites, education portals, customer support systems, partner or internal training sites, etc. Managing any of these websites can be a challenge without the right systems architecture in place. In this article, I’ll go over 3 common approaches and provide an example of an effective use case for each.
1. Separate installations
Separate codebases, separate databases
The easiest to setup but requiring the most time to manage is a system architecture involving separate installations for each web property. With this architecture, each site is a standalone installation with its own content, codebase and database.
Using separate installations is most appropriate for web properties that are distinctly different from each other in terms of features and functionality or for web properties that require completely different underlying platforms to run.
Separating web properties like this will make development cleaner and better adapted to the needs specific to each site and it will bring better performance scalability compared to other solutions mentioned further down. With separate installations, it’s easier to tweak server configurations and software to match each sites specific needs.
I can give you a good example of this architecture using Acro Media’s own web properties. We have built and maintain an ecommerce demo site called the Urban Hipster. If you click through to it, you’ll see that it’s entirely different from our website that you’re reading this blog on. While it is 100% possible for us to run and maintain these two websites in one of the other architecture types I mention further down, having these running separately makes more sense since there is absolutely no crossover between the two. Everything from codebase to content is more effective for us to manage separately.
2. Multi-site installations
Same codebase, separate databases
The next system architecture type is what we call a multi-site approach. With multi-site installations, all of the web properties included share the same codebase but have different databases. With this architecture, sites may or may not be deployed on the same web server and even their databases may or may not be served by the same database server.
Using multi-site installations is most appropriate for websites that do have a lot of similarities; they share many features, have mostly the same functionality, and are running on the same underlying platform. From a development standpoint, because all the sites under a multi-site installation share the same codebase, making updates and adding features is very efficient. When you’re developing and testing code for one, all other sites will benefit. Each site can still have a different theme (look and feel), but even themes can be shared between each with just minor tweaks to differentiate them. From a training standpoint, staff trained to use one site can effectively use any of the other sites within the multi-site setup. It’s essentially all the same, just the customers and products are different.
Even though these web properties share code, separate databases ensure that there is no crossover of content, user information, and site configuration. This type of setup can be extremely beneficial for businesses who are running multiple storefronts that all require the same ecommerce features and functionality but don’t need to share users or content. Say your parent company has a both a pet supply sub-company and an office supply sub-company under it, the functionality to manage these stores is the same but the products and target customers are entirely different.
I can give another example of this using Acro Media. Our main website and our careers microsite are setup using a multi-site installation. These two sites look very much the same, but they serve entirely different audiences and purposes. They have different content, different menu structures, and we don’t need any crossover between the information submitted by site visitors (i.e. through contact forms). Our corporate site is mostly a sales and marketing tool while the careers site is a tool for our HR and recruitment team. From a development standpoint, one codebase simplifies ongoing maintenance.
3. Multi-domain installations
Same codebase and database
The last system architecture type is a multi-domain installation. With multi-domain installations, all sites share the same codebase AND the same database. They are essentially the same installation but use a clever ecosystem of software to make each site appear different.
With this setup, web properties and their users (both internal and customers) can benefit from:
- Managing content for multiple sites in one place.
- Choose which content is published on which site; each content item can be made available in one or more sites while kept unpublished on others.
- Sites can still have a unique look and feel (but with more limitations than the other two approaches) by enabling different themes on different sites.
It should therefore be clear that multi-domain installations (also sometimes called microsites) are appropriate for sites that require sharing content and users, and are overall very similar; they share mostly the same functionality but they may have differences in configuration and theming.
From a technical perspective Multi-domain sites are always deployed together in the same environment; this applies to both the codebase and the database or other services used, such as an in-site search engine. It is important to note that, because of this, performance and scalability must be carefully considered before making a decision to group together multiple sites in a multi-domain installation. If more than one of the sites has high traffic there may be difficulties in scaling. If one site is hogging resources, this can affect the performance of the other sites. For these reasons, a multi-site installation might be more appropriate instead as it allows more opportunities for arranging deployments in a more scalable way while still presenting the opportunity for sharing the same codebase.
An example of where a multi-domain setup can be a good option is in the education space. If you think about a college or university, these institutions typically have many departmental microsites that are run and maintained by each department. With a multi-domain system architecture, each department can manage their own content while a central administrator can also publish content to each microsite. Logged in users, both staff and students, would most likely want access to all of the microsites without being required to login to each one separately. This type of scenario is possible with a multi-domain approach and I’m sure could benefit many other organizations and businesses, too.
Your strategy is just one piece of the bigger picture
The approaches outlined here should, I hope, give you a good understanding of a strategy that might work best for you, but that’s just the start. The bigger picture is to actually make it happen.
These strategies might not work with you current setup, so you first need to figure out exactly what your digital architecture looks like as a whole and go from there. Many content and/or ecommerce platforms won’t support anything other than separate installations. If this is the case, you may need to swap platforms to get your ideal setup.
Digital commerce consulting companies like Acro Media can help you figure out all of the details. Our approach is to first do a “discovery and strategy” phase which involves looking at your entire tech stack and flow of data to understand the big picture unique to your business. From there, we’re able to effectively recommend which strategy would work best and develop a roadmap to get you there. But that’s not all, this phase is designed to uncover many more ways to improve your whole commerce architecture, automate workflows, and streamline your digital business.