Desafortunadamente, este término no tiene un buen análogo en ruso. Wikipedia da "inquilino múltiple, inquilino múltiple". A esto a veces se le llama "propiedad múltiple". Estos términos pueden resultar algo confusos, ya que el tema no está inherentemente asociado ni con el alquiler ni con la propiedad. Se trata de una cuestión de arquitectura del software y de organización de su funcionamiento. Y esto último no es menos importante.
Comenzamos a formular nuestra comprensión del multitenance al mismo tiempo que comenzamos a diseñar un enfoque para el modelo de trabajo en la nube (servicio) en 1C:Enterprise. Esto fue hace varios años. Y desde entonces nuestra comprensión se ha ampliado continuamente. Constantemente descubrimos más y más aspectos nuevos de este tema (pros, contras, dificultades, características, etc.).
A veces, los desarrolladores entienden el concepto de multitenencia como un tema muy simple: "para que los datos de varias organizaciones se almacenen en una base de datos, es necesario agregar una columna con el identificador de la organización a todas las tablas y establecer un filtro en ella". Por supuesto, a partir de este momento también comenzamos a estudiar la cuestión. Pero rápidamente se dieron cuenta de que se trataba sólo de un claro (tampoco, por cierto, fácil). En general, este es un "país entero".
La idea básica de multitenencia se puede describir así. Una aplicación típica es una cabaña diseñada para alojar a una familia, que utiliza su infraestructura (paredes, techo, suministro de agua, calefacción, etc.). Una aplicación multiinquilino es un edificio de apartamentos. En él cada familia utiliza la misma infraestructura, pero la infraestructura en sí se implementa para toda la casa.
¿El enfoque de multiinquilino es bueno o malo? Puedes encontrar opiniones muy diferentes al respecto. No parece haber ningún “bueno o malo” en absoluto. Es necesario comparar los pros y los contras en el contexto de las tareas específicas que se están resolviendo. Pero este es un tema aparte...
En su sentido más simple, el objetivo del multitenance es reducir el costo de mantener una aplicación “socializando” los costos de infraestructura. Este es el mismo movimiento que reducir el costo de una aplicación mediante el uso de una solución de producción (posiblemente con personalización y modificación), en lugar de escribirla "por encargo". Sólo en un caso se socializa el desarrollo y en el otro, la explotación.
Además, repetimos, no existe una relación directa con la forma de venta. La arquitectura multiusuario también se puede utilizar en una infraestructura de TI corporativa o departamental para automatizar una gran cantidad de sucursales y empresas holding similares.
Podemos decir que el multitenancy no es sólo una cuestión de organizar el almacenamiento de datos. Este es un modelo de cómo opera la aplicación en su conjunto (incluida una parte importante de su arquitectura, su modelo de implementación y su organización de mantenimiento).
Nos parece que lo más difícil e interesante del modelo multiusuario es que la esencia de la aplicación se “bifurca”. Parte de la funcionalidad trabaja con áreas de datos específicas (apartamentos) y “no le interesa” el hecho de que haya residentes en otros apartamentos. Y algunos perciben la casa como un todo y trabajan para todos los residentes a la vez. Al mismo tiempo, estos últimos no pueden ignorar el hecho de que, después de todo, se trata de apartamentos separados y es necesario garantizar el nivel necesario de granularidad y seguridad.
En 1C:Enterprise, el modelo multitenencia se implementa a nivel de varias tecnologías. Estos son los mecanismos de la plataforma 1C:Enterprise, los mecanismos de"Y"", mecanismos (bibliotecas de subsistemas estándar).
Cada uno de estos elementos contribuye a la construcción de la infraestructura general de un edificio de apartamentos. ¿Por qué esto se implementa en varias tecnologías y no en una, por ejemplo, en una plataforma? En primer lugar, porque algunos de los mecanismos, en nuestra opinión, es bastante apropiado modificarlos para una opción de implementación específica. Pero, en general, esta es una pregunta difícil y constantemente nos enfrentamos a una elección: a qué nivel es mejor implementar tal o cual aspecto del multitenance.
Obviamente, la parte básica de los mecanismos debía implementarse en la plataforma. Bueno, por ejemplo, la separación de datos real. Aquí es donde la gente suele empezar a hablar de multitenencia. Pero al final, el modelo multiusuario “viajó” a través de una parte importante de los mecanismos de la plataforma y requirió su perfeccionamiento y, en algunos casos, su replanteamiento.
A nivel de plataforma, implementamos exactamente los mecanismos básicos. Le permiten crear aplicaciones que se ejecutan en un modelo multiinquilino. Pero para que las aplicaciones "vivan y trabajen" en un modelo de este tipo, es necesario tener un sistema para gestionar sus "actividades de vida". Las tecnologías 1cFresh y una capa de lógica empresarial unificada a nivel BSP son responsables de esto. Así como en un edificio de apartamentos la infraestructura proporciona a los residentes todo lo que necesitan, las tecnologías 1cFresh proporcionan todo lo que necesitan para las aplicaciones que se ejecutan en un modelo multiinquilino. Y para que las aplicaciones puedan interactuar con esta infraestructura (sin modificaciones significativas), en ellas se colocan los correspondientes “conectores” en forma de subsistemas BSP.
Desde el punto de vista de los mecanismos de la plataforma, es fácil notar que a medida que ganamos experiencia y desarrollamos el caso de uso de la nube "1C:Enterprise", vamos ampliando la composición de los mecanismos que están involucrados en esta arquitectura. Pongamos un ejemplo. En el modelo multiusuario, los roles de los participantes del servicio de aplicaciones cambian significativamente. El rol (nivel de responsabilidad) de los responsables de operar las aplicaciones aumenta significativamente. Se hizo necesario que tuvieran herramientas de control de aplicaciones más potentes. Porque los usuarios de la aplicación (residentes) confían ante todo en el proveedor con el que trabajan. Para ello implementamos una nueva . Este mecanismo permite a los administradores de proveedores limitar la libertad de los desarrolladores de aplicaciones al nivel de seguridad requerido; en esencia, aislar el funcionamiento de la aplicación para cada inquilino dentro de un entorno de pruebas determinado.
No menos interesante es la arquitectura para administrar aplicaciones que operan en modo multiinquilino (que se implementa en las tecnologías 1cFresh y BSP). Aquí, en comparación con el modelo de implementación convencional, los requisitos para la automatización de los procesos de gestión aumentan significativamente. Hay docenas de procesos de este tipo: creación de nuevas áreas de datos ("apartamentos"), actualización de aplicaciones, actualización de información regulatoria, copias de seguridad, etc. Y, por supuesto, los requisitos en cuanto al nivel de confiabilidad y disponibilidad están aumentando. Por ejemplo, para garantizar una interacción confiable entre las aplicaciones y los componentes del sistema de control, implementamos tecnología de sistema de llamadas asíncronas con entrega garantizada.
Un punto muy sutil es la forma de socializar datos y procesos. Parece sencillo (si a alguien le parece) sólo a primera vista. El mayor desafío es el equilibrio entre la centralización de datos y procesos y la descentralización. Por un lado, la centralización permite reducir costes (espacio en disco, recursos del procesador, esfuerzos del administrador...). Por otro lado, limita la libertad de los “inquilinos”. Este es exactamente uno de los momentos de "bifurcación" de la aplicación, cuando el desarrollador necesita pensar simultáneamente en la aplicación en el sentido estricto (que sirve a un "apartamento") y en el sentido amplio (que sirve a todos los "inquilinos" a la vez). .
Como ejemplo de tal "dilema", se puede citar información regulatoria y de referencia. Por supuesto, existe una gran tentación de hacerlo común a todos los “inquilinos” de la casa. Esto le permite almacenarlo en una copia y actualizarlo para todos a la vez. Pero sucede que algunos vecinos necesitan cambios específicos. Por extraño que parezca, en la práctica esto ocurre incluso con la información especificada por los reguladores (organismos gubernamentales). Ésta resulta ser una pregunta difícil: ¿socializar o no socializar? Es tentador, por supuesto, hacer que la información sea general para todos y privada para quienes la deseen. Y esto ya lleva a una implementación muy difícil. Pero estamos trabajando en esto...
Otro ejemplo es el diseño de la implementación de procesos regulares (ejecutados según un cronograma, iniciados por el sistema de control, etc.). Por un lado, se pueden implementar para cada área de datos por separado. Es más fácil y conveniente. Pero, por otro lado, una granularidad tan fina crea una gran carga en el sistema. Para reducir la carga, es necesario implementar procesos socializados. Pero requieren un estudio más cuidadoso.
Por supuesto, esto plantea una pregunta muy importante. ¿Cómo pueden los desarrolladores de aplicaciones garantizar la tenencia múltiple? ¿Qué necesitan hacer para esto? Por supuesto, nos esforzamos por garantizar que la carga de los problemas tecnológicos y de infraestructura recaiga en la mayor medida posible sobre los hombros de la tecnología suministrada, y el desarrollador de aplicaciones piensa sólo en términos de tareas de lógica empresarial. Pero al igual que con otras cuestiones arquitectónicas importantes, los desarrolladores de aplicaciones deben tener cierta comprensión de cómo trabajar en el modelo multiusuario y se requerirá cierto esfuerzo al desarrollar aplicaciones. ¿Por qué? Porque hay puntos que la tecnología no puede proporcionar de forma automática sin tener en cuenta la semántica de los datos. Por ejemplo, la misma definición de los límites de la socialización de la información. Pero tratamos de que estas dificultades sean pequeñas. Ya existen ejemplos de implementación de este tipo de aplicaciones.
Un punto importante en el contexto de la implementación de multitenencia en 1C:Enterprise es que estamos creando un modelo híbrido en el que una aplicación puede funcionar tanto en modo multitenencia como en modo normal. Se trata de una tarea muy difícil y objeto de otro debate.
Fuente: habr.com