Header Ads Widget

Ticker

6/recent/ticker-posts

Las diferencias entre gateway, microgateway y service mesh

 Comparamos los beneficios y las desventajas de 3 estilos clave de administración de API

Las API son complejas. Cada componente sería complejo por sí solo, pero cuando estas API se comunican entre sí, esta complejidad solo se agrava. Agregue clientes externos y tendrá una intrincada red de bases de código de comunicación cruzada, caminos en competencia para obtener información y fuentes de verdad independientes.

En consecuencia, los proveedores han desarrollado muchas soluciones para ayudar a controlar estas complejidades. Algunos son muy eficaces, otros menos. Pero es de destacar que todos intentan resolver el problema central de las comunicaciones complejas entre capas de datos dispares.

Hoy, veremos tres soluciones principales: API Gateway , API Microgateway y Service Mesh . Cada una de estas soluciones ofrece un enfoque único y se puede aprovechar con gran efecto en escenarios y casos de uso específicos. Dicho esto, son muy particulares en sus aplicaciones, así como en su utilidad.

Puerta de enlace API

Una puerta de enlace API hace exactamente lo que parece: actúa como una puerta de enlace entre sus API y los clientes externos que solicitan servicios directamente. En lugar de que un cliente envíe una solicitud directamente a los servicios, la solicitud se envía a una puerta de enlace, que luego procesa la solicitud y la reenvía por la ruta adecuada.

Nginx lo resume claramente como tal:

“Una puerta de enlace API toma todas las llamadas API de los clientes y luego las enruta al microservicio apropiado con enrutamiento de solicitudes, composición y traducción de protocolos. Por lo general, maneja una solicitud invocando varios microservicios y agregando los resultados para determinar la mejor ruta. Se puede traducir entre protocolos web y protocolos no compatibles con la web que se utilizan internamente ... Un sitio de comercio electrónico puede utilizar una puerta de enlace API para proporcionar a los clientes móviles un punto final para recuperar todos los detalles del producto con una sola solicitud. Invoca varios servicios, como información de productos y reseñas, y combina los resultados ".

En esencia, una puerta de enlace API sirve como interfaz central para todas las comunicaciones externas. Esto es especialmente importante con los microservicios. En el paradigma de microservicios, la "red de servicios" puede estar formada por una cantidad ridícula de microservicios con nombres diferentes con diferentes ubicaciones, propiedades y métodos: una puerta de enlace API está destinada a aliviar el peso que dicha red puede agregar a las interacciones del cliente.

En la práctica, las puertas de enlace a menudo pueden admitir funciones mucho más avanzadas que el enrutamiento simple. Los esquemas de autenticación sofisticados (incluidas la federación y la delegación) a menudo se manejan en el backend a través de una credencial de puerta de enlace administrada de forma centralizada. La validación y el filtrado de entrada generalmente ocurren en el nivel de la puerta de enlace, lo que puede ayudar a aliviar la necesidad de un código de verificación de contenido duplicado en cada elemento de microservicio. La recopilación de métricas puede ocurrir en la puerta de entrada para métricas comparativas. La puerta de enlace puede incluso transformar tanto las solicitudes como las respuestas, ya que funciona como la primera capa de la red a la que llega la solicitud antes de que se lleve internamente. En esencia, un Gateway puede tomar una amplia variedad de formas y funciones y, en última instancia, es una poderosa primera línea de interacción.

Leer más:  ¿Qué es una puerta de enlace API?

Beneficios e inconvenientes

Las puertas de enlace API ofrecen una ejecución e interacción más sencillas que otras metodologías. En esencia, API Gateway es una especie de "API de API" y, como tal, los clientes solo necesitan hablar con un único punto final. Todo lo demás se maneja y resuelve internamente mediante esta única fuente de verdad, lo que significa que se puede enfocar la puerta de enlace cuando ocurre un error.

Tener un solo centro de transporte y enfoque también significa que la red de microservicios en general generalmente cuenta con latencias más bajas, como la validación de entrada, el equilibrio de carga y otros sistemas similares no tienen que replicarse localmente: todo se maneja en un solo lugar por un punto final único. Esto también significa que se pueden emplear alcances limitados y específicos para enviar datos a otros puntos finales y sistemas internos por la puerta de enlace, mejorando la eficiencia del sistema en general de manera sustancial.

Al utilizar una puerta de enlace, las API también pueden aprovechar una mayor seguridad. Debido a que el único punto final expuesto es el punto de entrada de la puerta de enlace, las API internas se ocultan y se vuelven inexplorables. Si bien este no es un método perfecto para la seguridad, dificulta que los atacantes organicen una expedición efectiva a la arquitectura y estructura de su red.

Una puerta de enlace también puede hacer que una API sea más amigable dentro de una colección más amplia de API. Debido a que la interacción es, en última instancia, mucho más simple, las API recopiladas que se muestran al usuario final son necesariamente menos problemáticas de manejar y, como tal, representan un aumento significativo en la experiencia positiva del usuario.

Además, este enfoque ofrece mejores métricas, ya que todo se puede desglosar muy bien en una sola fuente de falla. Los problemas pueden aislarse eficazmente en un solo nodo, función o sistema de transporte y, como tales, pueden repetirse y resolverse de forma más eficaz y rápida.

Sin embargo, todo esto agrega complejidad al sistema, y ​​este es un inconveniente importante para las puertas de enlace en general. Si bien este enfoque simplifica las redes ya complejas, las API simples de un solo punto final no tienen mucha complejidad en el otro lado de la escala. En esencia, sin tener la necesidad de adoptar una puerta de enlace, la puerta de enlace en sí puede volverse problemática.

Relacionado: ¿Debería crear una puerta de enlace API internamente?

Microgateways API

Las puertas de enlace monolíticas pueden hacer bastante, pero en esencia, tienen una función central única: exponen los puntos finales de la API a clientes externos. Sin embargo, las colecciones de microservicios hacen más que solo hablar externamente: también hablan internamente de manera bastante prolija y, como tales, requieren facilitación para ese proceso de comunicación.

APIfriends lo define como tal :

“Uno de los principios de una estrategia de microservicios exitosa es el cumplimiento de la Ley de Conway, que da como resultado una organización donde hay equipos independientes que crean microservicios independientes. Esto presenta desafíos para los operadores y las personas de seguridad que desean un control y una gobernanza centralizados para el tráfico de API que fluye dentro de la organización. Aquí es donde un microgateway API es útil. Un microgateway API es un proxy que se encuentra cerca del microservicio. Como resultado, proporciona valor a los desarrolladores al extraer gobernanza, descubrimiento, observabilidad y estabilidad en un agente reutilizable y da valor a los operadores al exponer el punto de aplicación de políticas (PEP) y los controles de seguridad en un panel de control centralizado ".

Esta exposición, y específicamente el control de la exposición, puede hacer que los catálogos de API interrelacionadas sean más complicados, pero en última instancia presentan un enfoque mucho más granular que otras soluciones que se ofrecen. Si bien, en principio, una puerta de enlace es mucho más simple, no ofrece una vista "a nivel del suelo" de todo el ecosistema de API, lo que puede llevar a una ofuscación bastante obstructiva; utilizar una micropuerta puede aliviar algo de esto.

Un concepto relacionado con las API Gateways, las API Microgateways están diseñadas completamente para la comunicación interna entre servicios. En esencia, un Microgateway es un proxy API distribuido y ligero que está diseñado para hacer cumplir las políticas y la lógica empresarial en o cerca de los puntos finales del servicio propiamente dichos. De hecho, es una puerta de enlace interna emparejada con una instancia de microservicio, lista para funcionar y proporcionar conexiones de comunicación. Por su propia naturaleza, son soluciones de baja latencia y tamaño reducido.

Relacionado:  Puertas de enlace API a la arquitectura de microservicios directos

Beneficios e inconvenientes

Las API Microgateways cuentan con una latencia más baja que las puertas de enlace normales, ya que no hay necesidad de una línea de solicitudes para "esperar su turno" en la cola de la funcionalidad de la puerta de enlace. Por supuesto, esto viene con la advertencia de que, en algunos casos, esto significa que tendrá duplicación de código en múltiples instancias de microservicio, lo que puede ser un problema si el código no es eficiente o no descarga funciones a otros puntos finales.

Dicho esto, si el código se desarrolla adecuadamente para admitir la estructuración inteligente, entonces su huella general será menor. Es posible que vea la duplicación de código, pero el código general necesario será significativamente menor por instancia, ya que no hay una "puerta de enlace monolítica". Este proceso, por su propia naturaleza, abstrae gran parte de la lógica de conexión fuera del sistema, aunque parte de esta lógica de conexión todavía se requiere para impulsar la interacción entre las puertas de enlace internamente.

Revisión:  Gloo, The Function Gateway

Mallas de servicio

Un Service Mesh es una capa de comunicación entre microservicios. En un diseño de este tipo, toda la comunicación de servicio a servicio tiene lugar en una malla de servicio diseñada para facilitar la comunicación de red utilizando metodologías estándar. Esto es similar a lo que a menudo se denomina "proxy de sidecar" o "puerta de enlace de sidecar".

Kasun Indrasiri señaló las siguientes características clave de una malla de servicios:

“En pocas palabras, un Service Mesh es una infraestructura de comunicación entre servicios. […] Un microservicio determinado no se comunicará directamente con los otros microservicios. Más bien, todas las comunicaciones de servicio a servicio se realizarán sobre un componente de software llamado service mesh (o proxy de sidecar) ".

Las mallas de servicio incluyen soporte integrado para funciones de red como resistencia, verificación de errores, descubrimiento de servicios, etc. Este enfoque permite a los desarrolladores dedicar su tiempo a trabajar en la lógica empresarial, en lugar de tener que trabajar en la lógica y los procesos de la red. Esto también significa que, dado que está utilizando lógica de red estandarizada, los Service Meshes son completamente independientes del idioma. En esencia, una malla de servicios se parece mucho a una micropuerta, pero se abstrae por completo de la lógica empresarial.

Lea también:  La necesidad de una capa de composición de API

Beneficios

Las mallas de servicio son una bestia interesante. En esencia, abstraen por completo las comunicaciones de red de la lógica empresarial API. En la práctica, esencialmente sirven como un cuidador de la red que también solicita la transferencia. La misma lógica que se deriva de los puntos finales de la lógica empresarial a las puertas de enlace se refleja aquí, que se deriva de la lógica de la red a las puertas de enlace más pequeñas.

Esto viene con algunas preocupaciones sobre la duplicación de código. Si bien esto es menos preocupante ya que la red utiliza métodos completamente estándar, también puede resultar en una situación en la que tenga muchos nodos de malla que no hacen tanto como lo haría una sola puerta de enlace. Dicho esto, la ganancia de usar métodos estándar es enorme: la red es la red y, como tal, la malla de servicios es completamente independiente del lenguaje por diseño.

La mayor ventaja aquí es el hecho de que la adopción de una malla de servicios permite a los desarrolladores centrarse en la lógica empresarial sin tener que preocuparse por la red; la lógica de la red es un hecho y no es necesario repetirla, liberando importantes recursos de desarrollo para la oferta comercial principal.

Conclusión

Cada una de estas implementaciones tiene una propuesta de valor muy buena, pero son casi independientes entre sí; aunque ciertamente cruzan parte del mismo territorio a veces, son muy particulares en los problemas que resuelven. En consecuencia, son más apropiados en una situación dada: los monolitos de puerta de enlace pueden ser muy efectivos, pero pueden ser abrumadores para implementaciones simples, por ejemplo.

Dicho esto, cualquiera de estas soluciones puede funcionar y son muy efectivas en lo que hacen. ¿Qué piensas? ¿Hay algunas advertencias importantes que nos perdimos? ¡Háganos saber a continuación!

Publicar un comentario

0 Comentarios