Modelos de arrendamiento para una aplicación multi-inquilino
Profundizando en la noción de "multi-arrendamiento" y compartiendo nuestras ideas sobre cómo lo percibimos.
Frecuentemente escuchamos sobre la importancia de crear una aplicación multi-inquilino, especialmente en el contexto de desarrollar una aplicación de Software como Servicio (SaaS).
Existe cierta confusión sobre el concepto de una “aplicación multi-inquilino” y los diversos modelos utilizados para desarrollarla. En este artículo, analizamos esos términos de una manera más práctica.
Comprender diferentes modelos de arrendamiento desde un punto de vista técnico
Arquitectura de un solo inquilino
La arquitectura de un solo inquilino es un modelo de software o informática en la nube donde cada cliente o inquilino tiene una instancia dedicada de una aplicación o servicio. Si observamos el origen del modelo de negocio B2B, comienza con cada instancia del software atendiendo a un solo cliente u organización.
Características
- Aislamiento: Cada cliente o inquilino opera en un entorno aislado con recursos, bases de datos y configuraciones dedicadas.
- Personalización: Las arquitecturas de un solo inquilino a menudo permiten una mayor personalización y flexibilidad para satisfacer necesidades específicas del cliente.
- Seguridad: Seguridad y privacidad de datos mejoradas, ya que los datos del cliente no se mezclan con los de otros inquilinos.
- Escalabilidad: Escalar recursos y capacidad puede ser más sencillo, ya que la instancia de cada inquilino puede ajustarse independientemente.
- Mantenimiento: Mantenimiento y actualizaciones independientes, ya que los cambios realizados en el entorno de un inquilino no afectan a otros.
- Costo: Por lo general, mayores costos de infraestructura y operativos debido a la necesidad de mantener instancias separadas para cada inquilino.
Ejemplos
- Alojamiento dedicado: Los proveedores tradicionales de alojamiento web ofrecen arquitecturas de un solo inquilino, donde cada cliente obtiene sus propios recursos, bases de datos o configuraciones.
- Software en las instalaciones: Algunas aplicaciones de software a nivel empresarial, como los sistemas de gestión de relaciones con los clientes (CRM) o los sistemas de gestión de recursos humanos (HRMS), ofrecen opciones de implementación de un solo inquilino para organizaciones con requisitos estrictos de seguridad de datos y personalización.
- SaaS con niveles premium: En algunas ofertas de Software como Servicio (SaaS), los niveles premium o empresariales proporcionan opciones de un solo inquilino para clientes que requieren mayor seguridad, cumplimiento o personalización.
La arquitectura de un solo inquilino se utiliza comúnmente en escenarios donde el cumplimiento es primordial o necesita requisitos de seguridad adaptados. Por ejemplo, industrias como la financiera, sanitaria y gubernamental, que tienen estrictos requisitos regulatorios, a menudo prefieren soluciones de un solo inquilino para garantizar el cumplimiento.
Sin embargo, es importante tener en cuenta que las arquitecturas de un solo inquilino pueden ser más intensivas en recursos y complejas de gestionar en comparación con las arquitecturas multi-inquilino, ya que la instancia de cada cliente requiere su propia infraestructura y mantenimiento. Como resultado, pueden ser más adecuadas para aplicaciones con menos pero más grandes clientes o donde la personalización y el aislamiento son críticos.
Arquitectura multi-inquilino
Multitenencia de software es una arquitectura de software en la que una sola instancia de software se ejecuta en un servidor y atiende a múltiples inquilinos. Los sistemas diseñados de esta manera son "compartidos" (en lugar de "dedicados" o "aislados"). Un inquilino es un grupo de usuarios que comparten acceso común con privilegios específicos a la instancia de software. Con una arquitectura multi-inquilino, una aplicación de software está diseñada para proporcionar a cada inquilino una porción dedicada de la instancia, incluidas sus datos, configuración, gestión de usuarios, funcionalidad individual del inquilino y propiedades no funcionales. -- Wikipedia
Características
- Recursos compartidos: Múltiples inquilinos comparten la misma infraestructura, incluidos servidores, bases de datos y recursos de red, para optimizar la utilización de recursos.
- Aislamiento: Los datos y configuraciones de los inquilinos están lógicamente segregados, asegurando privacidad y seguridad de datos.
- Economías de escala: La multitenencia puede ser rentable ya que la carga se distribuye entre múltiples usuarios, reduciendo los costos operativos e infraestructurales.
- Escalabilidad: La arquitectura puede escalar horizontal o verticalmente para acomodar un número creciente de inquilinos y usuarios.
- Mantenimiento: Las actualizaciones y el mantenimiento se agilizan, ya que los cambios se aplican uniformemente a todos los inquilinos, simplificando la gestión.
- Personalización: Aunque es posible cierta personalización, generalmente es más limitada en comparación con las arquitecturas de un solo inquilino para mantener la consistencia en todo el sistema.
Ejemplos
- SaaS basado en la nube: La mayoría de las aplicaciones de Software como Servicio (SaaS), como Google Workspace y Salesforce, emplean multitenencia para atender a múltiples organizaciones o usuarios en una plataforma compartida.
- Alojamiento compartido: En el alojamiento web, los servicios de alojamiento compartido alojan múltiples sitios web en el mismo servidor, cada uno perteneciente a un cliente u organización diferente.
- Servicios de nube pública: Los proveedores de nube pública, como AWS y Azure, utilizan multitenencia para atender a clientes diversos con recursos virtualizados aislados dentro de centros de datos compartidos.
- Soluciones infraestructurales a nivel empresarial: Como un clúster de Kubernetes compartido que es utilizado por múltiples unidades de negocio dentro de una organización.
Redefiniendo aplicaciones multi-inquilino en el mundo real
Proporcionamos definiciones desde una perspectiva arquitectónica, haciendo que sea sencillo distinguir entre diseños multi-inquilino y de un solo inquilino. Sin embargo, esto se inclina más hacia la definición técnica. Si usamos estas definiciones en nuestro entorno de desarrollo del mundo real al diseñar modelos de tenencia, esta forma de pensar supone que una aplicación multi-inquilino debe tener una infraestructura puramente compartida y multi-inquilino.
Sin embargo, los negocios y los productos varían mucho y tienen muchos requisitos caso por caso, por lo que no existe una solución única para todos.
Imagina un escenario donde un inquilino está utilizando recursos de una infraestructura compartida, pero debido a necesidades específicas del negocio, requiere que una o dos partes del sistema se dediquen exclusivamente a ellos. Estas partes dedicadas podrían ser la base de datos, las instancias, o una combinación de otros componentes, todo mientras se comparte la infraestructura general. Aquí es donde entra en juego la arquitectura de arrendamiento mixto.
En el desarrollo práctico de productos SaaS, es común encontrarse con un escenario donde un producto está diseñado principalmente con un modelo de multitenencia genérico. Sin embargo, ciertos aspectos de la arquitectura o recursos pueden estar orientados hacia un enfoque de "un solo inquilino".
AWS utilizó el siguiente caso como ejemplo para comunicar este concepto: la multitenencia es un concepto amplio, y es caso por caso combinar y elegir la estrategia correcta para definir lo que se quiere lograr con los recursos compartidos y el aislamiento de datos.
En otras palabras, a veces la gente todavía llama a este modelo “Multitenencia”, por lo que en la definición más amplia de multitenencia, no implica que cada componente en una solución sea compartido. Más bien, implica que al menos algunos componentes de una solución se reutilizan entre múltiples inquilinos.
Comprender este término de manera amplia puede ayudarte mejor a empatizar con las necesidades de tus clientes y de dónde provienen.
En lugar de fijarse en un único modelo arquitectónico, la multitenencia refleja la practicidad de la arquitectura de un producto SaaS en el mundo real. Cuando nos referimos a una aplicación multi-inquilino, no significa necesariamente que la aplicación se adhiera a un modelo arquitectónico; podría utilizar varias estrategias de arrendamiento, indicando que al menos algunos de sus componentes son compartidos.
Consideraciones clave para determinar tu estrategia de modelo de arrendamiento
Aquí viene la pregunta, ¿cómo propongo la estrategia de tenencia para mi producto? Aquí hay algunas preguntas importantes para pensar:
- ¿Cuáles son tus objetivos comerciales?
- ¿Puede una solución de un solo inquilino respaldar tus planes de crecimiento futuros?
- ¿Qué tan grande es tu equipo de operaciones y cuánta gestión de infraestructura puedes automatizar? ¿Te importa la agilidad y la eficiencia de costos?
- ¿Están tus clientes cómodos con varias opciones de multitenencia?
- ¿Cómo afecta cada opción al cumplimiento, tanto tuyo como de tus clientes?
- ¿Se espera que cumplas con acuerdos de nivel de servicio (SLAs) o apuntes a objetivos específicos de nivel de servicio (SLOs)?
- ¿Has considerado la seguridad, el costo, el rendimiento, la fiabilidad y la capacidad de respuesta a las necesidades individuales de los inquilinos como un todo?
Recuerda que no existe una división rígida en tu producto donde debas optar por un modelo puramente multi-inquilino o exclusivamente de un solo inquilino. Tu decisión debe basarse en cómo divides los componentes arquitectónicos de tu producto y los niveles de aislamiento específicos que necesitan tus clientes o tu negocio. Puedes luego aplicar diferentes enfoques en consecuencia.
Siguiente
Hablamos sobre la “nueva” definición de una aplicación multi-inquilino, sin embargo, ¿qué hay sobre el aislamiento de inquilinos, identidades y cómo determinar si tus identidades deben estar aisladas o no? ¿Qué significa que las identidades estén "aisladas"?
La confusión a menudo surge cuando se trata de situaciones donde un usuario del mundo real tiene dos identidades diferentes. ¿Es apropiado etiquetar esta situación como - “identidades aisladas”?
Abordaremos estas preguntas en nuestra próxima serie de artículos. ¡Mantente atento!