Una universidad nunca es un solo sitio web. Es el sitio institucional principal, más sitios independientes para cada facultad, departamento, centro de investigación, biblioteca y, a menudo, docenas de proyectos, laboratorios y eventos individuales. Una universidad grande puede fácilmente gestionar entre 50 y varios cientos de sitios distintos. El desafío no está en construir uno solo de ellos, sino en gestionarlos todos juntos: mantenerlos seguros, coherentes con la marca y actualizados sin necesidad de un equipo y una pila tecnológica independientes para cada uno. Este es el problema que Drupal multisite está diseñado para resolver, y es una gran parte de la razón por la que tantas de las principales universidades del mundo funcionan con Drupal.
Este artículo explica cómo funciona Drupal multisite, por qué se adapta tan bien al caso de uso universitario, cómo se compara con las alternativas y, con la misma importancia, cuándo es la elección equivocada. El objetivo es ofrecer una imagen clara y honesta que ayude a una institución a decidir si multisite es la arquitectura adecuada para su patrimonio web.
El problema de los múltiples sitios que enfrenta toda universidad
Las universidades son, por naturaleza, descentralizadas. Cada facultad quiere tener control sobre su propio sitio, cada departamento tiene su propio contenido y sus propios editores, y el departamento central de TI es responsable de mantener todo el patrimonio seguro, accesible y coherente. Si se deja sin gestionar, esta tensión produce un desorden familiar: los departamentos crean sus propios sitios no autorizados en la plataforma que les resulte conveniente, la coherencia de marca se derrumba, los parches de seguridad se aplican de forma desigual o directamente no se aplican, y nadie tiene una visión completa de lo que está en funcionamiento.
La decisión de plataforma, dicho de otro modo, es en realidad una decisión de gobernanza disfrazada. La pregunta que una universidad necesita responder no es solo "qué CMS deberíamos usar", sino "cómo permitimos que docenas de equipos gestionen sus propios sitios mientras TI central mantiene todo el patrimonio seguro y coherente". Drupal multisite es una de las respuestas más sólidas a exactamente esa pregunta.
Qué es realmente Drupal multisite
Drupal es uno de los pocos sistemas de gestión de contenidos que admite multisite de forma nativa en su núcleo. Un Drupal multisite es una única instalación de Drupal que ejecuta múltiples sitios web a partir de una base de código compartida. El detalle técnico importante es qué se comparte y qué no: los sitios comparten el código —el núcleo de Drupal, los módulos y los temas—, pero cada sitio tiene su propia base de datos independiente. Esto significa que el contenido, la configuración, los usuarios y los archivos subidos están completamente separados por sitio, aunque todos se ejecuten sobre la misma instalación subyacente.
A nivel mecánico, cada sitio reside en su propio subdirectorio dentro de la instalación, con su propio archivo de configuración que apunta a su propia base de datos. Cuando llega una solicitud, Drupal examina el dominio o la URL y carga la base de datos y la configuración del sitio correspondiente. El resultado práctico es un conjunto de sitios que parecen y se comportan como sitios web completamente independientes —cada uno con su propia identidad de marca, contenido y equipo editorial— mientras comparten por debajo una única base de código y un único proceso de actualización. Se actualiza el código una vez, y todos los sitios pasan a ejecutar la nueva versión.
Por qué las universidades confían en multisite
El modelo multisite se ajusta casi a la perfección a cómo funciona realmente una universidad. Stanford, Yale, Harvard y Duke gestionan sus propias plataformas de sitios Drupal a gran escala siguiendo este principio, e instituciones como University College London administran 500 o más microsites desde una sola capa de gobernanza. Las ventajas que hacen que esto funcione son concretas:
- Actualizar una vez, desplegar en todas partes: Un parche de seguridad o una actualización de versión de Drupal se aplica una sola vez a la base de código compartida y surte efecto en todos los sitios. En lugar de parchear 200 sitios individualmente, TI central ejecuta una única actualización, el ahorro operativo más importante que ofrece multisite.
- Gobernanza central con autonomía local: TI central gestiona la arquitectura, la seguridad y el sistema de diseño, mientras que cada facultad y departamento conserva el control editorial total de su propio contenido. Los departamentos obtienen su independencia; la institución conserva su coherencia.
- Coherencia de marca a gran escala: Un sistema de diseño y componentes compartidos significan que cada sitio puede mantener una identidad de marca y unos estándares de accesibilidad coherentes, en lugar de que cada uno derive en su propia dirección.
- Desarrollo compartido: La funcionalidad personalizada se construye una sola vez y se pone a disposición de todos los sitios. Un módulo o funcionalidad desarrollada para una facultad puede activarse para las demás sin necesidad de reconstruirla.
- Incorporación eficiente de nuevos sitios: Cuando un nuevo departamento o programa necesita un sitio, este puede aprovisionarse rápidamente desde la plataforma compartida, partiendo de la misma base segura, accesible y coherente con la marca, en lugar de empezar desde cero.
Para una institución que gestiona un gran patrimonio de sitios, estas eficiencias se acumulan. Este es exactamente el patrón que explica el dominio de Drupal en la educación superior, y se conecta directamente con las fortalezas más amplias de la plataforma en el sector, que abordamos en nuestro resumen sobre Drupal en el sector educativo.
Multisite no es la única opción
El multisite clásico es una forma de ejecutar muchos sitios desde Drupal, pero no la única. Elegir la arquitectura adecuada desde el principio ahorra tiempo y costos significativos más adelante, por lo que merece la pena conocer las principales alternativas.
| Enfoque | Cómo funciona | Mejor adaptado para |
|---|---|---|
| Multisite clásico | Una base de código, una base de datos independiente por sitio. Contenido completamente aislado. | Muchos sitios estructuralmente similares que necesitan una fuerte separación de contenido. |
| Domain Access | Una base de código y una base de datos compartida; un módulo controla qué contenido pertenece a qué dominio. | Sitios que comparten mucho contenido y editores, gestionados de forma centralizada. |
| Instalaciones separadas | Cada sitio es su propia instalación independiente de Drupal, a menudo gestionada con un flujo de trabajo compartido de Composer. | Sitios que difieren significativamente, o que necesitan aislamiento total y escalado independiente. |
| Distribución / upstream | Una compilación estándar de Drupal se empaqueta y se usa como punto de partida para cada nuevo sitio independiente. | Lanzar muchos sitios a partir de una base común manteniéndolos independientes. |
La distinción clave es aislamiento de contenido frente a compartición de contenido. Multisite otorga a cada sitio su propia base de datos y la separación más fuerte. Domain Access comparte una única base de datos, lo que facilita compartir contenido y editores, pero acopla los sitios de forma estrecha. Las instalaciones separadas ofrecen el máximo aislamiento e independencia a costa de gestionar cada una individualmente. La respuesta correcta depende de si sus sitios son variaciones de un mismo tema que deberían compartir, o patrimonios genuinamente independientes que no deberían hacerlo.
Las contrapartidas honestas: cuándo multisite es la elección equivocada
Multisite es potente, pero no está exento de riesgo, y una evaluación responsable debe sopesar los inconvenientes con la misma seriedad que los beneficios. La eficiencia de una base de código compartida es también su debilidad central: crea un único punto de fallo.
- Destino compartido: Dado que todos los sitios se ejecutan sobre una misma base de código, un problema en esa base de código afecta a todos los sitios a la vez. Un pico de tráfico en un sitio puede degradar el rendimiento de todos los demás, y una brecha de seguridad es más difícil de contener: si un sitio es vulnerado a través del código compartido, los demás también pueden quedar expuestos.
- Aislamiento limitado: No existe una segmentación fuerte entre sitios a nivel de código, lo cual es una consideración genuina para instituciones con requisitos estrictos de seguridad o cumplimiento normativo. Donde los sitios deben estar completamente aislados, las instalaciones separadas son el modelo más seguro.
- Acoplamiento de mantenimiento: Algunas operaciones, como ciertas actualizaciones, pueden requerir que todos los sitios entren en modo de mantenimiento a la vez, y separar un sitio de un multisite más adelante no es una tarea trivial.
- Divergencia con el tiempo: Si los sitios se distancian en sus necesidades de código o configuración, la vía de actualización compartida puede bifurcarse, y la simplicidad que justificaba el multisite comienza a erosionarse.
Los flujos de trabajo modernos de Drupal han hecho que las alternativas sean más atractivas de lo que solían ser. Un flujo de trabajo basado en Composer que gestiona instalaciones separadas, o una plataforma que aprovisiona sitios aislados a partir de un upstream compartido, puede ofrecer gran parte de la coherencia de multisite sin el riesgo de un destino compartido. Multisite sigue siendo una excelente opción para un gran patrimonio de sitios similares y bien gobernados, pero para sitios que necesitan aislamiento genuino, escalado independiente o divergencia significativa, a menudo es la herramienta equivocada. La regla honesta es elegir multisite porque sus sitios son genuinamente similares y se gobiernan de forma centralizada, no simplemente porque parezca reducir el número de sitios.
Gobernanza: la verdadera razón por la que esto importa
Por debajo de la arquitectura técnica, lo que una universidad realmente adquiere con multisite es un modelo de gobernanza. El problema más difícil en la gestión web universitaria no es construir sitios, sino coordinar a docenas de equipos autónomos sin ahogar su independencia ni perder el control central.
Una plataforma multisite bien gestionada resuelve esa tensión de manera explícita. TI central es propietaria de la capa compartida: la base de código, las actualizaciones de seguridad, el sistema de diseño, los estándares de accesibilidad y la arquitectura general. Las facultades y los departamentos son propietarios de su contenido: sus propios editores, sus propios calendarios de publicación, su propia estructura específica del sitio dentro del marco compartido. Dado que los roles y permisos se definen de forma centralizada, cada equipo obtiene exactamente el acceso que necesita y nada más. El resultado es autonomía donde ayuda —el contenido— y coherencia donde importa —la seguridad, la marca y el cumplimiento normativo—. Ese equilibrio es el verdadero producto, y es la razón por la que la elección de plataforma es, en última instancia, una decisión de gobernanza más que una puramente técnica.
Errores comunes en multisite y cómo evitarlos
- Elegir multisite para reducir el número de sitios: La razón para usar multisite es la similitud genuina y la gobernanza compartida, no un número menor en un servidor. Elija la arquitectura que se ajuste a cómo se relacionan realmente los sitios, no la que parezca más ordenada.
- Ignorar el punto único de fallo: Una base de código compartida implica un riesgo compartido. Planifique con prácticas de seguridad sólidas, margen de rendimiento suficiente y una comprensión clara de qué ocurre si un sitio tiene un mal día.
- Forzar la convivencia de sitios muy diferentes: Los sitios con necesidades de código o configuración significativamente divergentes tensionan el modelo compartido. Si la divergencia es real, las instalaciones separadas sirven mejor que un multisite forzado.
- Subestimar el costo de salida: Separar un sitio de un multisite más adelante es difícil. Planifique la arquitectura teniendo en cuenta una posible separación futura, en lugar de asumir que los sitios permanecerán juntos para siempre.
- Descuidar la gobernanza: La tecnología por sí sola no crea orden. Sin un modelo claro de quién es propietario de la capa compartida y quién es propietario del contenido de cada sitio, incluso un multisite bien construido termina derivando en confusión.
- Permitir que los sitios diverjan sin control: Dejar que cada sitio acumule su propio código a medida erosiona la ventaja de la base de código compartida. Mantenga las personalizaciones disciplinadas y, siempre que sea posible, compartidas.
Bien gestionado, Drupal multisite permite a una universidad ejecutar un patrimonio web extenso y coherente desde una sola plataforma: TI central mantiene todo seguro y coherente con la marca, mientras que cada facultad y departamento conserva el control de su propio sitio. Es una de las razones más claras por las que Drupal se ha convertido en la opción predeterminada en la educación superior, y se combina de forma natural con las fortalezas de la plataforma en contenido multilingüe, accesibilidad e integración con sistemas académicos.
Preguntas frecuentes sobre Drupal multisite
¿Los sitios en un multisite comparten contenido entre sí?
No, en un multisite clásico no. Cada sitio tiene su propia base de datos independiente, por lo que el contenido, los usuarios y la configuración están aislados: los sitios solo comparten el código subyacente. Si compartir contenido entre sitios es un requisito, ese es un caso para una arquitectura diferente, como Domain Access, que utiliza una única base de datos compartida y le permite controlar qué contenido aparece en qué sitio. La elección entre ambos se reduce a si sus sitios deben estar aislados o deben compartir.
¿Cuántos sitios puede ejecutar un único Drupal multisite?
No existe un límite fijo, y las grandes instituciones gestionan cifras considerables: universidades como University College London administran 500 sitios o más, y algunas implementaciones alcanzan cientos o más. El límite práctico lo determina menos Drupal en sí mismo que la infraestructura, la disciplina de gobernanza y el grado de similitud entre los sitios. Cuantos más sitios ejecute sobre una misma base de código, más importantes se vuelven las prácticas operativas sólidas y la planificación del rendimiento, porque todos comparten el destino de esa base de código.
¿Se está descontinuando Drupal multisite?
No. Multisite es una función del núcleo muy valorada y no se está eliminando. Ha habido debates en la comunidad sobre cómo mejorar su funcionamiento con herramientas modernas como Composer, y esas mejoras han avanzado, pero la funcionalidad en sí sigue siendo compatible. Dicho esto, el ecosistema ofrece ahora alternativas sólidas —entre ellas instalaciones separadas gestionadas con Composer y upstreams basados en plataformas—, por lo que la pregunta moderna no es tanto "¿está disponible multisite?" como "¿es multisite la opción adecuada para este patrimonio en particular?".
Multisite o instalaciones separadas: ¿qué debería elegir una universidad?
Depende de cuán similares y cuán aislados deban estar los sitios. Multisite se adapta a un gran patrimonio de sitios estructuralmente similares que comparten un sistema de diseño y deberían actualizarse juntos, con gobernanza centralizada: el escenario clásico de los sitios departamentales universitarios. Las instalaciones separadas se adaptan a sitios que difieren significativamente, necesitan aislamiento total por motivos de seguridad o cumplimiento normativo, o deben escalar de forma independiente. Muchas universidades optan por multisite para la mayoría de sus sitios departamentales y por instalaciones separadas para todo aquello con requisitos genuinamente distintos. La decisión debe seguir la relación real entre los sitios, no solo una preferencia por menos piezas móviles.