Apoyando multitenancy

¿Cuáles son los desafíos típicos que surgen al convertir una aplicación de un solo inquilino en una aplicación de múltiples inquilinos? La seguridad y el aislamiento de datos me parecen los más importantes. ¿Cuáles son algunos otros?

Soy uno de los arquitectos de un esfuerzo de automatización bastante significativo, e históricamente solo ha sido nuestra compañía usándolo. Queremos hacer posible que otros también lo usen. Cada vez que hablamos de "hacerla multiempresa", la conversación gira en torno a mantener a los usuarios con un inquilino alejado de los datos que posee otro inquilino, y asegurarse de que los usuarios con un inquilino no puedan (ya sea intencionalmente o sin darse cuenta) crear impactos en otro Ambientes del inquilino. Lo que me pregunto es si la seguridad / aislamiento de datos son realmente las únicas preocupaciones importantes aquí, o si hay otras preocupaciones importantes en las que simplemente no estamos pensando.

architecture multitenancy

— Grant Palin
fuente

¿La solución más fácil? Una nueva instancia de todo el sistema, incluido el hardware, vacío, desde cero, un nuevo sistema por inquilino. Si el sistema y los datos son bastante valiosos, esta puede ser una muy buena opción. Si no le gusta el nuevo hardware para cada instancia, use la virtualización. Puede que no sea más eficiente, pero ciertamente ahorrará un montón de dolores de cabeza.

— SF.

Probablemente desde una perspectiva de diseño, esto es lo más fácil, pero desde una perspectiva administrativa no parece ser. Al menos nuestros administradores de sistemas no están muy entusiasmados con esta propuesta. (Y sí, estamos usando máquinas virtuales). Maneras de más instancias para administrar (monitoreo, implementación, etc.) De hecho, estamos buscando formas de hacer que esto sea más manejable para obtener un poco de aislamiento físico aquí, pero a primera vista, esto el enfoque parece cambiar la simplicidad del desarrollador por la simplicidad del administrador ...?

Respuestas:

Además de la recopilación de datos, puede tener problemas con

Disponibilidad: con un solo inquilino, solo pueden hacer DoS por sí mismos, pero incluso cuando los datos están correctamente distribuidos, un inquilino aún puede agotar los recursos.
Registro: todos los mensajes de registro suponen un único inquilino. A menos que silo registre por inquilino, sus mensajes de registro pueden volverse menos útiles.
Concurrencia: las aplicaciones de un solo inquilino pueden ejecutarse con una carga moderada, o una alta contención por algunos bloqueos puede serializar efectivamente ciertas operaciones. Si las cerraduras se multiplican por inquilino, puede comenzar a ver la intercalación de operaciones que no ocurrieron antes. Las condiciones raciales que era muy poco probable que alguna vez se manifestaran, ahora es probable que se manifiesten.
Nuevas fuentes de contención de recursos: donde antes podía tener n sockets y m manejadores de archivos, ahora multiplique ese por inquilino.
Configuraciones / compensaciones de compatibilidad con versiones anteriores: antes de que pueda obsoleto un componente a medida que implementa un reemplazo, ahora puede tener un inquilino que exige un componente y un inquilino que exige que el componente antiguo que reemplaza permanezca indefinidamente.
Objetivo de citación: actualmente es un objetivo de citación para problemas relacionados con su empresa. Con los inquilinos múltiples, es posible que deba responder a las solicitudes de citación incluso cuando no sea parte en la acción legal.

Algunos de estos suponen que está ejecutando todos los inquilinos en el mismo espacio de direcciones (máquina o clúster). Si cada inquilino ejecuta su software en su hardware, puede discutir algunos de los anteriores y agregar:

Dificultades para acceder a máquinas para depurar.
Solicitudes de soporte para versiones anteriores.
Solicitudes para permitir la configuración de contratistas externos.
Menos control sobre el hardware en el que se ejecuta.
Menos control sobre el ciclo de parche / actualización del sistema operativo en el que se ejecuta.

