Cómo gestionar a tus clientes en un entorno Multi-Tenant de Azure | Parte 3: Modelo de precios y gestión de recursos y costes
En las dos partes anteriores de esta serie de artículos sobre Cómo gestionar a tus clientes en un entorno multi-tenant en Azure:
destacamos puntos importantes del recorrido que debemos tener en cuenta a la hora de crear una solución multitenant:
- Niveles de aislamiento entre Tenants
- Límites y escalado
- Ciclo de vida de un Tenant: decisiones de arquitectura y despliegue
Aún así, con toda esta información sobre la que trabajar, existen puntos que todavía necesitamos analizar y conocer para poder tomar decisiones:
- Gestión de recursos de computación de Azure
- Gestión de Costes
Estos son los puntos que repasaremos en este nuevo artículo, y llegados a este nivel, finalmente, podremos decidir qué modelo de precios aplicamos a nuestro sistema.
Gestión de Recursos de Computación en Azure
Hay diversos modos para llevar a cabo esta gestión. Deberemos tener dentro de nuestro radar conceptos como:
- Web Server
- App Services
- Load Balancing
- Statefulness – Gestión del estado de cada Tenant
A la hora de diseñar cómo gestionaremos los recursos de computación. Podemos encontrar más detalle en: Architectural approaches for compute in multitenant solutions
Hay un aspecto concreto de esta gestión de recursos que me gustaría recalcar. Retomando el símil de “inquilino” de una casa que hacíamos en la primera parte de esta serie de artículos; nos podemos encontrar con los típicos vecinos ruidosos o Noisy Neighbours.
En el caso de un entorno compartido de Azure, con una capacidad del sistema total compartida, un “vecino ruidoso” podría ser ese tenant que utiliza tanto los recursos compartidos que provoca que éstos dejen de estar disponibles para otro Tenant:
Como podemos imaginar, este escenario se puede complicar cuando en el edificio hay más de dos apartamentos y más de un solo “vecino ruidoso”. Para mitigar estos casos nos podemos plantear diferentes estrategias:
- Desplegar con recursos compartidos sobredimensionados
- Escalar dinámicamente el sistema en función de su carga. De modo que nos aseguramos de tener los recursos suficientes para cada momento
- Crear varios pools de recursos y asegurarnos que los Tenants de esos pools tengan diferentes cargas de trabajo
- También cabe la posibilidad de utilizar throttling para establecer límites para cada Tenant
Para poder asegurar que nuestros Tenants tendrán el servicio que necesitan en cada momento. Recordad esa “ilusión de entorno dedicado” que comentábamos en el primer artículo de esta serie.
Gestión de costes en un entorno Multi-Tenant
A primera vista podemos pensar: “Ya parece bastante complicada la gestión de costes en Azure para un único Tenant, ¿cómo debe ser para múltiples Tenants?”, ¿cómo puedo cobrar a mis clientes el coste de recursos de Azure que ha utilizado?
En el artículo “Architectural approaches for cost management and allocation in a multitenant solution” podemos encontrar todas las herramientas necesarias y consideraciones que tenemos a disposición para este tema:
- Utilizar Resource Tags para etiquetar los recursos de cada Tenant. Este caso se complica en un entorno compartido.
- Utilizar la instrumentación:
- Por ejemplo: medir el número de peticiones de cada Tenant mediante:
- Event Hubs (tratando cada petición como si fuese un evento)
- Application Insights que no está pensada para esta labor ni se recomienda usarla, aunque hay gente que las utiliza
- Por ejemplo: medir el número de peticiones de cada Tenant mediante:
Respecto a la gestión de costes deberemos tener en cuenta la precisión que deseamos. Para ello nos podemos hacer las siguientes preguntas:
- ¿Por qué estoy midiendo? ¿Cuál es mi propósito?
- ¿Necesito costes aproximados o costes exactos?
- ¿Cómo gestionaré los componentes compartidos?
y analizar cómo responder a cada una de ellas con los recursos que nos brinda Azure.
Modelos de precios
Llegados a este punto, ya tenemos claro todo lo que necesitamos para poder gestionar un entorno multi-tenant en Azure. Pero como es normal, querremos ganar dinero con nuestra plataforma, entonces ¿qué modelos de precio puedo usar?
La respuesta a esta pregunta está ligada estrechamente con cuál va a ser nuestro modelo de negocio dado que va a tener una relación directa con el modelo de precio a ofrecer.
De por sí los modelos de precio ya son complejos, en este artículo repasaremos algunas pinceladas sobre ellos. Podéis encontrar más detalle en “Pricing models for a multitenant solution”.
Algunas opciones de modelo de precios que tenemos son:
- Cobrar a cada tenant una tarifa plana: sin importar cuántos recursos del sistema utiliza cada Tenant.
- Cobrar por consumo a cada Tenant; pero como hemos visto es un punto difícil de predecir con los que también será difícil predecir nuestro coste y nuestro beneficio.
- Aplicar el modelo Freemium: ofrecer algunas funcionalidades i/o características de nuestro sistema gratuitamente y cobrar por otras añadidas o mejoradas.
- Tiered Pricing: En esta opción no ofrecemos nada gratuitamente, pero sí diferentes categorías de nuestro sistema asociada cada una de ellas con un conjunto de funcionalidades que se pueden utilizar. Sería al estilo “Bronce, Plata, Oro”
En resumen, sea cual sea el modelo de precios que deseamos aplicar deberemos tener en cuenta:
- Medir el uso de los recursos de cada Tenant
- Gestionar los costes totales o parciales
- Asegurar límites de uso
- Plantearnos, si aplica en nuestro sistema el activar y desactivar funcionalidades
Gestión de un entorno Multi-Tenant en Azure
En esta serie de artículos hemos aprendido la gestión de un entorno multi-tenant en Azure recorriendo:
- Las diferentes opciones de aislamiento que podemos aplicar
- Límites y escalado
- Ciclo de vida de un tenant
- Gestión de la computación
- Costes
- Precios
Hay aspectos más técnicos y arquitectónicos que también debemos tener en cuenta. Podéis revisar todos ellos en esta formación de Microsoft, “Managing Your Customers in a Multi-Tenant Environment” que ha sido la fuente más importante de información para desarrollar estos artículos.