Comenzamos a trabajar en nuestra filosofía de multitenencia en las primeras etapas del diseño del soporte de servicios en la nube en 1C:Enterprise. Esto fue hace varios años y desde entonces nuestro concepto de multitenencia sigue expandiéndose constantemente. Constantemente descubrimos nuevos aspectos: ventajas y desventajas, complejidades y peculiaridades.
Algunos desarrolladores tienen una comprensión muy básica de la multitenencia: “Para almacenar los datos de múltiples empresas en una sola base de datos, simplemente agregaremos la columna ID de la empresa a todas las tablas y luego las filtraremos por esta columna”. Eso es por donde empezamos también. Sin embargo, rápidamente nos dimos cuenta de que es solo una isla (con muchos misterios propios) en todo un archipiélago.
Describiremos la idea básica de la multitenencia utilizando un ejemplo visual. Una aplicación simple es una casa construida para una sola familia, que utiliza la infraestructura de la casa: paredes, techo, agua, energía, y así sucesivamente. Una aplicación multitenant es un bloque de apartamentos donde todas las familias comparten la infraestructura de la casa, que se implementa a nivel de la casa.
¿Es buena la multitenencia? Las opiniones varían. No existe algo como el bien o el mal definitivo, siempre tienes que sopesar las ventajas y desventajas para tus tareas específicas. Sin embargo, esto está fuera del alcance de este artículo.
En términos simples, el objetivo de la multitenencia es reducir los costos distribuyendo los costos de infraestructura entre los inquilinos. Es similar a reducir los costos mediante la venta de soluciones listas para usar (que, por supuesto, pueden necesitar alguna personalización) en lugar de escribir una solución personalizada para cada cliente. La multitenencia tiene como objetivo compartir los costos de mantenimiento, mientras que las soluciones listas para usar tienen como objetivo reducir los costos de desarrollo.
Tenga en cuenta que la multitenencia no implica necesariamente vender un producto a varias empresas. Las corporaciones e instituciones públicas pueden utilizar la arquitectura multitenant para automatizar sus sucursales y subsidiarias.
La multitenencia es más que un conjunto de reglas de almacenamiento de datos. Es un modelo de aplicación completo que afecta muchos aspectos arquitectónicos, de implementación y de mantenimiento.
El aspecto más complejo e interesante de la multitenencia es su naturaleza dual. Una parte de la funcionalidad de la aplicación afecta áreas de datos individuales (apartamentos), tratando cada área como si fuera la única disponible. La otra parte se aplica a toda la casa, afectando a todos los inquilinos. Sin embargo, esta parte debe ser consciente de los apartamentos individuales para admitir la granularidad de acceso y la seguridad.
1C:Enterprise implementa el modelo de multitenencia en varios niveles, que incluyen la plataforma en sí, las tecnologías de desarrollo y publicación de la aplicación 1cFresh y la Biblioteca de Subsistemas 1C.
Cada uno de estos niveles es importante y necesario para construir un bloque de apartamentos. ¿Por qué varios niveles y no solo la plataforma? Porque algunos de los algoritmos pueden requerir modificaciones en la etapa de implementación. Elegir un nivel para implementar otro aspecto de la multitenencia siempre es una tarea compleja.
Claramente, los fundamentos del soporte de multitenencia (por ejemplo, la separación de datos) deben implementarse en la plataforma. Sin embargo, hay mucho más que eso. El modelo de multitenencia afecta a una parte significativa de los mecanismos de la plataforma, lo que provoca su refactorización o incluso rediseño.
Los mecanismos implementados a nivel de plataforma proporcionan una base para el desarrollo de aplicaciones multitenant. Sin embargo, para ejecutar y mantener las aplicaciones, se necesitan herramientas de gestión adecuadas. Estas se implementan en 1cFresh y en la capa unificada de lógica empresarial de la Biblioteca de Subsistemas 1C. Al igual que la infraestructura de un bloque de apartamentos proporciona a sus inquilinos todo lo que necesitan, las tecnologías de 1cFresh proporcionan a las aplicaciones multitenant todo lo que necesitan. Para proporcionar a las aplicaciones la capacidad de interactuar con la infraestructura (sin grandes personalizaciones), la Biblioteca de Subsistemas 1C proporciona “sockets” que se pueden integrar fácilmente en las aplicaciones.
Con el desarrollo de la multitenencia y el soporte de tecnología en la nube, ampliamos la lista de mecanismos involucrados en esta arquitectura. Por ejemplo, los roles de los encargados del mantenimiento de la aplicación cambian con el tiempo. A medida que aumenta el nivel de responsabilidad del personal de mantenimiento de la aplicación, requieren herramientas de gestión más poderosas. Esto se debe a que los usuarios de la aplicación (los residentes de los apartamentos) confían en su proveedor de servicios, y esta es la razón detrás de la implementación de perfiles de seguridad en 1C:Enterprise 8.3. Los administradores del proveedor de servicios pueden utilizar perfiles de seguridad para aplicar restricciones de seguridad (aislando efectivamente a cada inquilino en su propio “sandbox”).
La arquitectura de gestión de la aplicación (la funcionalidad implementada en las tecnologías de 1cFresh y en la Biblioteca de Subsistemas 1C) también es interesante. En comparación con el modelo de implementación regular, esta arquitectura implica requisitos más estrictos para los procesos de automatización de implementación. Hay docenas de tales procesos: creación de áreas de datos (“apartamentos”), actualizaciones de la aplicación, actualizaciones de datos regulatorios, creación de copias de seguridad y más. Por supuesto, esto también aumenta los requisitos de disponibilidad y confiabilidad del servicio. Por ejemplo, implementamos la tecnología de llamadas asíncronas con entrega garantizada para garantizar una interacción confiable entre las aplicaciones y los componentes del sistema de gestión.
Compartir datos y procesos también es complicado, aunque pueda parecer fácil a primera vista. La parte más difícil es mantener el equilibrio entre la centralización y la descentralización de los datos y los procesos. Por un lado, la centralización reduce los costos (en términos de espacio en disco, recursos de CPU y esfuerzos del administrador). Por otro lado, restringe la libertad del inquilino. Este es uno de los aspectos de la “naturaleza dual” que mencionamos antes: un desarrollador debe pensar en la aplicación tanto en un sentido estrecho (un servicio para un solo “apartamento”) como en un sentido amplio (un servicio para todos los inquilinos).
Por ejemplo, los desarrolladores pueden querer compartir una sola instancia de datos regulatorios entre todos los inquilinos. Esto simplifica el almacenamiento y la actualización de estos datos. Sin embargo, un inquilino puede querer introducir algunos cambios en estos datos. Curiosamente, a menudo quieren alterar incluso los datos regulatorios y legislativos proporcionados por los organismos gubernamentales. Entonces, ¿compartir o no compartir? Compartir los datos y tener la opción de sustituir datos personalizados para usuarios específicos es tentador, sin embargo, esto agrega complejidad a la implementación. Aún así, estamos investigando esto.
Otro ejemplo presenta el diseño de procesos programados. Se pueden hacer específicos del área de datos; sin embargo, esa granularidad aumenta la carga general del sistema. Para reducir la carga, es necesario implementar procesos compartidos, que requieren mucha más atención.
Y por supuesto, la pregunta se plantea: ¿cómo pueden los desarrolladores de aplicaciones agregar multitenencia a sus aplicaciones? Estamos haciendo todo lo posible para resolver problemas tecnológicos e infraestructurales a nivel tecnológico, dejando solo tareas relacionadas con la lógica empresarial a los desarrolladores de aplicaciones. Sin embargo, los desarrolladores deben comprender el modelo de multitenencia y aún deben invertir cierto esfuerzo en el soporte de multitenencia. Esto se debe a que ninguna tecnología puede proporcionar una solución universal e independiente de la semántica. Por ejemplo, no existe un algoritmo universal para decidir qué datos se deben compartir. Aún así, hacemos todo lo posible para simplificar el desarrollo de aplicaciones multitenant y algunas de ellas ya han llegado al mercado.
Es importante tener en cuenta que proporcionamos un modelo de multitenencia híbrido donde una sola aplicación puede ejecutarse tanto en modos regulares como multitenant. Esta es una tarea compleja que vale la pena un artículo separado.
