Header Ads Widget

Ticker

6/recent/ticker-posts

Puertas de enlace API a la arquitectura de microservicios directos

 

API Gateway para dirigir la arquitectura de microservicios nordic apis

En una época en la que miles de dispositivos interactúan con microservicios y servidores impulsados ​​por API, una puerta de enlace API puede actuar como un único punto de entrada a la arquitectura interna, una opción popular para los desarrolladores, ya que aumenta la seguridad, mejora la experiencia del usuario y ayuda a que los ecosistemas prosperen.

En este artículo, discutimos qué es una puerta de enlace API, los beneficios y los inconvenientes de dicho sistema, las diferencias entre las puertas de enlace API y la gestión de API, y cómo implementar una puerta de enlace API en la economía API moderna.

¿Qué es una puerta de enlace API?

Una puerta de enlace API es una interfaz singular que maneja una variedad de solicitudes a servidores internos. El término se ha aplicado a varios  flujos arquitectónicos , pero en su forma más simple, una puerta de enlace API puede actuar como:

  • Filtrar el tráfico entrante desde dispositivos dispares: web, móvil, nube, B2B, servicios web, etc.
  • capa de punto de entrada único que puede exponer varias API, microservicios y / o máquinas virtuales en el servidor de aplicaciones del proveedor,
  • oferta común dentro de las soluciones de gestión de API ,
  • enrutador para la limitación de la velocidad de API  y la gestión del tráfico,
  • mecanismo de seguridad , con autenticación, registro y más.

Cuando un usuario ingresa a una puerta de enlace API, puede provenir de una variedad de dispositivos dispares. Pueden requerir una variedad de respuestas a su gran variedad de consultas. La puerta de enlace unifica estas solicitudes y presenta una interfaz en la que la entidad solicitante puede usar casi cualquier sistema, navegador o cliente, y administrar para obtener lo que necesita.

API Gateway visualización-flujo-arquitectura-nordic-apis

Diferencia entre API Gateways y API Management

Vale la pena tomarse un momento para discutir las soluciones de administración de API , aunque solo sea para diferenciar las dos. Si bien ciertamente hay algunos cruces, las puertas de enlace de API y la gestión de API son en realidad una comparación de manzanas y naranjas.

Las puertas de enlace de API crean una barrera entre los clientes solicitantes externos y las API internas que vinculan microservicios dispares en una arquitectura unificada . La gestión de API, por otro lado, se centra más en un alcance más amplio. Mientras que una puerta de enlace API es simplemente un método de redirección y filtración del tráfico de terceros, las soluciones de administración de API manejan esto, así como los análisis, los datos comerciales, los servicios de proveedores adjuntos y la implementación del control de versiones.

La administración de API puede abarcar puertas de enlace de API; después de todo, una suite centrada en la administración no valdría la pena sin ofrecer dicha característica. Sin embargo, es importante delinear los dos, ya que a menudo (erróneamente) se los denomina sinónimos.

En resumen, una puerta de enlace de API es un componente de una solución de gestión de API completa.

Lea también: Cómo controlar la identidad del usuario en microservicios

6 beneficios de una puerta de enlace API

La integración de una puerta de enlace API puede llevar mucho tiempo, pero en última instancia, vale la pena el tiempo y los recursos. Para la mayoría de los casos de uso, la implementación de una puerta de enlace API otorgará una cantidad tan sustancial de beneficios al ecosistema que vale la pena los relativamente pocos inconvenientes.

1: Separación de la capa de aplicación y las partes solicitantes

Uno de los mayores beneficios de tal implementación es el hecho de que la puerta de enlace de API por diseño separa las particiones de microservicios dentro de la API de los usuarios de esa API. Esta distancia aumenta la seguridad y se hace de tal manera que, si bien los dos reinos están separados, la relación sigue siendo fundamentalmente la misma.

2: aumenta la simplicidad para el consumidor

