Patrón ambassador

Azure

Crea servicios auxiliares que envían solicitudes de red en nombre de una aplicación o servicio de consumidor. Un servicio de embajador puede considerarse como un proxy fuera de proceso que se encuentra en una ubicación conjunta con el cliente.

Este patrón puede ser útil para descargar tareas comunes de conectividad de cliente, como la supervisión, el registro, el enrutamiento, la seguridad (como TLS) y los patrones de resistencia de una manera independiente del lenguaje. A menudo se usa con aplicaciones heredadas u otras aplicaciones que son difíciles de modificar, con el fin de ampliar sus funcionalidades de red. También puede permitir que un equipo especializado implemente esas características.

Contexto y problema

Las aplicaciones basadas en la nube resistentes requieren características como la interrupción del circuito, el enrutamiento, la medición y la supervisión, y la capacidad de realizar actualizaciones de configuración relacionadas con la red. Puede ser difícil o imposible actualizar aplicaciones heredadas o bibliotecas de código existentes para agregar estas características, ya que el equipo de desarrollo ya no mantiene el código o no puede modificarlo fácilmente.

Las llamadas de red también pueden requerir una configuración sustancial para la conexión, la autenticación y la autorización. Si estas llamadas se usan en varias aplicaciones, creadas con varios lenguajes y marcos, las llamadas deben configurarse para cada una de estas instancias. Además, es posible que un equipo central de su organización deba administrar la funcionalidad de red y seguridad. Con una base de código grande, puede ser arriesgado que ese equipo actualice el código de aplicación con el que no está familiarizado.

Solución

Coloque marcos de cliente y bibliotecas en un proceso externo que actúe como proxy entre la aplicación y los servicios externos. Implemente el proxy en el mismo entorno de host que la aplicación para permitir el control sobre el enrutamiento, la resistencia, las características de seguridad y evitar restricciones de acceso relacionadas con el host. También puede usar el patrón de embajador para estandarizar y ampliar la instrumentación. El proxy puede supervisar las métricas de rendimiento, como la latencia o el uso de recursos, y esta supervisión se produce en el mismo entorno host que la aplicación.

Las características que se descargan en el embajador se pueden administrar independientemente de la aplicación. Puede actualizar y modificar el embajador sin alterar la funcionalidad heredada de la aplicación. También permite a los equipos independientes especializados implementar y mantener las características de seguridad, redes o autenticación que se han movido al embajador.

Los servicios ambassador se pueden implementar como sidecar para acompañar el ciclo de vida de una aplicación o servicio que consume. Como alternativa, si un embajador es compartido por varios procesos independientes en un host común, se puede implementar como demonio o servicio de Windows. Si el servicio de consumo está en contenedor, el embajador debe crearse como un contenedor independiente en el mismo host, con los vínculos adecuados configurados para la comunicación.

Problemas y consideraciones

• El proxy agrega cierta sobrecarga de latencia. Considere si una biblioteca cliente, invocada directamente por la aplicación, es un enfoque mejor.
• Tenga en cuenta el posible impacto de incluir características generalizadas en el proxy. Por ejemplo, el embajador podría controlar los reintentos, pero eso podría no ser seguro a menos que todas las operaciones sean idempotentes.
• Considere un mecanismo para permitir que el cliente pase algún contexto al proxy y vuelva al cliente. Por ejemplo, incluya encabezados de solicitud HTTP para no participar en el reintento o especificar el número máximo de veces que se va a reintentar.
• Tenga en cuenta cómo empaquetará e implementará el proxy.
• Considere si se debe usar una única instancia compartida para todos los clientes o una instancia de para cada cliente.

Cuándo usar este patrón

Use este patrón cuando:

• Es necesario crear un conjunto común de características de conectividad de cliente para varios lenguajes o marcos.
• Es necesario descargar problemas de conectividad de cliente transversales a los desarrolladores de infraestructura u otros equipos más especializados.
• Es necesario admitir los requisitos de conectividad de la nube o del clúster en una aplicación heredada o una aplicación que sea difícil de modificar.

Este patrón puede no ser adecuado:

