Un grupo con varias empresas o marcas
Cada filial quiere su imagen, su catálogo y su administración, y la matriz quiere ver el conjunto. Los dos requisitos tiran en direcciones opuestas.
Moodle · Arquitectura
Moodle™ multitenant y multiinstancia: he implantado separación lógica y despliegues independientes para distintas organizaciones
He resuelto este problema con dos patrones distintos: separación lógica dentro de una plataforma y despliegues independientes coordinados. No elijo por el nombre de la solución, sino por el aislamiento que necesita cada organización, quién administra la plataforma, qué debe compartirse y cómo gestiono las actualizaciones, los informes y la recuperación.
- He trabajado las dos separaciones: por infraestructura, con varias instalaciones unificadas por acceso único y portal, y por lógica, dentro de una misma instalación.
- La pregunta que más veces ha decidido el modelo es si alguien tendría que responder «cuántas personas se han formado en todo el grupo».
- El coste que más veces he visto subestimar no es el de infraestructura: es el de las personas que operan cada entorno.
- Compruebo si la plataforma ofrece separación lógica. Cuando no la ofrecía, he trabajado con el equipo para construirla, y eso añade trabajo en cada actualización.
Experiencia en arquitectura
Elijo entre separación lógica, varias instalaciones o campus independientes según el aislamiento de datos, la administración, el contenido común, las actualizaciones y los informes. Compruebo que los permisos no crucen organizaciones y valoro la divergencia de versiones, las identidades duplicadas y el coste operativo de cada arquitectura.
Mi trayectoriaLas seis preguntas con las que tomo la decisión
Las planteo en este orden. Las dos primeras suelen bastarme para decidir.
- 01
¿Existe una exigencia de separación de datos?
Descarto la separación lógica si un contrato, una normativa o el responsable de protección de datos exige que los datos de una organización no compartan base de datos con los de otra. Es el requisito que más veces he visto cerrar la conversación en la primera reunión.
- 02
¿Alguien tendrá que responder por la formación de todo el grupo?
Si alguien debe informar de cuántas personas se han formado en todo el grupo y con qué resultados, uso una sola instalación siempre que el modelo de datos, los permisos y los informes permitan evitar la consolidación entre entornos. Con varias instalaciones, normalmente consolido los datos fuera de ellas.
- 03
¿Comparten contenido?
Comparto el contenido común sin sincronización si todas las organizaciones consumen el mismo recurso. Si cada organización trabaja con copias, plantillas derivadas o ediciones separadas, uso un procedimiento de propagación aunque todo esté en una sola instalación.
- 04
¿Pueden pararse todas a la vez?
Fijo una ventana común para una instalación compartida. Los calendarios incompatibles entre organizaciones —una tiene exámenes cuando otra necesita actualizar— me llevan a separar las instalaciones.
- 05
¿Cuántas personas operan las instalaciones?
Cada entorno adicional suma copias, vigilancia, actualizaciones y soporte. He visto instalaciones sin actualizar durante meses porque no había manos. Esa desatención pone en riesgo la seguridad.
- 06
¿Cuántas organizaciones habrá dentro de tres años?
La opción que funciona con tres puede ser inviable con treinta. Comparo el coste de anticipar esa escala con el de migrar más adelante y dejo explícitos los supuestos de crecimiento.
Cuándo hay que tomar esta decisión
Tomo esta decisión en cuatro situaciones bastante reconocibles. En tres, ya hay algo montado y debo moverlo.
Formación que se vende a terceros
Separo cada organización de las demás para que no puedan verse entre sí. A veces, además, el contrato lo exige. En esos casos, el aislamiento deja de ser una preferencia técnica.
Una administración con organismos dependientes
Analizo por separado la normativa, el calendario y la persona responsable de los datos de cada organismo. También reviso los servicios comunes y el contenido que comparten a veces.
Cuando ya hay varios campus sin coordinación
Detecto un problema de capacidad en campus que nacieron por separado: el equipo no da abasto para coordinar las actualizaciones, consolidar las cifras de personas y mantener el mismo nivel de seguridad.
Qué separa realmente cada opción
Comparo cómo se comportan las tres alternativas en cuatro planos antes de hablar de soluciones concretas.
- 01
Los datos y el alcance de un incidente
En una instalación compartida, las organizaciones comparten la aplicación y normalmente parte de sus datos o recursos. La base de datos, el almacenamiento y el cómputo pueden estar distribuidos, pero compruebo qué fallos y controles siguen teniendo un alcance común. En instalaciones separadas, compruebo si la base de datos y el almacenamiento pueden aislarse por entorno. También reviso si los recursos compartidos, las credenciales, la red y la operación están separados o segmentados: sin esa condición, el incidente no queda contenido. Si un contrato exige separación, traduzco esa exigencia en controles comprobables, no solo en una topología.
- 02
Quién administra y hasta dónde
Con la separación lógica, delego la administración de cada organización sin ceder el control de la plataforma: cada responsable gestiona lo suyo y no ve lo demás. Si separo las instalaciones, compruebo de qué servicios, controles y decisiones comunes sigue dependiendo la autonomía de cada entorno.
- 03
El contenido común
En una sola instalación evito la sincronización entre entornos, pero defino un modelo propio para cada recurso: permisos y visibilidad para el catálogo, un procedimiento de actualización para las plantillas y, desde Moodle 5.0, bancos compartidos con los roles y las capacidades adecuados. Entre varias instalaciones decido qué copio, cuándo, en qué dirección y qué versión prevalece si el destino la ha modificado.
- 04
Las actualizaciones y los informes
Con una sola instalación, aplico cada actualización una vez y coordino una ventana común entre organizaciones con calendarios distintos. Con varias instalaciones, mantengo ritmos propios, aunque eso genera divergencias entre versiones. En una instalación compartida, genero el informe agregado sin consolidar varios entornos siempre que el modelo de datos, los permisos y los informes lo permitan. Con instalaciones separadas, uso una capa de consolidación, que puede estar ya automatizada.
Lo que suele salir mal
Seis problemas que he encontrado después de elegir, cuando cambiar ya cuesta.
Confundir catálogos distintos con un aislamiento lógico comprobado
No considero suficiente mostrar catálogos distintos: compruebo que el aislamiento lógico cubra permisos, consultas, informes, extensiones y pruebas de acceso cruzado. Si el contrato exige aislamiento físico, separo además los recursos que especifica.
Permisos que cruzan la frontera entre organizaciones
El fallo de seguridad que más detecto en entornos compartidos nace de un rol asignado en un contexto superior para resolver algo puntual: puede hacer visible la información de una organización a otras.
Divergencia de versiones
Tras dos años con varias instalaciones, encuentro una versión y unas extensiones distintas en cada una. A partir de ahí, pruebo cualquier cambio común tantas veces como entornos haya.
Identidades duplicadas entre entornos
Una misma persona figura varias veces, con identificadores distintos. Necesito un identificador compartido o una regla fiable de correspondencia para consolidar sus registros entre entornos sin elevar el coste ni el riesgo de errores.
Personalización que rompe la separación entre organizaciones
Compruebo si una extensión respeta el modelo de organizaciones: si no lo tiene en cuenta, puede mostrar datos de una a otra. Reviso también desde ese ángulo cualquier desarrollo en este contexto.
El coste de operación suele quedar fuera del cálculo inicial
Cada entorno nuevo puede parecer barato si solo cuento la infraestructura. Incluyo en el cálculo las horas de actualización, vigilancia y soporte, porque pueden concentrar el coste real.
Qué cambia con la carga operativa y el número de organizaciones
El número de organizaciones me orienta, pero la heterogeneidad, el aislamiento y el coste medido de operar cada entorno pesan más en mi decisión.
- Pocas organizaciones y operación automatizada
Considero razonables las instalaciones separadas si automatizo las actualizaciones, la observación y el soporte, y mantengo el coste operativo dentro de la capacidad del equipo.
- Varias organizaciones que necesitan una visión de conjunto
Si aumentan la coordinación que exigen las actualizaciones y la demanda de informes agregados, reviso el modelo antes de añadir otro entorno por inercia.
- Cuando la operación supera la capacidad del equipo
El número por sí solo no decide. Mido el tiempo que exige aprovisionar, actualizar, observar y recuperar cada entorno. Si ese trabajo supera la capacidad disponible, elijo entre más automatización, otro modelo de aislamiento o más capacidad operativa.
- Con altas y bajas frecuentes
Con altas y bajas frecuentes comparo el tiempo y la fiabilidad del aprovisionamiento, la extracción y el borrado en cada arquitectura. La automatización de ese ciclo pesa más que el número de instalaciones por sí solo.
Qué exigir en un pliego con varias organizaciones
He visto este error más veces en pliegos con varias organizaciones que en ningún otro: quien decide cree que compra una cosa, pero compra otra.
| Requisito | Evidencia exigible | Criterio de aceptación |
|---|---|---|
| Nivel de aislamiento declarado | Documento que diga si la separación es lógica o física y qué comparten los entornos | Lo declarado coincide con lo que exige el contrato o la normativa |
| Administración delegada | Modelo de roles por organización que delimita cada rol | Un administrador de una organización no ve ni toca las demás |
| Política de actualizaciones | Calendario, ventana de actualización y procedimiento de prueba para cada organización | Ensayar la actualización sin afectar a una organización durante un periodo crítico |
| Informes agregados | Método para obtener datos del conjunto de organizaciones y de cada organización por separado | Generar un informe transversal en el plazo fijado |
| Salida de una organización | Procedimiento de extracción y borrado de sus datos | Comprobar que la extracción es completa y que el formato permite reutilizar los datos |
Diez comprobaciones antes de elegir
No considero madura una decisión si no puedo responder a las cuatro primeras.
- Sé si existe una exigencia contractual o legal de separar los datos.
- Sé si alguien pedirá informes del conjunto y con qué frecuencia.
- Sé qué contenido es común y quién es su propietario.
- Sé cuántas organizaciones habrá dentro de tres años.
- He sumado el coste de operar cada entorno, no solo el de alojarlo.
- Sé quién administra cada organización y hasta dónde llega.
- Los calendarios críticos de cada organización están sobre la mesa.
- Existe una forma de identificar a la misma persona en todos los entornos.
- Cualquier desarrollo se revisa también de acuerdo con el modelo de separación.
- Está escrito qué pasa cuando una organización se va.
Los atajos habituales
Tres decisiones que he visto tomar por la vía rápida y arrastrar sus consecuencias durante años.
Usar categorías de cursos como si fueran organizaciones
Con las categorías separo el catálogo, pero no a las personas: los usuarios siguen perteneciendo al mismo sitio, los informes globales lo mezclan todo y un permiso mal configurado cruza la frontera sin avisar.
Montar un campus nuevo cada vez que se incorpora una organización
Las primeras veces avanzo más rápido con un campus nuevo. Cuando acumulo varios campus, actualizar la versión se convierte en un proyecto largo si no mantengo un inventario de las extensiones de cada entorno.
Elegir por el precio de la licencia o del servidor
A medio plazo, doy a la operación tanto peso como a la infraestructura, o más: copias, vigilancia, actualizaciones y soporte por entorno. También incluyo en la comparación las licencias, la continuidad, los despliegues y la recuperación.
Referencias
Fuentes y límites
- Documentación oficialRoles y capacidades — documentación oficial de Moodle
Contextos, herencia de roles y alcance de los permisos, que es donde se decide la separación lógica. Consultado el 1 de agosto de 2026.
- Documentación oficialCohortes — documentación oficial de Moodle
Agrupación de personas en todo el sitio o dentro de una categoría, una de las piezas del modelo por organización. Consultado el 1 de agosto de 2026.
- Documentación oficialMulti-tenencia — documentación oficial de Moodle
Dice literalmente que la función pertenece a Moodle Workplace y que este se distribuye solo a través de socios y proveedores certificados. Consultado el 2 de agosto de 2026.
Los umbrales dependen del inventario, la automatización, el aislamiento exigido y la capacidad del equipo que opera; el número de entornos no basta para decidir. La comparación entre las tres arquitecturas está escrita desde la experiencia de operarlas, no desde una prueba comparativa publicada. Sobre las capacidades concretas de productos comerciales conviene contrastar con el fabricante, porque cambian entre versiones.
Blog
Casos, pruebas y fuentes.
En el blog desarrollo casos particulares, pruebas y fuentes que amplían esta página de referencia.
Ir a blog.albertolarah.comContacto
Una plataforma o varias: cómo lo decido
Cada vez he decidido con los mismos datos: cuántas organizaciones son, si alguna exige separar los datos, si alguien pedirá informes del conjunto, qué contenido comparten y cuánta gente gestionará la opción elegida.
hola@albertolarah.comLinkedIn ↗