It is not uncommon to break up a large site into parts and place each part on a separate subdomain. For example, say we have a popular news site located atwww.example.com. But this site also has a successful blog. Instead of residing under www.example.com, the blog may be reachable at the separate domain blog.example.com. While this appears to be an isolated site, it may be running on the same hardware. Often, subdomain configurations such as this are done when the two parts of the site run different software. For instance the main site may run on Drupal while the blog site may run on WordPress.

This is not the sort of configuration that Drupal's multi-site feature is built for. Drupal does not natively run other applications. But there are other multi-site configurations (for example, Apache's virtual hosting) that can neatly accomplish this.

Sometimes a single operator will run more than one website, and these websites may be completely independent of each other. But to make the most of an existing hosting provider, the operator may choose to run both websites on the same host. This minimizes hosting costs and maintenance hours, but still allows the administrator to host different sites.

I do this, and in my case I have a single account with a web host, and I host multiple sites under that one account. This way I pay one monthly fee regardless of how many sites I operate from that account. And since my sites run Drupal, I take advantage of Drupal's multi-site capabilities.

Maintaining a server is work. A server requires maintenance and upkeep. And the more servers one maintains, the more effort is required to keep everything running smoothly. For that reason, some choose multi-site configurations just to reduce the amount of maintenance work involved in keeping a server running. It also lowers the cost of server hardware, Internet connectivity, and utilities. But this trade off is not without its drawbacks. When a multi-site server goes down, all of the sites on that server will be inaccessible. (A common way of addressing this hazard is to run at least one other redundant server.)

The main method used for setting up this sort of configuration is called virtual hosting, and Apache, Nginx, and other popular web servers support this out of the box. It is a layer higher than Drupal's multi-site feature (though the two can sometimes be used in conjunction).

It is common practice to stage or run quality assurance (QA) testing on server software before pushing it into production. This requires running an identical code base, but on a different set of servers. In an ideal development environment, separate configurations could be stored in such a way that they could be tracked in version control, require little or no configuration when deploying to each of these environments, and pose no security risks.

Drupal's multi-site configuration is often used for this, since staging, QA, and production sites can share the same code base, even with different configuration files. Sites can seamlessly be deployed from one environment to the next.

Taking a step beyond merely easing server administration, even more effort can be saved by sharing not just a server, but the web-serving software as well. Some CMS systems—Drupal is a prime example—can run multiple sites from a single installation of the software. This means that instead of running one instance of Drupal per site, a single download and installation of Drupal can operate several sites. And this eases maintenance and management further: Code only needs to be updated in one place. Modules and themes only need to be placed in one location. In short, it eases not only general system administrative tasks, but also application maintenance tasks.

The HTTP protocol on which the web runs is not itself a secure protocol. Data transmitted over plain HTTP is not encrypted or signed. But HTTPS uses the Secure Sockets Layer/Transport Layer Security (SSL/TLS) mechanism to encrypt and sign content. By leveraging multi-site technologies, it is possible to run two sites on the same domain—one accessible over HTTP, and the other accessible over HTTPS. Often, this is done to provide one level of service for "anonymous" traffic and other tools and services for authenticated users.

This level of configuration is tricky, and requires support in the web server software. Typically, Drupal's built-in multi-site tools are not helpful for this kind of configuration, though there are other Drupal add-on modules that can be very handy in this scenario.

So far, the examples have been centered on serving sites to visitors, but there is another problem space that can be addressed with multi-site configuration. This is site development. Site developers may work on more than one site at a time. Sometimes they work on both the released version of a site, and the upcoming next-generation version. Sometimes they work on several different projects, each with its own site. Regardless, it is much easier to have the option of running multiple sites on a development server, or even on a local workstation.

In my own development, I run a local virtual server (Oracle's VirtualBox), which in turn runs Linux, Apache, MySQL, PHP, and three or four different websites at a time. Running all of these sites in one place makes it easy to manage. In fact, the process has become so efficient for me that I sometimes create a separate site (on the same server) just to test out a new feature or two. As this book proceeds, I will discuss several of the tricks I use for keeping this process simple and effective.

As we will see later, there are other ways of using Drupal's multi-site options to provide sophisticated development environments, such as providing each person on a team with their own configuration file, while still keeping all code (including settings files) in a Version Control System (VCS) . This can be a useful way of improving the efficiency of site development when more than one person is working on the same site.

There are other reasons, of course, for running multi-site installations. The examples shown earlier point out some of the situations in which multi-site technologies come in handy. As we've seen, there are multiple ways of implementing a multi-site configuration, and Drupal isn't always the perfect solution for a multi-site challenge.

To get a better idea for which situations are a good fit for Drupal, we need to learn a little more about what are Drupal's multi-site's strong points, and its weaknesses.