Compartir vía

Consideraciones para actualizar una solución multiinquilino

  • Artículo

Una de las ventajas de la tecnología en la nube es la mejora y la evolución continuas. Como proveedor de servicios, debe aplicar las actualizaciones en la solución y es posible que tenga que realizar cambios en el código de la aplicación, la infraestructura de Azure, los esquemas de base de datos o cualquier otro componente. Es importante planear cómo actualizar los entornos. En una solución multiinquilino, es especialmente importante tener clara la directiva de actualización, ya que algunos de los inquilinos pueden ser reacios a permitir cambios en sus entornos, o pueden tener requisitos que limiten las condiciones en las que puede actualizar su servicio.

Al planear una estrategia para actualizar la solución, debe hacer lo siguiente:

  • Identifique los requisitos de los inquilinos.
  • Aclare sus propios requisitos para operar su servicio.
  • Busque un equilibrio que usted y sus inquilinos puedan aceptar.
  • Comunique claramente su estrategia a los inquilinos y a otras partes interesadas.

En esta artículo, se proporciona una guía para los responsables técnicos de la toma de decisiones sobre los enfoques que se pueden considerar para actualizar el software de los inquilinos y las ventajas y desventajas que ello supone.

Requisitos de los clientes

A menudo, los clientes tienen requisitos explícitos o implícitos que pueden afectar a la forma en que se actualiza el sistema. Tenga en cuenta los siguientes aspectos para hacerse una idea de cualquier motivo de preocupación que puedan tener los clientes:

  • Expectativas y requisitos: Identifique cualquier expectativa o requisito que los clientes puedan tener sobre cuándo se puede actualizar la solución. Pueden habérselos comunicado formalmente en contratos o contratos de nivel de servicio, o pueden ser informales.
  • Períodos de mantenimiento: Conozca si los clientes esperan períodos de mantenimiento definidos por el servicio o definidos por ellos mismos. Es posible que necesiten comunicar a sus usuarios acerca de las posibles interrupciones o que necesiten probar elementos importantes del servicio una vez completada la actualización.
  • Normativas: Ponga en claro si sus clientes tienen algún problema sobre regulaciones que requiera una aprobación adicional antes de poder aplicar las actualizaciones. Por ejemplo, si proporciona una solución sanitaria que incluya componentes de IoT, es posible que tenga que obtener la aprobación de la Administración de Medicamentos y Alimentos (FDA) de Estados Unidos antes de aplicar una actualización.
  • Susceptibilidad: Confirme si alguno de los clientes es especialmente susceptible o resistente a realizar actualizaciones. Si es así, intente dilucidar por qué. Por ejemplo, si dirige una tienda física o un sitio web de venta al por menor, es posible que quiera evitar actualizaciones alrededor del Black Friday, ya que los riesgos son mayores que las posibles ventajas.
  • Historial: Revise el historial de finalización correcta de actualizaciones sin que hayan afectado a los clientes. Debe seguir buenas prácticas de DevOps, pruebas, implementación y supervisión para reducir la probabilidad de interrupciones y asegurarse de identificar rápidamente los problemas que presentan las actualizaciones. Si los clientes saben que puede actualizar sus entornos sin problemas, es menos probable que se opongan.
  • Reversión: Indague si los clientes quieren revertir las actualizaciones si hay un cambio importante y quién solicitaría dicha reversión.

Sus requisitos

También debe tener en cuenta las siguientes preguntas desde su propia perspectiva:

  • Controlar lo que está dispuesto a proporcionar: ¿es razonable que los clientes tengan control sobre cuándo se aplican las actualizaciones? Si va a crear una solución que usan los clientes de grandes empresas, la respuesta puede ser sí. Sin embargo, si crea una solución centrada en el consumidor, es poco probable que proporcione el control sobre cómo actualizar u operar la solución.
  • Versiones: ¿cuántas versiones de la solución puede mantener razonablemente a la vez? Recuerde que si encuentra un error y necesita realizar una corrección, es posible que tenga que aplicarla a todas las versiones en uso.
  • Consecuencias de las versiones anteriores: ¿cuál es el impacto de permitir que los clientes se queden muy por detrás de la versión actual? Si publica nuevas características de forma periódica, ¿se volverán las versiones anteriores obsoletas rápidamente? Además, según la estrategia de actualización y los tipos de cambios, es posible que tenga que mantener infraestructuras independientes para cada versión de la solución. Por lo tanto, puede haber costes operativos y financieros para mantener la compatibilidad con versiones anteriores.
  • Reversión: ¿puede la estrategia de implementación admitir reversiones a versiones anteriores? ¿Es una opción que quiera habilitar?

