Como veníamos platicando en la parte 1 de este articulo, la arquitectura de la solución puede influir en las opciones que se tiene disponibles para el aislamiento. Por ejemplo, imaginemos en una arquitectura de la solución de tres niveles
1) El nivel de interfaz de usuario, puede ser una aplicación web multi tenant compartida y todos los inquilinos accedan a través de un nombre de host único.
2) El nivel intermedio puede ser una capa de aplicación compartida con colas de mensajes compartidos.
3) La cola de datos podría ser bases de datos aisladas o contenedores de blobs
sea cual sea la opción, es importante considerar la posibilidad de combinar o en si caso hacer coincidir diferentes niveles de aislamiento en cada nivel. La decisión de este aislamiento tendrá distintos criterios de aceptación como lo serán:
1) Coste
2) Complejidad
3) Requisitos de los clientes
4) Numero de recursos
Modelos de tenant comunes
Ya teniendo los requisitos analizados y evaluados podremos considerar algunos de los patrones de implementación para sistemas multi tenant.
1) Implementaciones automatizadas de tenant único:
En este modelo se implementa un conjunto dedicado de infraestructura para cada tenant, la aplicación es responsable de iniciar y coordinar la implementación de los recursos de cada tenant.
Estas soluciones hacen un uso extensivo de la infraestructura como código o de las api de Azure Resource Manager. Este enfoque es bueno cuando necesitamos aprovisionar infraestructuras completamente independientes de cada uno de los clientes.
Una de sus principales ventajas es que los datos están completamente aislados para cada tenant, lo que reduce considerablemente el riesgo de inconsistencia de información o perdida accidental.
Uno de los riesgos es que su rentabilidad es baja, ya que no se comparte la infraestructura entre los tenant y eso puede abrir la puerta a que los tenants puedan tener gastos excesivos.
2) Implementaciones totalmente multi tenant
Ahora podemos considerar una implementación completamente multi tenant en donde si se comparten todos los componentes.
Solo se tiene un conjunto de infraestructura para implementar y mantener, y todos los inquilinos la usan.
Una de sus ventajas de esta implementación es el coste, ya que se utiliza una solución con componentes compartidos, incluso si se llegara a requerir implementaciones con SKU superiores, seguirá siendo para todos los tenants.
Unos de los riesgos es la consistencia de la información ya que no se debe filtrar datos entre tenants , aquí es probable que se apliquen técnicas de administración y particionamiento de datos además de pensar en como actuar o que pasara si un tenant requiere de algún ajuste especifico y como afectara a los demás tenants.
3) Implementaciones con particiones verticales
No es todo o nada, ahora con esta implementación podemos considerar la posibilidad de crear particiones verticales de algunos tenants, por ejemplo:
podemos usar una combinación de implementaciones de tenant único con multi tenant para clientes que necesiten mayor rendimiento o con características particulares.
podemos implementar varias instancias de la solución geográficamente y un tenant puede estar en una área geográfica especifica.
Una de las ventajas sigue siendo el compartimiento de la infraestructura y que toma ventajas de los modelos de implementación anteriores.
Un riesgo es que ahora hay que hacer énfasis en el código ya que la arquitectura de ese código debe estar diseñada para soportar implementaciones generales o especificas
4) Implementaciones con particiones horizontales
Es posible también considerar este tipo de implementaciones ya que esto implica tener componentes compartidos y como hemos visto es una mejora considerable tomando en cuenta los riesgos del compartimiento de la infraestructura.
Una de las ventajas es que se pueden mitigar problemas de vecinos ruidosos ya que por ejemplo al ser horizontal podemos tener en algún servidor bases de datos para diferentes clientes y cada quien utilizaría su base de datos
Un riesgo es que por ejemplo al momento de desplegar debemos tener en cuenta los parches o actualizaciones individuales para cada cliente.
ahora que ya sabemos estos puntos, debemos hacernos la siguiente pregunta.
¿Cómo probar el aislamiento?
podemos considerar el usar el servicio de Azure Chaos Studio para poder introducir errores que simulan interrupciones o problemas del mundo real y comprobar la resistencia y resiliencia de nuestras soluciones multi tenant
Excelente, has llegado al final, por hoy reflexiona, ¿Qué pasaría si en tu solución un servidor deja de funcionar?, ¿estas listo para atender esa situación?, ¿Cómo administras la información de tus clientes?, ¿ es fácil migrar de tecnologías o frameworks?
déjame tus comentarios y debatamos acerca de esto, seria genial tu apoyo compartiendo este articulo y comentándome que te parece esta serie de artículos.
Comparto mis redes para cualquier duda, y dirían por ahí ¡voy y vengo!
Top comments (0)