Consideraciones para actualizar una solución multiinquilino

  • Artículo
  • 8 minutos para leer

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 actualizaciones a la solución y es posible que tenga que realizar cambios en la infraestructura de Azure, el código o las aplicaciones, 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 los tiempos en los que se puede actualizar su servicio. Debe identificar los requisitos de los inquilinos, aclarar sus propios requisitos para utilizar el servicio, encontrar un equilibrio que funcione para todos y, a continuación, comunicarlo nítidamente.

Requisitos de los clientes

Pregúntese lo siguiente:

  • ¿Tienen los clientes expectativas o requisitos sobre cuándo se pueden actualizar? Pueden habérselos comunicado formalmente en contratos o contratos de nivel de servicio, o pueden ser informales.
  • ¿Esperan los clientes ventanas de mantenimiento definidas por el servicio o incluso autodefinidas? Es posible que deban comunicarse con sus propios clientes sobre posibles interrupciones.
  • ¿Tienen los clientes prioridades normativas que requieran aprobación adicional antes de que se puedan aplicar 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.
  • ¿Alguno de los clientes es especialmente sensible o resistente a la aplicación de actualizaciones? Intente comprender 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.
  • ¿Cuál es su historial de finalización correcta de actualizaciones sin ningún impacto para 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.
  • ¿Querrán los clientes revertir las actualizaciones si hay un cambio importante?

Sus requisitos

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

  • ¿Es razonable que los clientes tengan el control sobre cuándo se aplican las actualizaciones? Si crea 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.
  • ¿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.
  • ¿Cuáles son las consecuencias de permitir que la versión de los clientes se quede demasiado alejada de la 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.
  • ¿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. Debe diseñar para esto, por lo que es importante tener en cuenta el proceso de actualización al diseñar la arquitectura de la solución. Tenga en cuenta que, aunque no planee interrupciones, puede considerar la posibilidad de definir una ventana de mantenimiento periódica, para que los clientes entiendan que los cambios se realizan en momentos específicos. Para más información sobre cómo lograr implementaciones sin tiempo de inactividad, consulte Alcanzar un tiempo de inactividad nulo mediante 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 sensible a las actualizaciones en viernes (puesto que es el día que tiene mayor actividad de la semana), ¿puede aplazar con facilidad las actualizaciones a los lunes, sin afectar a la solución?

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.

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 requerirá 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 más información sobre la supervisión, consulte Supervisión de DevOps.

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 permiso proporcionando un proceso de no participación?
  • ¿Tiene una ventana de mantenimiento programado que se usa al aplicar actualizaciones?
  • ¿Qué ocurre si tiene 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?

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 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?
  • ¿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.

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

Stamps de implementación

Algunas 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 afecte a otros.

Marcas de característica

Las marcas de característica permiten agregar funcionalidad a la solución, a la vez que solo se exponen a un subconjunto de sus clientes o inquilinos. Puede usar marcas de característica si implementa actualizaciones con regularidad, pero quiere evitar mostrar nuevas funcionalidades, o si quiere evitar aplicar cambios de comportamiento hasta que un cliente participe.

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. 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 otras opciones. Un anillo de usuario pionero contiene inquilinos que son ligeramente más reacios al riesgo, pero sin embargo están preparados para recibir actualizaciones periódicas. 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.

Pasos siguientes