Patrones de diseño en la nube que admiten la excelencia operativa
Al diseñar arquitecturas de cargas de trabajo, debe usar patrones del sector que aborden desafíos comunes. Los patrones pueden ayudarle a compensar intencionadamente las cargas de trabajo y optimizar el resultado deseado. También pueden ayudar a mitigar los riesgos que se originan en problemas específicos, lo que puede afectar a la confiabilidad, la seguridad, el rendimiento y el costo. Dado que las operaciones se reducen en todas esas áreas, los riesgos afectarán finalmente a las operaciones de carga de trabajo. Estos patrones están respaldados por la experiencia real, están diseñados para modelos operativos y de escala en la nube, y son inherentemente independientes del proveedor. El uso de patrones conocidos como una manera de estandarizar el diseño de la carga de trabajo es un componente de excelencia operativa.
Muchos patrones de diseño admiten directamente uno o varios pilares de arquitectura. Los patrones de diseño que admiten el pilar de excelencia operativa usan topologías que proporcionan una base sólida para las prácticas de implementación seguras y facilitan la evolución de la arquitectura a lo largo del tiempo, los escenarios de migración y la observabilidad.
Patrones de diseño para la excelencia operativa
En la tabla siguiente se resumen los patrones de diseño en la nube que admiten los objetivos de excelencia operativa.
| Patrón | Resumen |
|---|---|
| Anti-Corruption Layer | Protege los nuevos componentes del sistema de las opciones de comportamiento o implementación de los sistemas heredados mediante la adición de una capa de mediador a las interacciones de proxy entre componentes heredados y nuevos. Este patrón ayuda a garantizar que el nuevo diseño de componentes permanezca influido por implementaciones heredadas que podrían tener diferentes modelos de datos o reglas de negocio al integrar con estos sistemas heredados. El patrón es especialmente útil en las migraciones graduales del sistema. Reduce la deuda técnica en nuevos componentes y sigue admitiendo componentes existentes. |
| Organización | Coordina el comportamiento de los componentes distribuidos autónomos en una carga de trabajo mediante la comunicación descentralizada controlada por eventos. Este patrón puede ser útil cuando se espera actualizar o reemplazar los servicios con frecuencia durante el ciclo de vida de una carga de trabajo. Dado que los componentes distribuidos son autónomos, puede modificar la carga de trabajo con un cambio general menor en el sistema. |
| Compute Resource Consolidation | Optimiza y consolida los recursos de proceso aumentando la densidad. Este patrón combina varias aplicaciones o componentes de una carga de trabajo en una infraestructura compartida. La consolidación conduce a una plataforma de proceso más homogéneo, que puede simplificar la administración y la observabilidad, reducir enfoques dispares para las tareas operativas y reducir la cantidad de herramientas necesarias. |
| Sellos de implementación | Proporciona un enfoque para publicar una versión específica de una aplicación y su infraestructura como una unidad controlada de implementación, en función de la suposición de que las mismas o diferentes versiones se implementarán simultáneamente. Este patrón se alinea con los objetivos de infraestructura inmutables, admite modelos de implementación avanzados y puede facilitar prácticas de implementación seguras. |
| External Configuration Store | Extrae la configuración de un servicio externo a la aplicación para admitir actualizaciones dinámicas en los valores de configuración sin necesidad de cambios de código ni reimplementación de la aplicación. Esta separación de la configuración de la aplicación del código de aplicación admite la configuración específica del entorno y aplica el control de versiones a los valores de configuración. Los almacenes de configuración externos también son un lugar común para administrar las marcas de características para habilitar prácticas de implementación seguras. |
| Gateway Aggregation | Simplifica las interacciones de cliente con la carga de trabajo mediante la agregación de llamadas a varios servicios back-end en una sola solicitud. Esta topología permite que la lógica de back-end evolucione independientemente de los clientes, lo que le permite cambiar las implementaciones de servicio encadenadas o incluso los orígenes de datos, sin necesidad de cambiar los puntos de contacto del cliente. |
| Gateway Offloading | Descarga el procesamiento de solicitudes en un dispositivo de puerta de enlace antes y después de reenviar la solicitud a un nodo back-end. Agregar una puerta de enlace de descarga al proceso de solicitud le permite administrar la configuración y el mantenimiento de la funcionalidad descargada desde un solo punto en lugar de administrarla desde varios nodos. |
| Gateway Routing | Enruta las solicitudes de red entrantes a varios sistemas back-end en función de las intenciones de solicitud, la lógica de negocios y la disponibilidad del back-end. El enrutamiento de puerta de enlace permite desacoplar las solicitudes de los back-end, lo que a su vez permite a los back-end admitir modelos de implementación avanzados, transiciones de plataforma y un único punto de administración para la resolución de nombres de dominio y el cifrado en tránsito. |
| Health Endpoint Monitoring | Proporciona una manera de supervisar el estado o el estado de un sistema mediante la exposición de un punto de conexión diseñado específicamente para ese fin. La estandarización de los puntos de conexión de mantenimiento que se van a exponer y el nivel de análisis en los resultados, en toda la carga de trabajo puede ayudarle a evaluar los problemas. |
| Puente de mensajería | Proporciona un intermediario para habilitar la comunicación entre sistemas de mensajería que, de lo contrario, no son compatibles debido al protocolo o formato. Esta desacoplamiento proporciona flexibilidad al realizar la transición de la tecnología de mensajería y eventos dentro de la carga de trabajo o cuando tiene requisitos heterogéneos de dependencias externas. |
| Publicador y suscriptor | Desacopla los componentes de una arquitectura reemplazando la comunicación directa de cliente a servicio o cliente a servicios por comunicación a través de un agente de mensajes intermedio o un bus de eventos. Esta capa de direccionamiento indirecto puede permitirle cambiar de forma segura la implementación en el lado publicador o suscriptor sin necesidad de coordinar los cambios en ambos componentes. |
| Cuarentena | Garantiza que los recursos externos cumplan un nivel de calidad acordado por el equipo antes de autorizarlos a consumirlos en la carga de trabajo. La automatización y la coherencia de estas comprobaciones forman parte del ciclo de vida de desarrollo de software de la carga de trabajo y de las prácticas de implementación seguras (SDP). |
| Sidecar | Amplía la funcionalidad de una aplicación mediante la encapsulación de tareas no básicas o transversales en un proceso complementario que existe junto con la aplicación principal. Este patrón proporciona un enfoque para implementar flexibilidad en la integración de herramientas que podría mejorar la observabilidad de la aplicación sin necesidad de que la aplicación tome dependencias de implementación directas. Permite que la funcionalidad sidecar evolucione de forma independiente y se mantenga independientemente del ciclo de vida de la aplicación. |
| Fig Strangler | Proporciona un enfoque para reemplazar sistemáticamente los componentes de un sistema en ejecución por nuevos componentes, a menudo durante una migración o modernización del sistema. Este patrón proporciona un enfoque de mejora continua, en el que se prefiere un reemplazo incremental con pequeños cambios a lo largo del tiempo, en lugar de cambios sistémicos grandes que son más peligrosos de implementar. |
Pasos siguientes
Revise los patrones de diseño en la nube que admiten los otros pilares de Azure Well-Architected Framework: