Header Ads Widget

Ticker

6/recent/ticker-posts

Revisión de Gloo, The Function Gateway

 


Internet funciona con complejidad: la suma total de la comunicación por Internet es en realidad una multitud de comunicaciones entre API dispares, cada una de las cuales transforma los datos de una manera única. Ninguna API puede hacer todo y, francamente, ninguna API debería intentarlo. Sin embargo, a medida que nos alejamos de esta visión monolítica del desarrollo, han aparecido nuevos problemas. Con tantas API, una capa de puerta de enlace híbrida para la comunicación se convierte en una propuesta interesante.

Gloo espera ser la solución a ese problema. En esta pieza, vamos a echar un vistazo a Gloo y ver qué hay debajo del capó. Echaremos una vista de alto nivel a su diseño y estructura, y veremos cómo encaja dentro del ecosistema API más amplio .

¿Qué hace Gloo?

El desarrollador detrás de Gloo, Solo , tiene un espíritu simple: las API deben construirse a partir de funciones , no de servicios. En otras palabras, cada llamada enrutada debe estar relacionada en términos de funciones y cómo esas funciones funcionan juntas, en lugar del conocimiento específico o especial que tiene cada API. La idea es que cuando las API se relacionan entre sí por lo que tienen en común y no por lo que difieren, se logra una mayor interfuncionalidad.

Gloo considera que las funciones son la “ unidad más pequeña de computación ”, es decir, la base más pequeña en la que ocurren los cálculos para el usuario. En consecuencia, al mover la relación entre las API al nivel de función y otorgar al usuario la capacidad de llamar a estas funciones, en lugar de API específicas, los usuarios, por lo tanto, tienen un control extremo sobre la forma en que se enrutan y manejan sus solicitudes.

Esto es posible en gran parte debido al hecho de que Gloo aprende sobre las API que enruta hacia arriba. Al aprender cómo estas API enrutan las funciones y qué hacen esas funciones, se crea una capa de comprensión. El cliente y el servidor ya no necesitan conocer el mismo idioma, tener la misma arquitectura, etc. - todo se puede portar a nivel de función. Gloo se refiere a esto como " enrutamiento a nivel de función ", que es todo un cambio de paradigma.

También debe tenerse en cuenta que Gloo se refiere a sí mismo como " completamente conectable ", lo que significa que cada módulo se puede configurar, cambiar y poner en nuevos flujos de trabajo. Esta configuración y extensibilidad significan que hay flexibilidad a través de un montón de diferentes tipos, servicios de descubrimiento y flujos de consultas del sistema.

Gloo en sí es una especie de API a la que se accede a través de una capa definida por el usuario. Esta es una relación algo invertida, por supuesto, ya que Gloo es realmente funciones de enrutamiento , no datos o llamadas. Por tanto, la configuración del usuario define dónde se produce este proceso y en qué mecanismo, sin interrumpir la funcionalidad principal.

Conceptos básicos

Gloo señala dos conceptos básicos en su documentación. El primero es Virtual Services , la idea de que las reglas de enrutamiento bajo un dominio específico pueden enrutar funciones y llamadas de forma transparente. El mecanismo que utiliza Gloo para esta función se conoce como comparador , que contiene datos sobre los tipos de llamadas y el destino nombrado al que está vinculado.

En segundo lugar a los servicios virtuales está el concepto de Upstream . Upstreams en Gloo determina los destinos de la ruta y es realmente el mecanismo de habilitación central para el enrutamiento a nivel de función subyacente a Gloo. Junto con los servicios virtuales, este proceso permite el enrutamiento funcional y, por lo tanto, la totalidad de las ofertas de Gloo.

Gloo se describe como "una puerta de enlace de aplicaciones híbrida de alto rendimiento, ampliable con complementos e independiente de la plataforma, construida sobre Envoy". Aquí hay una estructura de alto nivel de cómo funciona.

El caso de uso

La justificación de Gloo en el caso de uso es el hecho de que existe una brecha entre muchos enfoques de arquitectura de servicio. La mayoría de las empresas son esencialmente un entorno híbrido de microservicios, monolitos, sistemas sin servidor y API externas; hacer que funcionen en conjunto, y mucho menos abrirlos a usuarios externos, es extremadamente difícil.

Las puertas de enlace son buenas soluciones, pero incluso con las puertas de enlace, la responsabilidad de comprender la API de backend aún recae en el usuario, lo que requiere una gran dedicación de recursos de conocimiento y tiempo. En consecuencia, Gloo descubrió que el término medio se llenaría mejor con una solución personalizada en lugar de una prediseñada.

Gloo es esta solución personalizada. Al eliminar la responsabilidad del usuario de comprender y permitir una interacción mucho más granular, permite que el usuario tenga una experiencia personalizada , haciendo que sus comandos se dirijan a la función, no al nivel de API. Lo hace agregando las API de los servicios de backend y presentándolas al usuario como una única colección de funciones. Esencialmente, Gloo cambió la relación del proveedor a lo que se proporciona y se hizo cargo del enrutamiento de esas disposiciones de manera experta.

¿No es esto solo una puerta de entrada?

En esencia, sí, esto es solo una puerta de entrada, pero el enfoque es completamente diferente. La mayoría de las puertas de enlace son lo que dice en la lata: una puerta de entrada a API adicionales. En el caso de Gloo, este enrutamiento se realiza a nivel de función. Si bien sí, es justo decir que es una "puerta de enlace" en el sentido de que llena ese nicho que generalmente realiza una puerta de enlace, lo hace con una capa de abstracción a nivel de función que permite el enlace de una tonelada de fuentes dispares. En esencia, esta es una API para API.

En muchos sentidos, esto es casi similar al enfoque de backend para frontends . En ese enfoque, las experiencias de múltiples usuarios se conectan a través de una única API a varias API de backend; en este enfoque, sin embargo, varias funciones se conectan a través de una única API a varias API externas.

Enviado

Dado que Gloo toma prestado mucho de su Envoy de implementación de capa secundaria , merece cierta discusión. Envoy es esencialmente un proxy distribuido , que le permite combinar contenido en lo que ellos denominan el "plano de datos universal". Esto crea una especie de malla de servicios, uniendo un montón de API en lugar de forzar a cada sistema a enrutar a una única API a la vez.

Envoy es bastante poderoso en sí mismo, pero esa sería su propia pieza. Solo tenga en cuenta que Envoy es autónomo, de alto rendimiento y orientado al uso de poca memoria. Es compatible con HTTP / 2 y GRPC , e integra sistemas avanzados de equilibrio de carga, como limitación de velocidad global y reintentos automáticos, en su base de código.

Criterios de diseño

Gloo tiene algunos principios de diseño básicos establecidos que ayudan a contextualizar exactamente lo que está sucediendo aquí. En primer lugar, Gloo está claramente centrado en el usuario : la capacidad de enrutar funciones en lugar de enrutar la funcionalidad a una API se centra enormemente en el usuario y cambia todo el paradigma de la relación usuario-recurso a un desequilibrio a favor del usuario.

Gloo también se centra en la idea de mejora de proxy . En este enfoque, Envoy se utiliza para manipular la solicitud en la forma necesaria, incluido el cambio del patrón de transformación de solicitud y respuesta. Estas transformaciones pueden incluir diversos cambios en los filtros lambda de AWS, los filtros de funciones de Google y más. Los filtros en este nivel de función permiten un verdadero "pez babel" de API.

La extensibilidad también se analiza en profundidad en la documentación. Desde cero, Gloo está diseñado para ser enchufable y modular . Al permitir que el usuario tenga tal personalización, el sistema en cuestión es mucho más flexible y permite una gama más amplia de funcionalidad e interoperabilidad entre diferentes sistemas.

Con ese fin, Gloo también se construyó con la usabilidad como foco. Hacer que los proyectos sean fáciles de consumir es una parte de eso, pero hacer que sean naturalmente fáciles de extender es la otra cara de la moneda. Se desarrollaron varias herramientas para ayudar en esto, que incluyen:

  • glooctl : una herramienta de línea de comandos que permite una poderosa transformación en funciones y llamadas.
  • TheTool : un excelente sistema de automatización que brinda a los usuarios la capacidad de automatizar gran parte de su trabajo dentro de Gloo y en todos los servicios integrados.
  • Soporte como controlador de entrada de Kubernetes de forma predeterminada.

Todo esto finalmente se suma a un servicio que fue claramente diseñado con la mentalidad de “usuario primero” en mente.

El flujo de trabajo básico

El flujo de trabajo básico de Gloo es relativamente simple y se desarrolla en cuatro pasos generales . Estos pasos pueden, al menos en teoría, realizarse en cualquier orden, pero es mejor hacerlo en el orden que se describe en la documentación para poder solucionar problemas en caso de que algo salga mal.

  1. Implementa Gloo . En primer lugar, debe implementar Goo. Esto se puede hacer como un pod de Kubernetes , como un contenedor de Docker , en un servidor: Gloo puede ejecutarse prácticamente en cualquier lugar con facilidad.
  2. Implemente servicios de descubrimiento . A continuación, debe implementar los servicios de descubrimiento de Goo que ayudan a configurar automáticamente la configuración de Gloo. La documentación considera que este es un paso opcional, pero si no lo haces, solo tendrás más trabajo en el futuro.
  3. Apoderado. A continuación, implemente un proxy Envoy con su configuración apuntando a Gloo.
  4. Enrutamiento . Finalmente, debe configurar una ruta y un flujo ascendente para que Gloo enrute sus funciones. Desde aquí, básicamente puede usar Gloo para todas sus necesidades de enrutamiento de funciones.

Advertencias

Dicho todo esto, Gloo no siempre es la mejor solución. En las API que no necesitan conexiones de funciones externas, Gloo es esencialmente un sistema desperdiciado. La naturaleza de valor agregado de Gloo está fuera de toda duda, pero requiere la necesidad de trasladar sus funciones a API externas; si su API no llega a API externas, entonces realmente no hay razón para integrarse.

Además, es posible que Gloo no sea apropiado en entornos de empresa a empresa. En esos casos, las API que se establecen para su uso se establecen normalmente por contrato y, como tal, sus interacciones deben ser limitadas y específicas. Por supuesto, existe la advertencia de que, a menudo, los contratos establecen objetivos finales, no la forma en que se debe lograr ese objetivo, y en esos casos, Gloo es más que apropiado.

Conclusión

Gloo es una herramienta poderosa en el sentido de que satisface un requisito muy específico y lo hace con una mentalidad de usuario primero. Cada proveedor debe determinar si la implementación es adecuada o no para las necesidades de una API, pero Gloo definitivamente debe considerarse como parte de un conjunto de herramientas más grande.

¿Has usado Gloo? ¿Cuáles fueron tus pensamientos? ¿Lo recomendaría a otros? Háganos saber a continuación.



Publicar un comentario

0 Comentarios