Editar

Compartir vía


Enfoques arquitectónicos para una solución multiinquilino

Azure

Hay muchas maneras diferentes de diseñar y compilar soluciones multiinquilino en Azure. En un extremo, puede compartir todos los recursos de la solución entre todos los inquilinos. En el otro extremo, puede implementar recursos aislados para cada inquilino. Puede parecer sencillo implementar recursos independientes para cada inquilino y puede funcionar para un número reducido de inquilinos. Sin embargo, normalmente no es eficiente en gastos y puede ser difícil administrar los recursos. También hay varias estrategias que se sitúan entre estos extremos y todas ellas tienen aparejadas ventajas y desventajas: escala, aislamiento, rentabilidad, rendimiento, complejidad de la implementación y capacidad de administración.

En esta sección, trataremos las categorías principales de servicios de Azure que componen una solución, como proceso, almacenamiento y datos, redes, implementación, identidad, mensajería, inteligencia artificial y aprendizaje automático, e IoT. Para cada categoría, se describen los patrones y enfoques clave que se pueden tener en cuenta al diseñar una solución multiinquilino y algunos antipatrones que se deben evitar.

Patrón de stamps de implementación

El patrón de stamps de implementación se usa con frecuencia en soluciones multiinquilino. Implica la implementación de una infraestructura dedicada para un inquilino o para un grupo de inquilinos. Un solo stamp puede atender a varios inquilinos o puede estar dedicado a un único inquilino.

Diagrama con un ejemplo de implementación del patrón Stamps de implementación. En este caso, cada inquilino tiene su propio stamp que contiene una base de datos.

Cuando se usan stamps de inquilino único, el patrón de stamps de implementación tiende a ser fácil de implementar, ya que es probable que cada stamp no sea consciente de ningún otro, por lo que no es necesario crear ninguna lógica ni funcionalidad de multiinquilinato a nivel de aplicación. Cuando cada inquilino tiene su propio stamp dedicado, este patrón proporciona el mayor grado de aislamiento y mitiga el problema del vecino ruidoso. También ofrece la opción de configurar o personalizar los inquilinos según sus propios requisitos, como estar ubicados en una región geopolítica específica o tener requisitos específicos de alta disponibilidad.

Al usar stamps multiinquilino, es necesario tener en cuenta otros patrones para administrar el multiinquilinato dentro del stamp, y el problema del vecino ruidoso todavía podría ocurrir. Sin embargo, mediante el patrón de stamps de implementación puede seguir escalando a medida que la solución crezca.

El mayor problema con el patrón de stamps de implementación, cuando se usa para atender a un único inquilino, tiende a ser el costo de la infraestructura. Cada stamp debe tener su propio conjunto independiente de infraestructura y la infraestructura no se comparte con otros inquilinos. También debe asegurarse de que los recursos implementados para una marca sean suficientes para satisfacer la carga máxima de la carga de trabajo de ese inquilino. Asegúrese de que el modelo de precios compense el costo de implementación de la infraestructura del inquilino.

Los stamps de un inquilino único suelen funcionar bien cuando se tiene un número pequeño de inquilinos. A medida que crece el número de inquilinos, es posible, pero cada vez más difícil, administrar una flota de stamps de un único inquilino (consulte este caso práctico como ejemplo). También puede aplicar el patrón de stamps de implementación para crear stamps de varios inquilinos, lo que puede aportar algunas ventajas para el uso compartido de recursos y costes.

Para implementar el patrón de stamps de implementación, es importante usar enfoques de implementación automatizados. En función de la estrategia de implementación, puede pensar en administrar los stamps dentro de los procesos de implementación mediante una infraestructura declarativa como código, como archivos de Bicep o plantillas de Terraform. Como alternativa, puede considerar la posibilidad de crear código personalizado para implementar y administrar cada stamp, por ejemplo, mediante los SDK de Azure.

Destinatarios

Los artículos de esta sección están concebidos como un recurso útil para los arquitectos de soluciones y desarrolladores principales de aplicaciones multiinquilino, incluidos proveedores de software independientes (ISV) y startups que desarrollan soluciones SaaS. Gran parte de las instrucciones de esta sección son genéricas y se aplican a varios servicios de Azure dentro de una categoría.

Pasos siguientes

Se recomienda revisar los enfoques de la organización de recursos en una solución multiinquilino antes de revisar las instrucciones sobre categorías específicas de servicios de Azure.