• Cuando la latencia de la solicitud de red es crítica. Un proxy presenta cierta sobrecarga, aunque es mínima y, en algunos casos, esto puede afectar a la aplicación.
• Cuando un solo idioma consume las características de conectividad de cliente. En ese caso, una mejor opción podría ser una biblioteca cliente que se distribuye a los equipos de desarrollo como un paquete.
• Cuando las características de conectividad no se pueden generalizar y requieren una integración más profunda con la aplicación cliente.

Diseño de cargas de trabajo

Un arquitecto debe evaluar cómo se puede usar el patrón Ambassador en el diseño de su carga de trabajo para abordar los objetivos y principios descritos en los pilares de Azure Well-Architected Framework. Por ejemplo:

Fundamento	Cómo apoya este patrón los objetivos de los pilares
Las decisiones de diseño de la fiabilidad ayudan a que la carga de trabajo sea resistente a los errores y a garantizar que se recupere a un estado de pleno funcionamiento después de que se produzca un error.	El punto de mediación de comunicaciones de red facilitado por este patrón ofrece una oportunidad para agregar patrones de confiabilidad a la comunicación de red, como reintento o almacenamiento en búfer. - RE:07 Autopreservación
Las decisiones de diseño de seguridad ayudan a garantizar la confidencialidad, integridad y disponibilidad de los datos y sistemas de su carga de trabajo.	Este patrón proporciona una oportunidad para aumentar la seguridad en las comunicaciones de red que el cliente no pudo controlar directamente. - SE:06 Controles de red - Cifrado SE:07

Al igual que con cualquier decisión de diseño, hay que tener en cuenta las ventajas y desventajas con respecto a los objetivos de los otros pilares que podrían introducirse con este patrón.

Ejemplo

En el diagrama siguiente se muestra una aplicación que realiza una solicitud a un servicio remoto a través de un proxy de embajador. El embajador proporciona enrutamiento, interrupción del circuito y registro. Llama al servicio remoto y, a continuación, devuelve la respuesta a la aplicación cliente:

Recursos relacionados

• Patrón Sidecar

Crea servicios auxiliares que envían solicitudes de red en nombre de una aplicación o servicio de consumidor. Un servicio de embajador puede considerarse como un proxy fuera de proceso que se encuentra en una ubicación conjunta con el cliente.

Este patrón puede ser útil para descargar tareas comunes de conectividad de cliente, como la supervisión, el registro, el enrutamiento, la seguridad (como TLS) y los patrones de resistencia de una manera independiente del lenguaje. A menudo se usa con aplicaciones heredadas u otras aplicaciones que son difíciles de modificar, con el fin de ampliar sus funcionalidades de red. También puede permitir que un equipo especializado implemente esas características.

Contexto y problema

Las aplicaciones basadas en la nube resistentes requieren características como la interrupción del circuito, el enrutamiento, la medición y la supervisión, y la capacidad de realizar actualizaciones de configuración relacionadas con la red. Puede ser difícil o imposible actualizar aplicaciones heredadas o bibliotecas de código existentes para agregar estas características, ya que el equipo de desarrollo ya no mantiene el código o no puede modificarlo fácilmente.

Las llamadas de red también pueden requerir una configuración sustancial para la conexión, la autenticación y la autorización. Si estas llamadas se usan en varias aplicaciones, creadas con varios lenguajes y marcos, las llamadas deben configurarse para cada una de estas instancias. Además, es posible que un equipo central de su organización deba administrar la funcionalidad de red y seguridad. Con una base de código grande, puede ser arriesgado que ese equipo actualice el código de aplicación con el que no está familiarizado.

Solución

Coloque marcos de cliente y bibliotecas en un proceso externo que actúe como proxy entre la aplicación y los servicios externos. Implemente el proxy en el mismo entorno de host que la aplicación para permitir el control sobre el enrutamiento, la resistencia, las características de seguridad y evitar restricciones de acceso relacionadas con el host. También puede usar el patrón de embajador para estandarizar y ampliar la instrumentación. El proxy puede supervisar las métricas de rendimiento, como la latencia o el uso de recursos, y esta supervisión se produce en el mismo entorno host que la aplicación.

