Compartir a través de

Consideraciones para actualizar una solución multiinquilino

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: 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 claro la directiva de actualización, ya que algunos de los inquilinos pueden ser renuentes 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:

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

En este artículo, proporcionamos instrucciones para los responsables de la toma de decisiones técnicas sobre los enfoques que puede considerar para actualizar el software de los inquilinos y las desventajas implicadas.

Requisitos de los clientes

A menudo, los clientes tienen requisitos explícitos o implícitos que pueden afectar a cómo se actualiza el sistema. Tenga en cuenta los siguientes aspectos para crear una imagen de cualquier punto de preocupación que puedan generar los clientes:

  • Expectativas y requisitos: Descubra las expectativas o requisitos que los clientes podrían tener sobre cuándo se puede actualizar su solución. Estos podrían comunicarse formalmente a usted en contratos o acuerdos de nivel de servicio (SLA), o podrían ser informales.
  • Ventanas de mantenimiento: Comprenda si los clientes esperan ventanas de mantenimiento definidas por el servicio o incluso autodefinidas. Es posible que necesiten comunicarse a sus usuarios sobre las posibles interrupciones, o podrían esperar poder probar aspectos importantes del servicio una vez completada la actualización.
  • Normativa: Aclarar si los clientes tienen problemas normativos que requieren aprobación adicional antes de que se puedan aplicar las actualizaciones. Por ejemplo, si proporciona una solución de salud que incluye componentes de IoT, es posible que tenga que obtener la aprobación de la Administración de Alimentos y Medicamentos (FDA) de Los Estados Unidos antes de aplicar una actualización.
  • Sensibilidad: Comprenda si alguno de los clientes es especialmente sensible o resistente a la aplicación de actualizaciones. Si lo son, intente entender por qué. Por ejemplo, si ejecutan una tienda física o un sitio web minorista, es posible que quieran evitar actualizaciones alrededor del Viernes Negro, ya que los riesgos son mayores que las posibles ventajas.
  • Historia: Revise su historial de completar actualizaciones con éxito sin que esto afecte a sus clientes. Debe seguir buenas prácticas de DevOps, pruebas, implementación y supervisión para reducir la probabilidad de interrupciones y para asegurarse de que identifica rápidamente los problemas que presentan las actualizaciones. Si sus clientes saben que pueden actualizar sus entornos sin problemas, es menos probable que se opongan.
  • Reversión: Considere si los clientes quieren revertir las actualizaciones si hay un cambio importante y quién desencadenaría dicha solicitud de reversión.

Sus requisitos

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

  • Control que está dispuesto a proporcionar: ¿Es razonable que tus clientes tengan control sobre cuándo se aplican las actualizaciones? Si va a crear una solución que usan los clientes empresariales de gran tamaño, es posible que la respuesta sea sí. Sin embargo, si va a crear una solución centrada en el consumidor, es poco probable que le dé algún control en cómo actualizar o gestionar su solución.
  • Versiones: ¿Cuántas versiones de la solución puede mantener razonablemente al mismo tiempo? Si encuentra un error o una vulnerabilidad de seguridad y necesita aplicar una revisión, es posible que tenga que hacerlo a todas las versiones en uso.
  • Consecuencias de las versiones anteriores: ¿Cuál es el impacto de permitir a los clientes caer demasiado lejos de la versión actual? Si publica nuevas características periódicamente, ¿las versiones anteriores quedarán 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 costos operativos y financieros, ya que se mantiene la compatibilidad con versiones anteriores.
  • Reversión: ¿La estrategia de implementación puede admitir reversiones en versiones anteriores? ¿Quieres habilitar esto?

Nota:

Considere 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 para los procedimientos de software como servicio (SaaS) y las modernas prácticas de DevOps y las tecnologías en la nube le permiten evitar tiempo de inactividad durante las actualizaciones y el mantenimiento. Sin embargo, debe diseñar para implementaciones sin tiempo de inactividad, por lo que es importante tener en cuenta el proceso de actualización al planear la arquitectura de la solución.

