Compensación de la confiabilidad para las cargas de trabajo Power Platform
Una carga de trabajo fiable cumple de forma coherente con sus objetivos de fiabilidad definidos. Debería alcanzar objetivos de resistencia establecidos, idealmente evitando eventos que afecten a la fiabilidad. Sin embargo, de manera realista, una carga de trabajo debe tolerar y controlar el impacto de tales eventos y mantener las operaciones a un nivel predeterminado durante el mal funcionamiento activo. Incluso durante un desastre, una carga de trabajo fiable debe recuperarse a un estado específico en un período de tiempo determinado, ambos acordados entre las partes interesadas. Es vital contar con un plan de respuesta a incidentes que le permita lograr una detección y una recuperación rápidas.
Durante la fase de diseño de una carga de trabajo, debe considerar cómo las decisiones basadas en los principios de diseño de fiabilidad y las recomendaciones de la lista de comprobación de revisión del diseño para la fiabilidad podría influir en los objetivos y las optimizaciones de otros pilares. Ciertas decisiones pueden beneficiar a algunos pilares, pero constituir una desventaja para otros. Este artículo describe ejemplos de desventajas que un equipo de cargas de trabajo puede encontrar al diseñar la arquitectura y las operaciones de la carga de trabajo para lograr fiabilidad.
Desventajas de Fiabilidad con respecto a Seguridad
Compensación: Mayor superficie de carga de trabajo. El pilar Seguridad da prioridad a una superficie reducida y contenida para minimizar los vectores de ataque y reducir la administración de los controles de seguridad.
La fiabilidad a menudo se obtiene mediante la replicación. La replicación puede ocurrir a nivel de componente, a nivel de datos o incluso a nivel geográfico. Las réplicas, por diseño, aumentan la superficie de una carga de trabajo. Desde el punto de vista de la seguridad, se prefiere una superficie reducida y contenida para minimizar los posibles vectores de ataque y agilizar la administración de los controles de seguridad.
De manera similar, las soluciones de recuperación ante desastres, como las copias de seguridad, aumentan la superficie de una carga de trabajo. Sin embargo, suelen estar aislados del tiempo de ejecución de la carga de trabajo. Esto requiere la implementación de controles de seguridad adicionales, que pueden ser específicos de la solución de recuperación ante desastres.
En aras de los objetivos de fiabilidad, es posible que se necesiten componentes adicionales para la arquitectura, lo que aumenta el área de la superficie. Esta mayor complejidad aumenta la superficie de la carga de trabajo al agregar nuevos componentes que deben protegerse, posiblemente de formas que aún no se utilizan en el sistema. Normalmente, estos componentes van acompañados de código adicional para respaldar su uso o patrones generales de fiabilidad, lo que también aumenta la superficie de la aplicación.
Cuando una carga de trabajo experimenta un evento de fiabilidad que se aborda mediante una respuesta activa ante incidentes, la urgencia puede crear presión para que los equipos de carga de trabajo eviten los controles de seguridad optimizados para el acceso de rutina.
Las actividades de resolución de problemas pueden hacer que el equipo desactive temporalmente los protocolos de seguridad, dejando un sistema ya estresado potencialmente expuesto a riesgos de seguridad adicionales. También existe el riesgo de que los protocolos de seguridad no se restablezcan rápidamente.
Las implementaciones detalladas de controles de seguridad, como asignaciones de control de acceso basadas en rol o reglas de firewall, introducen complejidad de configuración y confidencialidad, lo que aumenta la posibilidad de una configuración incorrecta. Mitigar este posible impacto en la fiabilidad mediante el uso de reglas amplias erosiona los tres principios de la arquitectura Confianza cero.
La aplicación de actualizaciones de lanzamientos de versiones o actualizaciones a bibliotecas de proveedores, como componentes o soluciones de terceros, puede potencialmente alterar el componente de destino y provocar no disponibilidad durante el cambio. Retrasar o evitar la aplicación de parches podría evitar los posibles riesgos de fiabilidad, pero deja al sistema desprotegido contra las amenazas en evolución.
La consideración anterior también se aplica al código de la carga de trabajo. Por ejemplo, se aplica al código de aplicación que utiliza bibliotecas y componentes antiguos. Si la actualización e implementación del código de la aplicación se considera un riesgo de fiabilidad sin mitigar, la aplicación queda expuesta a riesgos de seguridad adicionales con el tiempo.
Desventajas de Fiabilidad con respecto a Excelencia operativa
Tener una estrategia de supervisión integral para una carga de trabajo es una parte clave de la excelencia operativa. La introducción de componentes adicionales en una arquitectura para implementar patrones de diseño de fiabilidad da como resultado más orígenes de datos para administrar, lo que aumenta la complejidad de implementar el seguimiento distribuido y la observabilidad.
El uso de múltiples regiones para superar las restricciones de capacidad de recursos de una sola región o implementar una arquitectura activa/activa aumenta la complejidad de la administración operativa de la carga de trabajo. Esta complejidad se debe a la necesidad de administrar múltiples regiones y la necesidad de administrar la replicación de datos entre ellas.
A medida que una carga de trabajo se vuelve más sólida mediante la adición de componentes y patrones de fiabilidad, se necesita más tiempo para mantener los procedimientos operativos y la documentación de los artefactos.
La formación se vuelve más compleja a medida que aumenta el número de componentes de la carga de trabajo. Esta complejidad afecta el tiempo necesario para la incorporación y aumenta el conocimiento necesario para realizar un seguimiento de las hojas de ruta de los productos y la orientación a nivel de servicio.
Desventajas de Fiabilidad con respecto a Optimización de la experiencia
Hacer hincapié en pruebas rigurosas puede retrasar el lanzamiento de características de experiencia que son esenciales para su adopción.
La optimización de la fiabilidad puede exagerar la reducción de la complejidad, lo que resta prioridad a las características para experiencias de usuario más atractivas, como integraciones y componentes personalizados.
Compromiso entre confiabilidad y eficiencia en el desempeño
Los patrones de confiabilidad a menudo incorporan la replicación de datos para sobrevivir al mal funcionamiento de la réplica. La replicación introduce una latencia adicional para operaciones de escritura de datos confiables, lo que consume una parte del presupuesto de rendimiento para un usuario o flujo de datos específico.
La confiabilidad a veces emplea varias formas de equilibrio de recursos para distribuir o redistribuir la carga a las réplicas saludables. Un componente dedicado que se utiliza para equilibrar generalmente afecta el rendimiento de la solicitud o el proceso que se está equilibrando.
La distribución de componentes a través de límites geográficos o zonas de disponibilidad para sobrevivir a un impacto de alcance limitado introduce latencia de red en la comunicación entre los componentes que abarcan esos límites de disponibilidad.
Se utilizan procesos extensos para observar la salud de una carga de trabajo. Si bien el monitoreo es fundamental para la confiabilidad, la instrumentación puede afectar el rendimiento del sistema. A medida que aumenta la observabilidad, el rendimiento podría disminuir.
Las operaciones de escalamiento automático no son instantáneas y, por lo tanto, no pueden manejar de manera confiable un aumento repentino y dramático en la demanda que no se puede controlar ni suavizar. Por lo tanto, el aprovisionamiento excesivo a través de instancias más grandes o de más instancias es una táctica de confiabilidad crítica para tener en cuenta el desfase entre la señal de demanda y la creación de la oferta. La capacidad no utilizada contradice los objetivos de eficiencia en el rendimiento.
A veces, un componente no se puede escalar en respuesta a la demanda, y esa demanda no es totalmente predecible. El uso de instancias de gran tamaño para cubrir el peor de los casos genera un desperdicio de aprovisionamiento excesivo en situaciones que están fuera de ese caso de uso.