Las características que se descargan en el embajador se pueden administrar independientemente de la aplicación. Puede actualizar y modificar el embajador sin alterar la funcionalidad heredada de la aplicación. También permite a los equipos independientes especializados implementar y mantener las características de seguridad, redes o autenticación que se han movido al embajador.

Los servicios ambassador se pueden implementar como sidecar para acompañar el ciclo de vida de una aplicación o servicio que consume. Como alternativa, si un embajador es compartido por varios procesos independientes en un host común, se puede implementar como demonio o servicio de Windows. Si el servicio de consumo está en contenedor, el embajador debe crearse como un contenedor independiente en el mismo host, con los vínculos adecuados configurados para la comunicación.

Problemas y consideraciones

• El proxy agrega cierta sobrecarga de latencia. Considere si una biblioteca cliente, invocada directamente por la aplicación, es un enfoque mejor.
• Tenga en cuenta el posible impacto de incluir características generalizadas en el proxy. Por ejemplo, el embajador podría controlar los reintentos, pero eso podría no ser seguro a menos que todas las operaciones sean idempotentes.
• Considere un mecanismo para permitir que el cliente pase algún contexto al proxy y vuelva al cliente. Por ejemplo, incluya encabezados de solicitud HTTP para no participar en el reintento o especificar el número máximo de veces que se va a reintentar.
• Tenga en cuenta cómo empaquetará e implementará el proxy.
• Considere si se debe usar una única instancia compartida para todos los clientes o una instancia de para cada cliente.

Cuándo usar este patrón

Use este patrón cuando:

• Es necesario crear un conjunto común de características de conectividad de cliente para varios lenguajes o marcos.
• Es necesario descargar problemas de conectividad de cliente transversales a los desarrolladores de infraestructura u otros equipos más especializados.
• Es necesario admitir los requisitos de conectividad de la nube o del clúster en una aplicación heredada o una aplicación que sea difícil de modificar.

Este patrón puede no ser adecuado:

• Cuando la latencia de la solicitud de red es crítica. Un proxy presenta cierta sobrecarga, aunque es mínima y, en algunos casos, esto puede afectar a la aplicación.
• Cuando un solo idioma consume las características de conectividad de cliente. En ese caso, una mejor opción podría ser una biblioteca cliente que se distribuye a los equipos de desarrollo como un paquete.
• Cuando las características de conectividad no se pueden generalizar y requieren una integración más profunda con la aplicación cliente.

Diseño de cargas de trabajo

Un arquitecto debe evaluar cómo se puede usar el patrón Ambassador en el diseño de su carga de trabajo para abordar los objetivos y principios descritos en los pilares de Azure Well-Architected Framework. Por ejemplo:

Fundamento	Cómo apoya este patrón los objetivos de los pilares
Las decisiones de diseño de la fiabilidad ayudan a que la carga de trabajo sea resistente a los errores y a garantizar que se recupere a un estado de pleno funcionamiento después de que se produzca un error.	El punto de mediación de comunicaciones de red facilitado por este patrón ofrece una oportunidad para agregar patrones de confiabilidad a la comunicación de red, como reintento o almacenamiento en búfer. - RE:07 Autopreservación
Las decisiones de diseño de seguridad ayudan a garantizar la confidencialidad, integridad y disponibilidad de los datos y sistemas de su carga de trabajo.	Este patrón proporciona una oportunidad para aumentar la seguridad en las comunicaciones de red que el cliente no pudo controlar directamente. - SE:06 Controles de red - Cifrado SE:07

Al igual que con cualquier decisión de diseño, hay que tener en cuenta las ventajas y desventajas con respecto a los objetivos de los otros pilares que podrían introducirse con este patrón.

Ejemplo

En el diagrama siguiente se muestra una aplicación que realiza una solicitud a un servicio remoto a través de un proxy de embajador. El embajador proporciona enrutamiento, interrupción del circuito y registro. Llama al servicio remoto y, a continuación, devuelve la respuesta a la aplicación cliente:

Recursos relacionados

• Patrón Sidecar