Al presentar a los usuarios externos una interfaz única y unificada para un grupo de sub-API y sistemas, los microservicios se pueden dividir en múltiples derivaciones, cada una con funciones, servidores, soluciones de seguridad e implementaciones específicas, sin ser transparentes.

3: mejora el desarrollo y aumenta la carga del servidor

La segregación de la funcionalidad y el propósito no solo agiliza el desarrollo al enfocar el talento del equipo donde se puede usar mejor, sino que también reduce la carga del servidor al separar las funciones comunes y no comunes. Una función común puede recibir miles de solicitudes pequeñas al día, mientras que una función poco común puede presentar solo unas pocas, pero si las pocas solicitudes requieren más ancho de banda y recursos del servidor que muchas, segregarlas beneficiará la funcionalidad de todo el sistema.

4: Zona de amortiguamiento contra ataques

Como la ingeniería inversa de las API generalmente se lleva a cabo cuando un servicio está expuesto, la segregación de estos servidores hace que sea más difícil eliminarlos o manipularlos. Al separarlos, crea una especie de zona de amortiguación , donde si un servicio se ve comprometido, solo ese servicio se verá afectado.

Para el usuario, sin embargo, esto pasa desapercibido: la puerta de enlace en sí misma sirve como una capa de abstracción, evitando que el usuario sea consciente de esta partición. La única diferencia que puede experimentar un usuario es la capacidad de realizar múltiples solicitudes en una sola solicitud unificada, una experiencia que es solo de naturaleza positiva, que reduce la carga de uso del usuario y cambia la lógica de múltiples llamadas (y el procesamiento relevante energía requerida) desde el cliente hasta la puerta de enlace.

5: Atienda a clientes específicos para mejorar la UX

A diferencia de las llamadas unificadas que brindan los servicios segregados cuando se unifican en una puerta de enlace, donde la evidencia está en la llamada, el mejor beneficio de este sistema es uno que el usuario nunca verá. Al segregar microservicios en varios portales y filtrar el tráfico a través de una puerta de enlace, el desarrollador de API puede proporcionar con mayor precisión la mejor API para cada cliente y caso de uso.

Tutorial: escribir microservicios en Go

Cuando un usuario realiza una solicitud, no tiene que recorrer miles de líneas de documentación para encontrar la llamada específica; simplemente mira la especificación de la API exacta proporcionada por la puerta de enlace y realiza su solicitud. El usuario nunca se dará cuenta de que hay más revisiones de la API que manejan diferentes funcionalidades, e incluso si de alguna manera se dan cuenta de esto, no se confundirán ni distraerán con funcionalidades adicionales e innecesarias.

Estos beneficios son especialmente importantes cuando se consideran las variaciones de la pila en la nube , donde las funciones y necesidades varían enormemente entre cada segmento de la población, y donde ciertos servicios pueden realizar más de mil llamadas por minuto.

6: Registre las métricas para anticipar el cambio

Finalmente, este enfoque brinda una oportunidad maravillosa en el ámbito de la analítica . Al segregar los servicios, rastrear los datos utilizados en esos servicios y ver qué partes de la red sufren más estrés, los desarrolladores pueden rastrear y comprender con mayor precisión los datos de métricas de API increíblemente importantes que a menudo pueden significar una amplia adopción o la muerte, dependiendo de cómo sea. usado.

Inconvenientes de una puerta de enlace API

Sin embargo, no se deje engañar: los inconvenientes del sistema de puerta de enlace API pueden ser importantes. Estos surgen directamente de la forma en que las puertas de enlace API manejan los datos y cómo interactúan con otros servicios. A diferencia de los problemas con los idiomas , las especificaciones de la documentación o los enfoques de arquitectura , los inconvenientes inherentes al enfoque de la puerta de enlace API no se pueden solucionar con una solución de terceros o con un simple ajuste.