Aunque no planee interrupciones durante el proceso de actualización, puede considerar la posibilidad de definir una ventana de mantenimiento normal. Una ventana puede ayudar a comunicarse con los clientes que se producen cambios durante horas específicas.

Para obtener 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.

Encontrar un equilibrio

Si deja la cadencia de las actualizaciones de servicio por completo a la discreción de los inquilinos, es posible que decidan no actualizar nunca. Es importante permitirse actualizar la solución, al tiempo que tiene en cuenta las preocupaciones o restricciones razonables que puedan tener los clientes. Por ejemplo, si un cliente es especialmente sensible a las actualizaciones de un viernes porque ese es su día más ocupado de la semana, ¿puede aplazar fácilmente las actualizaciones a los lunes, sin afectar a la solución?

Un enfoque que puede funcionar bien es desplegar actualizaciones de un inquilino a otro, utilizando uno de los enfoques que se describen a continuación. Dé aviso al cliente de las actualizaciones planeadas. Permitir que los clientes opten temporalmente por excluirse, pero no para siempre; establezca un límite razonable para cuando deba requerir aplicar la actualización.

Además, considere la posibilidad de permitirse la posibilidad de implementar revisiones de seguridad u otras revisiones críticas, con un aviso mínimo o sin antelación. Asegúrese de que los inquilinos comprendan esta práctica y su importancia para proteger sus 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 de permitir que los inquilinos inicien sus propias actualizaciones. Esto es complejo de implementar y requiere un esfuerzo significativo de desarrollo y pruebas para ofrecer y mantener.

Independientemente de lo que haga, asegúrese de que tiene un proceso para supervisar el estado de los inquilinos, especialmente antes y después de aplicar las actualizaciones. A menudo, los incidentes críticos de producción (también denominados incidentes de sitio activo) se producen después de las actualizaciones del código o la configuración. Por lo tanto, es importante supervisar y responder proactivamente a cualquier problema para conservar la confianza del cliente. Para más información sobre la administración de incidentes de sitio activo en cargas de trabajo de SaaS, consulte Administración de incidentes para cargas de trabajo de SaaS en Azure.

Comunicarse con sus clientes

La comunicación clara es clave para crear 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.

Tenga en cuenta las preguntas siguientes:

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

Comunicarse 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 atención al cliente deben poder responder fácilmente a las siguientes preguntas:

  • ¿Se han aplicado actualizaciones recientemente a la infraestructura de un inquilino o a los 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 al cliente tiene la información necesaria para comprender lo que ha cambiado.

Estrategias de implementación para admitir actualizaciones

Tenga en cuenta cómo implementará actualizaciones en la infraestructura. Esto está muy influenciado por el modelo de inquilino que se usa. Tres enfoques comunes para implementar actualizaciones son los sellos 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 que tiene suficientes reportes y visibilidad, de modo que sepa en qué versión de infraestructura, software o característica está cada inquilino, a qué pueden migrar y cualquier dato relacionado con el tiempo asociado a esos estados. El seguimiento de esta información suele ser una de las responsabilidades de un plano de control.

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 sellos 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 entre sellos, sin afectar a otros usuarios.

Marcas de características

Las marcas de características permiten agregar funcionalidad a la solución, al tiempo que solo exponen esa funcionalidad a un subconjunto de los clientes o inquilinos.

Considere la posibilidad de usar marcas de características si alguna de estas situaciones se aplica a usted:

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

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 uno en

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

  • Canario: Un anillo canario incluye sus propios inquilinos de prueba y clientes que desean tener actualizaciones cuando estén disponibles. Cualquiera en el anillo canario debe entender que puede recibir actualizaciones más frecuentes y que es posible que las actualizaciones no hayan pasado por un proceso de validación tan completo como en otros anillos.
  • 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 pertenecen 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 con su 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 en la API.

Colaboradores

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

Autor principal:

  • John Downs | Ingeniero principal de software, Patrones y prácticas de Azure

Otros colaboradores:

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

Paso siguiente

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