La segunda Feature Talk, donde hablamos sobre el concepto de Multitenancy acompañado de Feature Flags, ¡fue todo un éxito!
Los participantes han trabajado, y están desarrollando, productos de software utilizando la arquitectura multitenant.
Discutimos y pusimos en común qué cosas hay que tener en cuenta y a qué compromisos hay que llegar para diseñar e implementar una estrategia multitenant ganadora.
Tuvimos la oportunidad de introducir cómo estamos ayudando a implementar un sistema multitenant a partir del modelo de segmentación de FeaturIT.
Productos de software multitenant
En la sesión nos alineamos en qué significa que un producto de software sea multitenant.
A continuación, identificamos los conceptos a tener en cuenta cuando se desarrolla una aplicación multitenant.
Finalmente, nos centramos en definir los pros y contras para cada una de las decisiones.
Como de costumbre, no hay una solución ideal que se pueda aplicar a todos los casos. Por lo que hay que hacer varias sesiones para ir encontrando el modelo que mejor se ajusta según el caso de negocio entre otros requerimientos.
¿Qué significa que un producto de software sea multitenant?
En esta parte del brainstorming salieron varias ideas:
En definitiva, resaltamos los dos conceptos principales para determinar que una aplicación sea multitenant:
¿Qué hay que tener en cuenta cuando se diseña y desarrolla un producto de software sea multitenant?
Durante la sesión se identificaron cuatro conceptos principales a tener en cuenta, que a su vez desgranamos para tener una mejor definición.
Acceso a los datos, capa de seguridad, lógica de negocio y registro de los DNS.
¿Qué decisiones hay que tomar en un producto de software Multitenant? Pros y Contras
| Pros | Contras | |
| Seguridad con Auth0 | Provee el multitenancy de forma independiente | Si un tenant me pide localidad de los datos tengo que duplicar la infraestructura |
| Una sola BD con MongoDB | La separación lógica ha sido abstraída Simple de crear un nuevo tenant | No se pueden encriptar los datos por tenant Los logs están juntos (aunque se podrían separar) |
| Base de datos compartida | Coste bajo Permite encriptación a nivel lógico (delicado) Ágil | No se pueden encriptar los datos por tenant a nivel físico No se pueden guardar los datos en distintos países No se pueden encriptar los datos por tenant No escala independientemente por cada tenant |
| Base de datos independientes | Backups por tentant | Gestión independiente de la infraestructura |
| Customización del código – Código distinto por tenant con librerías base | Mucha flexibilidad Control de riesgos (bugs por tenant) | Complejo de reusar código Acabas con un equipo por tenant |
| Customización del código – Plugins/Factory | Lógicas que siguen con la misma interfaz pero con distintas implantaciones Permite habilitar y deshabilitar funcionalidades por tenant | Se tiene que mantener cada uno de los plugins de forma independiente (pero no hay más remedio) |
| Un dominio para todos los tenants | Menor mantenimiento a nivel DNS, etc | Varnish (cache a nivel de request) difícil de separar por tenant |
| Customización del código – Feature Flags | Mismo código activo o inactivo por lógica Centralizas la lógica de segmentación en un solo sistema | O se implantan de forma limpia o ensucian el código |
| Servidor de la aplicación – Independiente | Todo separado permite dar la máxima seguridad por tenant (aislado, encriptado, cerca de su oficina, etc) | Más caro a nivel de infraestructura Más caro de mantener |
Durante la conversación acerca de la customización de código hablamos acerca de la tecnología de Feature Flags.
Además compartimos algunas ideas sobre si es mejor crearse una solución de Feature Flags rudimentaria o utilizar una herramienta de mercado.
¿Qué aporta un software de Feature Flags para la customización?
Hablamos sobre cómo el software de mercado de Feature Flags aporta muchos más casos de uso que el de customizar el producto de software por tenant, ya que a abre muchas otras oportunidades como la Segmentación, los Experimentos A/B, tener Analíticas por funcionalidad, el Release Management, etc.
