¿Multi inquilino o multi instancia?

Estoy tratando de construir una solución SaaS basada en la web, y llegué a un camino en el que no estoy seguro de usar múltiples inquilinos o múltiples instancias. Trataré de describir lo que estoy tratando de lograr, y cada enfoque tiene ventajas y desventajas (mi opinión, de acuerdo con lo que leí). Incluya sus sugerencias en caso de que me haya perdido algo en un enfoque sobre el otro.

La aplicación que estoy tratando de construir es, como mencioné, una solución SaaS donde las compañías pueden crear sus cuentas, y cada cuenta / compañía tiene sus propios usuarios, clientes, productos, servicios ... etc. Cada usuario; quien es un empleado de la compañía; relacionado con una cuenta / empresa tendrá acceso solo a los clientes, productos y servicios de su empresa. Las empresas pueden tener un número ilimitado de clientes, productos y servicios, por lo que cada empresa debe tener su propio centro de datos.

Para eso, decidí crear una base de datos compartida (guardar todas las credenciales de los usuarios para fines de inicio de sesión) y un esquema compartido de varias bases de datos (base de datos por cuenta / empresa). Básicamente, Multi Tenancy .

Luego, alguien sugirió usar Multi Instance , donde cada compañía tendrá su propia instancia de la aplicación (es decir, código, bibliotecas, bases de datos, marcos ... etc.) totalmente separada de las otras compañías. Esto suena mejor ya que no tengo que ocuparme de una capa adicional donde necesito asegurarme de que los usuarios de cada inquilino tengan acceso solo a los datos de su empresa. Creo que es bueno mencionar que estoy dependiendo de Docker para lograr este enfoque (nunca lo he usado antes), pero creo que carece de características (más sobre eso más adelante) que necesitaré en el futuro (al menos no No los encuentre con un poco de búsqueda).

Sin embargo, cada enfoque tiene ventajas y desventajas, por lo que no pude tomar una decisión con respecto a qué enfoque seguir. Aquí hay una lista, pero desnuda conmigo, ya que me falta el conocimiento en ambos, por lo que podría haber algo de lo que no estoy al tanto, o una solución para un problema que no encontré en la web: [Cada enfoque tiene una lista ordenada de la cual seguí una comparación uno por uno]

Tenencia múltiple :

1. Host / hardware compartido, código compartido y base de datos múltiple.
2. Es más fácil ampliar la funcionalidad del código y corregir errores (código compartido).
3. Es más difícil extender el hardware (podría usar un servicio en la nube) o mover la base de datos del inquilino individual a otro sistema sin realizar cambios en el código.
4. Lo más importante, como mencioné antes, necesito agregar una capa adicional al sistema para asegurarme de que el usuario realmente pertenezca a su compañía y no acceda a la información de otra compañía.

Instancia múltiple :

1. Host / hardware compartido o no compartido, código por instancia y base de datos por instancia.
2. Es más difícil extender la funcionalidad o corregir errores (no estoy seguro de si hay una manera de hacerlo en Docker donde pueda agregar funcionalidad / característica a una instancia o contenedor de Docker e implementarla en las demás).
3. Es más fácil mover toda la instancia a un host / hardware diferente.
4. Como instancia, no necesito cuidar esa capa ya que cada instancia tendrá su propia base de datos.

Todas las ventajas y desventajas son redundantes en caso de que quiera hacer algo manualmente (como crear una instancia para cada inquilino manualmente), y es por eso que dudo de la solución Docker, a menos que haya una forma de resolver eso, que tal vez sea la principal. razón de la pregunta. Le agradecería que respondiera a la pregunta con referencias a las soluciones, y por qué cree que este enfoque es mejor que el otro.

En caso de que eso ayude (¿tal vez?), Estamos usando Laravel como el marco principal para el back-end (todo RESTfully).

Me estoy haciendo exactamente la misma pregunta en este momento.

Me estoy inclinando hacia la solución de arrendamiento único de varias instancias, pero aún no he tomado una decisión definitiva. Permítanme compartir algunos de mis pensamientos:

La principal ventaja histórica de la arquitectura multiinquilino es un mejor uso de los recursos de infraestructura , mediante la mutualización (sistema operativo único, base de datos única, capa de aplicación única) y una mejor ocupación de dichos recursos (cuando un usuario está fuera, otro puede usar el mismo recurso) .

También simplifica enormemente el ciclo de vida del software : implementa nuevas versiones en una instancia, todos los clientes se actualizan al mismo tiempo.

