El documento describe los conceptos de aplicaciones multi-tenant y cómo crear una aplicación que pueda ser utilizada por múltiples organizaciones (tenants) de forma aislada. Explica las diferencias entre aplicaciones single-tenant y multi-tenant, y diferentes modelos para almacenar datos de tenants de forma lógica o físicamente separada. Finalmente, detalla la arquitectura propuesta para una aplicación multi-tenant, incluyendo la separación de datos de cada tenant en su propia base de datos.

1. Creando aplicaciones multi-tenant

2. ¿Quién soy?
Nacho Fanjul
Software Developer
@ nfanjul@plainconcepts.com
@nfanjul
https://github.com/nfanjul

3. Agenda

4. Tenant, tenant, tenant…

5. ¿Qué es una aplicación multi-tenant?
“Multi-tenant se refiere a la capacidad del
software de ser utilizado por múltiples entidades
usuario (tenants) de forma que cada tenant opera
de forma aislada, mientras que en realidad, está
usando recursos físicos compartidos. Un tenant
puede ser una organización que utiliza una
aplicación simultáneamente con otros tenants.
También puede ser una aplicación compartiendo
recursos con otras aplicaciones.”
by Yefim V. Natis
VP Distinguished Analyst

6. Single-tenant vs multi-tenant

7. Single-tenant
•Configurable
•Seguridad
•Confiable
•Fácil restauración
•Entorno controlado

8. Single-tenant
•1 subdominio por tenant
•URL’s personalizadas con CNAME*
www.sporting.tenant1.net
www.sporting.tenant2.net
sportingtenant1.azurewebsites.net
sportingtenant2.azurewebsites.net

9. Multi-tenant
•Coste
•Mantenimiento
•Escalado
•Despliegue*

10. Multi-tenant
•1 subdominio compartido por los tenants
•Misma URL. A través del usuario*
sporting.azurewebsites.net/tenant1
sporting.azurewebsites.net/tenant2
sporting.azurewebsites.net/

11. Modelos de tenant – A nivel de datos
•Separación Lógica
•Separación Física

12. Posibles soluciones

13. Aplicación y BD independiente por tenant
• “n” instalaciones
• BD completa para cada tenant
• “>” Coste de
• Infraestructura
• Despliegue
• Administración
• Instancias independientes
• Datos completamente aislados

14. Una aplicación para “n” tenants
• BD compartida
• Escalado
• “>” Coste de…
• Desarrollo
• Administración BD
• Instalación única
• Instancia única
• “<” Coste de…
• Infraestructura
• Despliegue

15. Una aplicación para “n” tenants - evolución
• BD compartida
• “>” Coste de
• Desarrollo
• Administración BD
• Instalación única
• Instancia única
• Escalado casi infinito
• “<” Coste de
• Infraestructura
• Despliegue

16. Una BD para cada tenant
• Instalación e instancia única
• Aislamiento de los datos
• Escalado infinito
• Personalización
• “<” Coste de
• Infraestructura
• Despliegue
• Desarrollo
• BD individual
• “>” Coste de
• Administración BD

17. ¿De dónde veníamos?
y a dónde llegamos…

18. Lo que había…
Web & API
Web & API
Web & API
Cliente 1
Cliente 3
Cliente 2

19. Lo que pensamos inicialmente
BD’s clientes
BD
infraestructura
Multi-tenant
CORE
Web & API
Cliente 1
Cliente 3
Cliente 2

20. Evolución
BD’s clientes
BD
infraestructura
Multi-tenant
CORE
Web & API
CORE
APP
Aprovisiona
miento
Cliente 1
Cliente 3
Cliente 2

21. Aproximación final
BD’s clientes
BD
infraestructura
Multi-tenant
CORE
Web & API
CORE
APP
Aprovisionamiento
Cliente 1
Cliente 3
Cliente 2
(por el momento)

22. El terreno de juego

23. Problemas a resolver
• Arquitectura de la aplicación
• Resolver instancias de cada tenant
• Gestión de la información del tenant
• Login
• Aprovisionamiento nuevos tenant
• URL
• …

24. Estructura del proyecto

25. Contenedor IoC

26. Configurar middleware para mi contenedor IoC

27. Configurar mi contenedor IoC

28. Resolver el tenant

29. Creación de la BD

30. ¿Porqué esta solución?
• Información relevante totalmente separada
• Alto nivel de personalización
• Ahorro en infraestructura
• Escalado infinito
• Fácil aprovisionamiento para nuevos tenant
• No tener que jugar con URLs

31. ¿Preguntas?
Nacho Fanjul
Software Developer
@ nfanjul@plainconcepts.com
@nfanjul
https://github.com/nfanjul

32. Gracias!