Consideraciones sobre el ciclo de vida de los inquilinos en una solución multiinquilino
Al considerar una arquitectura multiinquilino, es importante tener en cuenta todas las fases del ciclo de vida de un inquilino. En esta página, se proporcionan instrucciones para los responsables técnicos de la toma de decisiones sobre las fases del ciclo de vida y las consideraciones importantes para cada fase.
Inquilinos de evaluación gratuita
Cuando cree soluciones SaaS, tenga en cuenta que muchos clientes solicitan o piden evaluaciones gratuitas antes de comprometerse a comprar una solución.
Las evaluaciones gratuitas aportan las siguientes consideraciones únicas:
- Requisitos de servicio: ¿deben estar las evaluaciones gratuitas sujetas a los mismos requisitos de seguridad de datos, rendimiento y nivel de servicio que los datos de los clientes de pleno derecho?
- Infraestructura: ¿se debe usar la misma infraestructura para los inquilinos de evaluación gratuita que para los clientes de pleno derecho o debería haber una infraestructura dedicada para los primeros?
- Migración: si los clientes compran el servicio después de una evaluación gratuita, ¿cómo migrarán los datos de sus inquilinos de prueba a los de pago?
- Proceso de solicitud: ¿hay límites en torno a quién puede solicitar una evaluación gratuita? ¿Cómo puede evitar el abuso de la solución? ¿Permite la creación automatizada de inquilinos de evaluación gratuita o su equipo participa en cada solicitud?
- Límites: ¿qué límites quiere o debe aplicar a los clientes de evaluación gratuita, por ejemplo, límites de tiempo, restricciones de características o limitaciones en torno al rendimiento?
En algunas situaciones, un modelo de precios freemium puede ser una alternativa a la evaluación gratuita.
Incorporación de nuevos inquilinos
Al incorporar un nuevo inquilino, tenga en cuenta las siguientes cuestiones:
- Proceso: ¿será la incorporación un proceso manual, automatizado o de autoservicio?
- Residencia de datos: ¿tiene el inquilino algún requisito específico de residencia de datos? Por ejemplo, ¿hay regulaciones de soberanía de datos en vigor?
- Cumplimiento: ¿tiene el inquilino que satisfacer los estándares de cumplimiento (como PCI DSS, HIPAA, etc.)?
- Recuperación ante desastres: ¿tiene el inquilino algún requisito específico de recuperación ante desastres, como un objetivo de tiempo de recuperación (RTO) o un objetivo de punto de recuperación (RPO)? ¿Son diferentes de las garantías que proporciona a otros inquilinos?
- Información: ¿qué información necesita para poder incorporar completamente el inquilino? Por ejemplo, ¿necesita conocer el nombre legal de su organización? ¿Necesita su logotipo de empresa para personalizar la aplicación y, si es así, qué tamaño y formato de archivo necesita?
- Facturación: ¿proporciona la plataforma diferentes opciones de precios y modelos de facturación?
- Entornos: ¿requiere el inquilino entornos posteriores a la producción? ¿Hay expectativas establecidas sobre disponibilidad para ese entorno? ¿Es transitorio (a petición) o siempre está disponible?
Una vez incorporados los inquilinos, se mueven a un estado de "situación normal". Sin embargo, todavía hay varios eventos importantes del ciclo de vida que pueden producirse, aunque estén en este estado.
Actualización de la infraestructura de los inquilinos
Deberá tener en cuenta la forma de aplicar las actualizaciones a la infraestructura del inquilino. Puede que se apliquen actualizaciones a distintos inquilinos en momentos diferentes.
Consulte Actualizaciones para conocer otras consideraciones sobre cómo actualizar las implementaciones de los inquilinos.
Modificación de la escala de la infraestructura de los inquilinos
Tenga en cuenta si los inquilinos pueden tener patrones empresariales estacionales u otros cambios del nivel de consumo de la solución.
Por ejemplo, si proporciona una solución a los minoristas, es de esperar que en determinados momentos del año esté especialmente ocupada en algunas regiones geográficas y tranquila en otras. Considere si esta estacionalidad afecta a la forma en que diseña y escala la solución. Tenga en cuenta cómo la estacionalidad puede afectar a los problemas de vecino ruidoso, como cuando un subconjunto de inquilinos experimenta un aumento repentino e inesperado de la carga que reduce el rendimiento de otros inquilinos. Puede considerar la posibilidad de aplicar mitigaciones, que pueden incluir el escalado de infraestructuras de inquilinos individuales, el traslado de inquilinos entre implementaciones y el aprovisionamiento de un nivel de capacidad suficiente para controlar los altibajos del tráfico.
Traslado de inquilinos entre infraestructuras
Puede que tenga que mover inquilinos entre infraestructuras por diferentes motivos, como:
- Reequilibrio: siga un enfoque con particiones verticales para asignar los inquilinos a la infraestructura, y mueva un inquilino a otra implementación para reequilibrar la carga.
- Actualizaciones: los inquilinos actualizan su SKU o plan de tarifa, y deben moverse a una implementación dedicada de un solo inquilino con un mayor aislamiento de otros inquilinos.
- Migraciones: un inquilino solicita que sus datos se muevan a un almacén de datos dedicado.
- Movimiento de región: un inquilino requiere que sus datos se muevan a una nueva región geográfica. Este requerimiento puede darse en adquisiciones de empresas o cuando cambian las leyes o las situaciones geopolíticas.
Piense en la forma de mover los datos de los inquilinos y redirigir las solicitudes al nuevo conjunto de infraestructura que hospeda su instancia. También debe considerar si mover un inquilino dará lugar a tiempo de inactividad y asegurarse de que los inquilinos sean plenamente conscientes del riesgo.
Combinación y división de inquilinos
Es tentador pensar que los inquilinos o clientes son entidades estáticas e invariables. Sin embargo, en realidad, a menudo no es cierto. Por ejemplo:
- En escenarios empresariales, se pueden adquirir o fusionar compañías, incluidas las ubicadas en regiones geográficas diferentes.
- En entornos empresariales, las compañías se pueden dividir o liquidar.
- En escenarios de consumidor, los usuarios individuales pueden unirse o abandonar familias.
Considere si necesita proporcionar funcionalidades para administrar la fusión y separación de datos, identidades de usuario y recursos. Además, tenga en cuenta cómo afecta la propiedad de los datos al control de las operaciones de fusión y división. Por ejemplo, considere una aplicación de fotografía de consumidor creada para que las familias compartan fotos entre sí. ¿Son las fotos propiedad de los miembros individuales de la familia que las han aportado o de la familia en su conjunto? Si algún usuario abandona la familia, ¿deben quitarse sus datos o permanecer en el conjunto de datos de la familia? Si los usuarios se unen a otra familia, ¿deben moverse sus fotos antiguas con ellos?
Retirada de inquilinos
También es inevitable que, en ocasiones, haya inquilinos que deban quitarse de la solución. En una solución multiinquilino, esto conlleva algunas consideraciones importantes, incluidas las siguientes:
- Período de retención: ¿cuánto tiempo debe mantener los datos de los clientes? ¿Existen requisitos legales para destruir datos después de un período de tiempo determinado?
- Reincorporación: ¿debe dar la posibilidad de volver a incorporar a los clientes? ¿Seguirán estando disponibles sus datos si se vuelven a unir dentro del plazo de retención de datos?
- Reequilibrio: si ejecuta una infraestructura compartida, ¿necesita reequilibrar la asignación de inquilinos a la infraestructura?
Desactivación y reactivación
Hay situaciones en las que puede que sea necesario desactivar o reactivar la cuenta de un cliente. Por ejemplo:
- El cliente ha solicitado la desactivación. En un sistema de consumidor, un cliente podría optar por cancelar la suscripción.
- No se puede facturar al cliente y es necesario desactivar la suscripción.
La desactivación es independiente de la retirada, ya que está pensada para ser un estado temporal. Sin embargo, después de un período de tiempo, puede optar por retirar un inquilino desactivado.
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Autor principal:
- John Downs | Ingeniero principal de software
Otros colaboradores:
- Chad Kittel | Ingeniero principal de software
- Paolo Salvatori | Ingeniero de clientes principal, FastTrack for Azure
- Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure
Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.
Pasos siguientes
Considere los modelos de precios que usará para la solución.