Sin embargo, parece que los avances recientes en la tecnología de la nube hacen que la primera clase de ventajas esté ampliamente disponible en una arquitectura de varias instancias (instancia por cliente) (estoy pensando específicamente en una plataforma como Jelastic aquí, pero estoy seguro de que hay otras que proporcionar las mismas características):

• PaaS basado en contenedores
• Aprovisionamiento y autoescalado de contenedores (contenedores elásticos)

Por lo tanto, la gestión de hardware y plataforma ya no es asunto del proveedor de software. Los recursos se mutualizan de manera mucho más eficiente que antes en los niveles de infraestructura y plataforma .

Todavía habrá una sobrecarga para múltiples instancias (algunas aplicaciones y middleware se ejecutarán N veces en lugar de solo una), pero mucho más bajas que cuando se usa una máquina separada (virtual) por instancia. La base de datos se podría compartir de todos modos (un esquema por instancia, varios esquemas por servidor de base de datos)

También :

• La automatización de la creación de nuevas instancias es posible a través de la API de PaaS
• La automatización de la implementación de nuevas versiones es posible a través de la API de PaaS, con cero tiempo de inactividad (requiere un poco de trabajo para su implementación)
• La escala siempre está fuera, nunca hacia arriba. No tenemos que preocuparnos por grandes conjuntos de datos a nivel de instancia.

Por supuesto, necesitaríamos algún tipo de servicio central que gestione todo esto automáticamente (por ejemplo, creación de instancia cuando un nuevo usuario crea una cuenta). Esto también manejaría problemas de pago y licencia, interacción entre instancias, etc. Este servicio central puede ser bastante complejo y difícil de desarrollar, pero lo bueno es que no tenemos que implementarlo por adelantado (ahora que no tenemos mucho recurso), mientras que los inquilinos múltiples tendrían que integrarse en la aplicación desde el principio.

Lo que me lleva a las ventajas finales de desarrollar un inquilino único para un proyecto de inicio en una etapa muy temprana (previa a la inversión):

• La misma versión (o casi la misma) de la aplicación se puede implementar en las instalaciones como un dispositivo virtual o un contenedor acoplable o incluso en una máquina administrada por el cliente (algunas empresas aún son reacias a la nube y puede ayudar a un inicio de etapa temprana a no expulsar a los primeros adoptantes importantes)
• Más rápido para obtener un producto con recursos limitados (la capa de aplicación y el esquema de la base de datos es bastante menos complejo), puede obtener primero un producto de inquilino único de una sola instancia "tonto" para los primeros usuarios y mostrar el valor comercial de la aplicación a inversores potenciales y agregue toda la automatización de la nube más adelante
• Puede verse como un argumento de venta para clientes preocupados por la seguridad de los datos : los datos están mejor encapsulados ya que cada cliente tiene su propio esquema o incluso una base de datos. Mucho menos riesgo de "derrame"

NB: obviamente estoy pensando aquí en una aplicación de negocios donde los clientes serían negocios (cada uno con múltiples usuarios individuales) y no individuos. No tendría ningún sentido ejecutar una instancia separada de una aplicación para cada usuario individual (¿o no?)

También es posible admitir ambas opciones (un grupo de inquilinos en varias instancias).

Estoy a favor de la causa de múltiples instancias del aislamiento natural. La instancia de cada cliente se ejecuta en sus propios procesos y sus datos están aislados en su propia base de datos. Puede actualizar instancias a nuevas versiones según el cliente / instancia cuando lo desee.

Los sistemas basados ​​en inquilinos conllevan un riesgo de seguridad de la información. Solo considere lo fácil que es olvidar una cláusula "WHERE tenantId = x". La razón principal para usar un sistema con capacidad para inquilinos sería el rendimiento, los procesos son pesados, al compartir un proceso, puede obtener más de una máquina. Creo que esto era más cierto en un mundo de 32 bits que en las máquinas de 64 bits que tienen mucha más RAM.

Un sistema de instancias múltiples tal vez necesite un poco más de herramientas para crear y configurar el entorno, como bases de datos e instancias de aplicaciones web. Se puede argumentar que de todos modos también debe tener esta secuencia de comandos para sus implementaciones de instancia única. Hacer esto tiene otras ventajas también como la capacidad de configurar entornos de desarrollo y prueba

Dejaría a un lado las capacidades del inquilino hasta que pueda defenderlo (costo de ingeniería versus dinero ahorrado en infraestructura (hardware) a través del intercambio de procesos).