Lamentablemente, este término no tiene un buen equivalente en ruso. Wikipedia proporciona «multitenencia, alquiler múltiple». A veces se le llama «propiedad múltiple». Estos términos pueden ser algo confusos, ya que el tema no se relaciona esencialmente con el alquiler o la propiedad. Es realmente una cuestión de arquitectura de software y organización de su explotación. Y esta última no es menos importante.
Comenzamos a formar nuestra comprensión de multitenencia al mismo tiempo que comenzamos a diseñar el enfoque para el modelo de trabajo en la nube (servicio) de «1C:Enterprise». Esto fue hace varios años. Desde entonces, nuestra comprensión se ha ido ampliando constantemente. Descubrimos continuamente nuevos aspectos de este tema (ventajas, desventajas, dificultades, características, etc.).
A veces, los desarrolladores entienden por multitenencia un concepto bastante simple: «para que los datos de varias organizaciones se almacenen en una sola base, es necesario agregar una columna con el identificador de la organización en todas las tablas y establecer un filtro sobre ella». También, por supuesto, comenzamos nuestro estudio sobre este tema desde este punto. Pero rápidamente nos dimos cuenta de que esto es solo un área (que también, por cierto, no es sencilla). En general, es «todo un país».
La idea principal de la multitenencia se puede describir de esta manera. Una aplicación común es una cabaña, diseñada para el alojamiento de una sola familia, que utiliza su infraestructura (paredes, techo, suministro de agua, calefacción, etc.). Una aplicación de multitenencia es un edificio de apartamentos. En él, cada familia utiliza el mismo conjunto de infraestructura, pero la infraestructura está implementada para todo el edificio en su conjunto.
¿Es un enfoque de multitenencia bueno o malo? Se pueden encontrar opiniones muy diversas al respecto. Parece que no existe un «bueno o malo» en absoluto. Se deben comparar las ventajas y desventajas en el contexto de tareas específicas a resolver. Pero ese es un tema aparte...
En su comprensión más simple, el objetivo de la multitenencia es reducir los costos de mantenimiento de la aplicación mediante la «socialización» de los gastos de infraestructura. Es un movimiento similar a la reducción del costo de la aplicación a través de la implementación de una solución de volumen (posiblemente, con ajustes y modificaciones), en lugar de desarrollarla «a medida». Solo que en un caso se socializa el desarrollo, y en el otro, la explotación.
Cabe mencionar que no hay un vínculo directo con el método de venta. La arquitectura de multitenancy puede aplicarse perfectamente en la infraestructura IT de corporaciones o instituciones para automatizar un gran número de filiales homogéneas, empresas de un holding.
Se puede decir que el multitenancy no es solo una cuestión de organización del almacenamiento de datos. Es todo un modelo de funcionamiento de la aplicación (incluyendo una parte significativa de los aspectos de su arquitectura, el modelo de despliegue y la organización del mantenimiento).
Lo más complicado e interesante de la modelo de multitenancy, en nuestra opinión, es que la esencia de la aplicación se 'duplica'. Una parte de la funcionalidad trabaja con áreas de datos específicas (apartamentos) y 'no se interesa' por los inquilinos en otros apartamentos. Mientras que otra parte percibe el edificio en su totalidad y trabaja simultáneamente para todos los inquilinos. Sin embargo, esta última no puede abstraerse de que, en definitiva, se trata de apartamentos individuales, y es necesario asegurar un nivel requerido de granularidad y seguridad.
En '1C:Empresa', el modelo de multitenancy se implementa a través de varias tecnologías. Son los mecanismos de la plataforma '1C:Empresa', los mecanismos '» y «', los mecanismos (bibliotecas de subsistemas estándar).
Cada uno de estos elementos contribuye a construir la infraestructura general de un edificio de apartamentos. ¿Por qué se implementa en varias tecnologías y no en una sola, por ejemplo, en la plataforma? Principalmente porque parte de los mecanismos, en nuestra opinión, se puede modificar adecuadamente según la variante de despliegue. Pero en términos generales, esta es una cuestión compleja, y constantemente nos enfrentamos a la decisión de a qué nivel es mejor implementar cada aspecto del multitenancy.
Es evidente que la parte básica de los mecanismos debía implementarse en la plataforma. Por ejemplo, la propia separación de datos. Es de donde generalmente comienza la conversación sobre multitenancy. Pero al final, el modelo de multitenancy 'ha recorrido' una parte significativa de los mecanismos de la plataforma y ha requerido su mejora, y en algunos casos, una reconsideración.
A nivel de plataforma, hemos implementado los mecanismos básicos. Estos permiten crear aplicaciones que funcionan en un modelo de multitenencia. Sin embargo, para que las aplicaciones "vivan y funcionen" en este modelo, es necesario contar con un sistema que gestione su "vida útil". Esto es responsabilidad de las tecnologías 1cFresh y de la capa unificada de lógica de negocio a nivel de BSP. Al igual que en un edificio de apartamentos, donde la infraestructura proporciona a los residentes todo lo necesario, las tecnologías 1cFresh aseguran que las aplicaciones que operan en el modelo de multitenencia dispongan de lo que requieren. Y para que las aplicaciones puedan interactuar con esta infraestructura (sin modificaciones significativas), se integran "conectores" correspondientes en forma de subsistemas BSP.
Desde el punto de vista de los mecanismos de la plataforma, es fácil notar que, a medida que obtenemos experiencia y desarrollamos la variante en la nube de "1C:Enterprise", ampliamos el conjunto de mecanismos involucrados en esta arquitectura. Un ejemplo es que en el modelo de multitenencia, cambia drásticamente la distribución de roles de los participantes en el mantenimiento de aplicaciones. Aumenta considerablemente el papel (nivel de responsabilidad) de quienes son responsables de la explotación de las aplicaciones. Estos ahora necesitan contar con herramientas de control más potentes. Porque los usuarios de las aplicaciones (residentes) confían principalmente en el proveedor con el que trabajan. Para ello, hemos implementado en la versión 8.3 un nuevo . Este mecanismo permite a los administradores del proveedor limitar la libertad de los desarrolladores de aplicaciones al nivel de seguridad necesario, aislando en esencia el trabajo de la aplicación para cada residente dentro de ciertos marcos de una "sandbox".
La arquitectura para la gestión de aplicaciones que operan en modo multitenancy (como se implementa en las tecnologías 1cFresh y BSC) es de igual interés. En comparación con el modelo de implementación tradicional, las exigencias de automatización de los procesos de gestión aumentan significativamente. Existen decenas de estos procesos: la creación de nuevas áreas de datos (‘apartamentos’), la actualización de aplicaciones, la actualización de información normativa, copias de seguridad, etc. Y, por supuesto, aumentan las exigencias en cuanto a fiabilidad y disponibilidad. Por ejemplo, para asegurar la interacción fiable entre aplicaciones y componentes del sistema de gestión, hemos implementado la tecnología de sistema de llamadas asíncronas con entrega garantizada.
Un aspecto muy delicado es la forma de compartir datos y procesos. Esto puede parecer sencillo (si alguien lo percibe así) a primera vista. La mayor complejidad radica en encontrar un equilibrio entre la centralización de datos y procesos y la descentralización. Por un lado, la centralización permite reducir costos (espacio en disco, recursos del procesador, esfuerzos de los administradores, etc.). Por otro lado, limita la libertad de los ‘inquilinos’. Este es precisamente uno de los momentos de ‘división’ de la aplicación, donde el desarrollador debe pensar simultáneamente en la aplicación en un sentido estricto (que atiende a un solo ‘apartamento’) y en un sentido amplio (que atiende a todos los ‘inquilinos’).
Como ejemplo de tal ‘dilema’, podemos citar la información normativa y de referencia. Ciertamente, existe la seducción de hacerla común para todos los ‘inquilinos’ del edificio. Esto permite almacenarla en un solo ejemplar y actualizarla de inmediato para todos. Pero puede suceder que algún inquilino necesite cambios específicos. Curiosamente, esto ocurre en la práctica, incluso para la información que está especificada por los reguladores (organismos gubernamentales). Surge la pregunta complicada: ¿compartir o no compartir? Por supuesto, es tentador crear información general para todos y privada para quienes lo deseen. Pero eso lleva a una implementación bastante complicada. No obstante, estamos trabajando en ello…
Otro ejemplo es el diseño de la implementación de procesos regulares (realizados según un horario, iniciados por el sistema de gestión, etc.). Por un lado, se pueden implementar por separado para cada área de datos. Esto es más simple y conveniente. Pero, por otro lado, tal granularidad crea una gran carga en el sistema. Para reducir la carga, es necesario implementar procesos comunitarios. Pero requieren una elaboración más cuidadosa.
Por supuesto, surge una pregunta muy importante. ¿Cómo pueden los desarrolladores de aplicaciones garantizar el funcionamiento en modo multitenencia? ¿Qué deben hacer para lograrlo? Claro, buscamos que la carga de cuestiones tecnológicas e infraestructurales recaiga lo más posible sobre la tecnología proporcionada, y que el desarrollador de la aplicación solo se preocupe por la lógica del negocio. Pero al igual que con otras preguntas arquitectónicas clave, los desarrolladores de aplicaciones deben tener algún conocimiento sobre el funcionamiento en el modelo de multitenencia y se requerirán ciertos esfuerzos al desarrollar aplicaciones. ¿Por qué? Porque hay aspectos que la tecnología no puede gestionar automáticamente sin tener en cuenta la semántica de los datos. Por ejemplo, la definición de los límites de la compartición de información. Pero nos esforzamos por mantener estas complejidades al mínimo. Ya existen ejemplos de la implementación de tales aplicaciones.
Un aspecto importante en el contexto de la implementación de multitenencia en "1C:Enterprise" es que creamos un modelo híbrido en el que una aplicación puede funcionar tanto en modo multitenencia como en modo normal. Esta es una tarea bastante complicada y es un tema de discusión aparte.
Fuente: habr.com