Nota

Analice si necesita desconectar la solución para las actualizaciones o el mantenimiento. Por lo general, las ventanas de interrupción se ven como una práctica obsoleta. Las prácticas de DevOps modernas y las tecnologías en la nube permiten evitar tiempos de inactividad durante las actualizaciones y el mantenimiento. Sin embargo, debe diseñar pensando en implementaciones sin tiempo de inactividad, por lo que es importante tener en cuenta el proceso de actualización al diseñar la arquitectura de la solución.

Incluso si no planea interrupciones durante el proceso de actualización, es posible que considere la posibilidad de definir una ventana de mantenimiento periódico. Una ventana puede ayudar a comunicar a los clientes que se van a producir cambios durante horas específicas.

Para más información sobre cómo lograr implementaciones sin tiempo de inactividad, consulte Eliminación del tiempo de inactividad a través de actualizaciones de servicio con versiones.

Búsqueda del equilibrio

Si deja la cadencia de las actualizaciones del servicio completamente a discreción de los inquilinos, es posible que decidan no actualizar nunca. Es importante permitirse actualizar la solución, a la vez que se tienen en cuenta las preocupaciones o restricciones razonables que puedan tener los clientes. Por ejemplo, si un cliente es especialmente susceptible a las actualizaciones los viernes, porque es el día de la semana con mayor actividad, ¿puede aplazar con facilidad las actualizaciones a los lunes, sin que la solución se vea afectada?

Un enfoque que puede funcionar bien es la implementación de actualizaciones por inquilino, mediante uno de los enfoques que se describen a continuación. Notifique al cliente las actualizaciones planeadas. Permita que los clientes opten por no actualizar durante un tiempo, pero no indefinidamente. Ponga un límite razonable en el que requerirá que se aplique la actualización.

Además, considere la posibilidad de permitirse implementar actualizaciones de seguridad u otras correcciones críticas, con un aviso mínimo o sin previo aviso. Asegúrese de que los inquilinos conozcan este procedimiento y su importancia para proteger los datos.

Otro enfoque puede ser permitir que los inquilinos inicien sus propias actualizaciones en un momento de su elección. De nuevo, debe proporcionar una fecha límite, momento en el que aplicará la actualización en su nombre.

Advertencia

Tenga cuidado al permitir que los inquilinos inicien sus propias actualizaciones. Es complejo de implementar y precisa de un esfuerzo significativo de desarrollo y pruebas para poderlo ofrecer y mantener.

Haga lo que haga, asegúrese de tener un proceso para supervisar el estado de los inquilinos, especialmente antes y después de que se apliquen las actualizaciones. A menudo, los incidentes críticos de producción (también denominados incidentes de sitio activo) suceden después de las actualizaciones del código o configuración. Por lo tanto, es importante supervisar de forma proactiva y responder a cualquier problema del cliente para conservar su confianza. Para obtener más información acerca de la supervisión, consulte Recomendaciones para diseñar y crear un sistema de supervisión.

Comunicación con los clientes

La comunicación clara es clave para generar la confianza de los clientes. Es importante explicar las ventajas de las actualizaciones periódicas, incluidas las nuevas características, las correcciones de errores, la resolución de vulnerabilidades de seguridad y las mejoras de rendimiento. Una de las ventajas de una solución moderna hospedada en la nube es la entrega continua de características y actualizaciones.

Pregúntese lo siguiente:

  • ¿Notificará a los clientes las próximas actualizaciones?
  • Si lo hace, ¿solicitará implícitamente el permiso mediante un proceso de exclusión voluntaria?, y, ¿cuáles son los límites de la exclusión voluntaria?
  • ¿Tiene una ventana de mantenimiento programado que se usa al aplicar actualizaciones?
  • ¿Qué pasa si hay una actualización de emergencia, como una actualización de seguridad crítica? ¿Puede forzar actualizaciones en esas situaciones?
  • Si no puede notificar al cliente de forma proactiva las próximas actualizaciones, ¿puede proporcionar notificaciones retrospectivas? Por ejemplo, ¿puede actualizar una página de su sitio web con la lista de actualizaciones que ha aplicado?
  • ¿Cuántas versiones distintas del sistema mantendrá en producción?

Comunicación con el equipo de soporte técnico al cliente

Es importante que su propio equipo de soporte técnico tenga visibilidad completa de las actualizaciones que se han aplicado a la infraestructura de cada inquilino. Los representantes de soporte técnico al cliente deben poder responder fácilmente a las siguientes preguntas:

  • ¿Se han aplicado actualizaciones recientemente a la infraestructura de un inquilino o a componentes compartidos?
  • ¿Cuál era la naturaleza de esas actualizaciones?
  • ¿Cuál era la versión anterior?
  • ¿Con qué frecuencia se aplican las actualizaciones a este inquilino?

Si uno de los clientes tiene un problema debido a una actualización, debe asegurarse de que el equipo de soporte técnico tiene la información necesaria para comprender lo que ha cambiado.

Estrategias de implementación para admitir actualizaciones

Analice cómo implementará las actualizaciones en la infraestructura. Esto está muy influenciado por el modelo de inquilino que se usa. Tres enfoques comunes para implementar actualizaciones son los stamps de implementación, las marcas de características y los anillos de implementación. Puede usar estos enfoques de forma independiente, o puede combinarlos para satisfacer requisitos más complejos.

En todos los casos, asegúrese de tener suficientes informes y visibilidad para saber en qué versión de la infraestructura, el software o las característica se encuentra cada inquilino, a qué puede migrar y los datos relacionados con el tiempo asociados a dichos estados.

Patrón de stamps de implementación

Muchas aplicaciones multiinquilino son una buena opción para el patrón de stamps de implementación, en el que se implementan varias copias de la aplicación y otros componentes. En función de los requisitos de aislamiento, puede implementar un stamp para cada inquilino o stamps compartidos que ejecuten cargas de trabajo de varios inquilinos.

Los stamps son una excelente manera de proporcionar aislamiento entre inquilinos. También proporcionan flexibilidad para el proceso de actualización, ya que puede implementar actualizaciones progresivamente en los stamps, sin que otros se vean afectados.

Marcas de característica

Las marcas de característica permiten agregar funcionalidad a la solución, a la vez que solo exponen esa funcionalidad a un subconjunto de sus clientes o inquilinos.

Considere la posibilidad de usar marcas de características si alguna de estas situaciones le es aplicable:

  • Implementa actualizaciones con regularidad, pero quiere evitar mostrar nuevas funcionalidades hasta que se implementen por completo.
  • Quiere evitar aplicar cambios de comportamiento hasta que el cliente opte por ello.

Puede insertar compatibilidad con marcas de característica en la aplicación escribiendo código usted mismo o mediante un servicio como Azure App Configuration.

Anillos de implementación

Los anillos de implementación permiten implementar actualizaciones progresivamente en un conjunto de inquilinos o stamps de implementación. Puede asignar un subconjunto de inquilinos a cada anillo.

Puede determinar cuántos anillos crear y qué significa cada anillo para su propia solución. Normalmente, las organizaciones usan los siguientes anillos:

  • Valor controlado: un anillo de valor controlado incluye sus propios inquilinos y clientes de prueba que quieren tener las actualizaciones en cuanto están disponibles, con el conocimiento de que pueden recibir actualizaciones con más frecuencia y que es posible que no hayan pasado por un proceso de validación tan completo como en las otras opciones.
  • Usuario pionero: un anillo de usuario pionero contiene inquilinos que son ligeramente más reacios al riesgo, pero que aun así están preparados para recibir actualizaciones periódicas.
  • Usuarios: la mayoría de los inquilinos pertenecerán al anillo de usuarios, que recibe actualizaciones menos frecuentes y más probadas.

Versiones de API

Si el servicio expone una API externa, tenga en cuenta que las actualizaciones que aplique podrían afectar a la forma en que los clientes o asociados se integran en la plataforma. En concreto, debe ser consciente de los cambios importantes en las API. Considere la posibilidad de usar una estrategia de control de versiones de API para mitigar el riesgo de actualizaciones de la API.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

Otros colaboradores:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Paso siguiente

Tenga en cuenta cuándo asignaría las solicitudes a los inquilinos en una solución multiinquilino.