En primer lugar, el enfoque de la puerta de enlace API presenta un enorme nivel de complejidad . Imagine una configuración básica de servidor API que proporciona un tiempo de actividad del 99,9% con un ancho de banda constante y una distribución del tráfico relativamente estable.

En tal configuración, la solicitud del cliente entraría en su red interna, se filtraría a través de una variedad de soluciones de seguridad, se pasaría a través de un equilibrador de carga y finalmente llegaría a un solo servidor para su procesamiento y respuesta. Este proceso se lleva a cabo increíblemente rápido, solo obstaculizado por la gran cantidad de dispositivos que pasan.

Ahora imagine una configuración utilizando el enfoque de puerta de enlace API. La solicitud ingresaría a la red interna a través de una puerta de enlace. En este punto, el tráfico se filtraría y pasaría a equilibradores de carga agrupados entre varios servidores o máquinas virtuales. Habría que analizar y cuantificar el tráfico en cuanto a dónde pertenece. Después de esto, el proceso se pasaría al servidor, que luego validaría que efectivamente puede llevar a cabo la llamada, lo que luego haría.

Esta complejidad crece exponencialmente: tener máquinas lógicas o virtuales para cada subconjunto de una API, especialmente una API unificada compuesta por diez o veinte funciones, aumenta no solo la sobrecarga de desarrollo y mantenimiento del sistema, sino también el tiempo que lleva procesar una petición.

Estos son los dos principales inconvenientes del enfoque de la puerta de enlace API:

  • Mayor complejidad derivada de la segregación de API;
  • Mayor tiempo de respuesta derivado de capas adicionales de comunicación.
Asegurando-la-fortaleza-API-blog-post-CTA-01

Gateways como característica de seguridad

La seguridad es un gran problema en el espacio de las API: ninguna discusión sobre una nueva función en el espacio de las API estaría completa sin abordar los posibles beneficios y desventajas frente a la seguridad.

La buena noticia es que implementar una puerta de enlace API es una de las mejores cosas que puede hacer por el perfil de seguridad de su API Al considerar la seguridad, hay un acrónimo fundamental utilizado por los profesionales de TI en todo el mundo: CIA . CIA significa Confidencialidad (la privacidad de la información), Integridad (garantizar que los datos no se modifiquen ilícitamente) y Disponibilidad (garantizar que los datos sean accesibles cuando se soliciten).

Las puertas de enlace API cumplen con la CIA de tres formas muy eficaces:

Confidencialidad

Al aislar los servidores en los que se protegen los datos privados, ya sea lógicamente a través de un servidor de puerta de enlace API o virtualmente a través de instancias de servidor segregadas, se garantiza la confidencialidad de los datos eliminando los principales métodos de ataque.

Sus servidores están diseñados para resistir intrusiones y evitar filtraciones de datos. Al separar los datos de los servidores frontales, está creando un punto de estrangulamiento en el que, incluso si se infringen los datos, puede controlar si los datos abandonan el servidor en primer lugar.

Integridad

En el enfoque de la puerta de enlace API, la integridad está asegurada como resultado de la forma en que se manejan los datos. Cuando los datos ingresan al ecosistema del servidor, cada servidor enruta las solicitudes y el tráfico a varios otros servidores y microservicios. A medida que estas solicitudes se examinan y se cumplen, los datos se mantienen todo el tiempo y se mantiene una especie de rastro en papel.

Es este mismo rastro en papel lo que garantiza la integridad de los datos, ya que existen múltiples puntos donde los datos se pueden compilar, verificar y registrar.

Disponibilidad

Uno de los mayores problemas en el espacio web es la disponibilidad. Desafortunadamente, hay grupos de personas que lo atacarán constantemente, probarán constantemente sus servidores. Afortunadamente, la puerta de enlace API proporciona una buena defensa contra esto.

Cuando las solicitudes mal formadas se filtran, no son manejadas por el mismo servidor que maneja la API y pueden rechazarse mientras las conexiones aprobadas mantienen su flujo de comunicación .