— Mike Samuel
fuente

El mayor problema en multicliente en mi opinión es la personalización. Esto sucede de manera rutinaria si vende una aplicación comercial a empresas. Puede variar desde algo tan simple como que cada cliente desee sus propios skins hasta la capacidad de configurar campos, reglas, formularios e informes adicionales. El nivel de personalización que necesita admitir juega un papel fundamental en la arquitectura.

— Sriram
fuente

La respuesta de Mike es muy buena, y muchos de los puntos casi minimizan su complejidad debido a lo cortos que son, así que tómalos en serio.

Un punto que agregaría es que debe tener buenas herramientas de administración para crear (y más adelante, administrar) nuevos inquilinos. Dependiendo de la arquitectura física con la que vaya, esto puede estar lejos de ser trivial, y es algo que a menudo se pasa por alto. Los beneficios de un producto de software como servicio realmente solo entran en juego cuando hay una gran cantidad de inquilinos, por lo que se debe realizar un esfuerzo considerable para satisfacer esto.

Extender la respuesta de Sriram; per-inquilino personalización es más o menos prohibido, todo lo que un inquilino que desee cambiar debe ser configurable . Por ejemplo, si su solución no satisface la adición dinámica de campos de datos en al menos algunas áreas clave, es probable que se vea inundado de solicitudes de personalización. Es uno de los pocos casos en los que un poco de complejidad adicional por adelantado realmente vale la pena (digamos que va en contra de YAGNI, o al menos, este nivel de configuración es casi un requisito clave, por lo que lo necesitará).

— Daniel B
fuente

¿Por qué está "prohibida" la personalización? Ciertamente es técnicamente alcanzable. Hay muchos patrones diferentes que permitirían la reutilización del sistema central para múltiples inquilinos y al mismo tiempo proporcionarían piezas personalizadas para inquilinos individuales. Si un cliente está dispuesto a pagarle por la personalización, parecería razonable considerarlo. Hay muchos productos multiinquilino que tienen personalizaciones por cliente por este motivo. Es más en el espíritu de YAGNI IMO permitir la extensibilidad y no por defecto hacer que todo sea configurable.

— RationalGeek

Bueno, me refiero a las implementaciones de software como servicio, en general (de "multicliente"). Claro, es técnicamente posible, pero va en contra de los fundamentos de SaaS. En un sentido financiero, está logrando costos más bajos al compartir la implementación y probablemente la infraestructura para muchos inquilinos. Esto le permite ofrecer su producto a un precio más bajo, atrayendo así la "cola larga" del mercado (un gran número de personas que solo están dispuestas a pagar una pequeña cantidad). Puede mantener quizás 5 ramas de un sistema, pero no 15000, y eso es a lo que apunta SaaS.

— Daniel B

A nivel empresarial, veo con frecuencia proveedores de SaaS que están dispuestos a realizar personalizaciones significativas en su código para atraer a un cliente. Cuando un cliente paga 6 o 7 cifras por el servicio, este es probablemente un modelo comercial razonable.

— RationalGeek

Sí, en esos casos, supongo que sí. La mayoría de los cambios que he visto se implementaron como nuevas funciones configurables que, de forma predeterminada, estaban desactivadas para los clientes existentes. El problema, creo, es cuando cada uno de los primeros 3 o 4 clientes recibe un tratamiento especial porque la solución aún está por despegar. La solución termina siendo demasiado específica y crea una cultura de "OK, la hackearemos". Pero sí, estoy de acuerdo con tu comentario sobre los grandes clientes.

— Daniel B

Esta es una distinción útil que ustedes hacen sobre la personalización. Creo que el mismo concepto podría aplicarse también a la capacidad de administración. Nuestra multipropiedad probablemente apunta a relativamente menos clientes más grandes en lugar de clientes de cola larga. Si el objetivo principal de la multitenencia es capturar la cola larga, entonces puede que ni siquiera sea el enfoque correcto para nosotros. Gracias por estas reflexiones.