Esto se puede equilibrar aún más con soluciones de equilibrio de carga. Nivelar su puerta de enlace API en varios servidores y luego enrutar estos servidores a las arquitecturas de microservicios API internos crea una situación en la que un atacante puede embestir contra su servidor, ser rechazado y nadie se da cuenta.

Ejemplo del mundo real

Auth0, un desarrollador de autenticación de token y inicio de sesión único, publicó recientemente documentación que demuestra el concepto de puerta de enlace API en un ejemplo muy claro y fácil de entender. El ejemplo, que se muestra a continuación, es una puerta de enlace Node.js simple, que recibe y reenvía solicitudes HTTP a puntos finales internos, autentificándose en el camino utilizando JWT (JSON Web Tokens).

/* 
 * Parses the request and dispatches multiple concurrent requests to each
 * internal endpoint. Results are aggregated and returned.
 */
function serviceDispatch(req, res) {
    var parsedUrl = url.parse(req.url);

    Service.findOne({ url: parsedUrl.pathname }, function(err, service) {
        if(err) {
            logger.error(err);
            send500(res);
            return;
        }

        var authorized = roleCheck(req.context.authPayload.jwt, service);
        if(!authorized) {
            send401(res);
            return;
        }       

        // Fanout all requests to all related endpoints. 
        // Results are aggregated (more complex strategies are possible).
        var promises = [];
        service.endpoints.forEach(function(endpoint) {   
            logger.debug(sprintf('Dispatching request from public endpoint ' + 
                '%s to internal endpoint %s (%s)', 
                req.url, endpoint.url, endpoint.type));

            switch(endpoint.type) {
                case 'http-get':
                case 'http-post':
                    promises.push(httpPromise(req, endpoint.url, 
                        endpoint.type === 'http-get'));
                    break;
                case 'amqp':
                    promises.push(amqpPromise(req, endpoint.url));
                    break;
                default:
                    logger.error('Unknown endpoint type: ' + endpoint.type);
            }            
        });

        //Aggregation strategy for multiple endpoints.
        Q.allSettled(promises).then(function(results) {
            var responseData = {};

            results.forEach(function(result) {
                if(result.state === 'fulfilled') {
                    responseData = _.extend(responseData, result.value);
                } else {
                    logger.error(result.reason.message);
                }
            });

            res.setHeader('Content-Type', 'application/json');
            res.end(JSON.stringify(responseData));
        });
    }, 'services');
}

En este ejemplo, están ocurriendo algunas cosas. En primer lugar, cuando se recibe una solicitud, se procesa mediante la función serviceDispatch , que intenta hacer coincidir los datos solicitados de los servicios relevantes. La función service.endpoints.forEach luego envía solicitudes a puntos finales conocidos dentro de la red interna; en otras palabras, estas dos funciones comprenden el primer manejo del flujo de datos de la puerta de enlace API.

Después de esto, la API utiliza las funciones de resultados para agregar las respuestas devueltas a la puerta de enlace, momento en el que se canaliza la respuesta adecuada al usuario que la solicitó.

Conclusión

Hablando fundamentalmente, una puerta de enlace de API es quizás una de las herramientas más efectivas en el conjunto de herramientas de desarrollo de API moderno. Entre el equilibrio de carga, la partición de microservicios y los beneficios de seguridad otorgados por el sistema, los pocos inconvenientes que existen palidecen en comparación.

Eso no quiere decir, por supuesto, que las puertas de enlace API sean una fórmula mágica. Si un desarrollador solo usa una única función de API, la puerta de enlace de API es un esfuerzo inútil. Pero para los proveedores de API que utilizan dos o más enfoques o funciones básicas en su API, la puerta de enlace es una opción maravillosa y debe considerarse seriamente como una característica de diseño y seguridad.

Publicar un comentario

0 Comentarios