Mejores prácticas para gestionar API internas

NGINX | 02 de septiembre de 2020

Karthik KrishnaswamyDirector de Marketing de Producto | F5

Algunas API orientadas al consumidor están tan extendidas que se han convertido en nombres conocidos por todos —como Google Maps y Stripe—, pero las API internas son el verdadero motor de la economía de las API.

Las API internas —es decir, aquellas que solo están disponibles para los clientes y desarrolladores de una organización— son un pilar fundamental de los esfuerzos de transformación digital de las empresas. La creación de API internas suele ser el primer paso en el desarrollo de productos y servicios digitales. De hecho, según el reciente estudio de IDC, «Las API: los factores determinantes del éxito o el fracaso de los negocios digitales», facilitar la integración interna de aplicaciones y productos es una de las principales prioridades de las iniciativas de desarrollo de API en las empresas.

¿Por qué son importantes las API internas? ¿Qué ventajas ofrecen? Y, sobre todo, ¿cuál es la arquitectura óptima para gestionarlas? Este blog aborda estas cuestiones para ayudarle a ofrecer API internas de forma segura y a gran escala.

¿Por qué son importantes las API internas?

Las API internas eliminan los silos de datos y tienden puentes al abrir los distintos sistemas backend de una organización para que otros desarrolladores de una línea de negocio (LOB) puedan utilizarlos. Por ejemplo, el departamento de marketing de un fabricante puede necesitar visibilidad sobre los sistemas utilizados por el departamento de la cadena de suministro para determinar si conviene aplicar descuentos a determinados productos y modelos, con el fin de dirigirse al segmento de mercado adecuado y maximizar los ingresos.

¿Cómo eliminan los silos las API internas? Proporcionan una interfaz común que permite el intercambio de datos mediante formatos estándar como HTML o JSON. No solo es fácil y rápido crear una API, sino también consumirla. Esto contrasta con el uso de conectores de bases de datos propietarios y protocolos de intercambio de datos complejos para recuperar información de repositorios de datos. Al reducir las fricciones, las API mejoran considerablemente la productividad. Estas API no están disponibles para desarrolladores externos ni terceros. El tráfico de las API internas permanece dentro de la organización y, por tanto, dentro del cortafuegos corporativo.

Ventajas de las API internas

Las API internas aceleran la comercialización y reducen el tiempo y el coste del desarrollo de software. Veamos sus ventajas en detalle.

Eficiencia operativa

Las API internas proporcionan una capa de abstracción fácil de utilizar para conectar distintas áreas de una empresa, así como la flexibilidad necesaria para adaptarse a los cambios en los requisitos. En lugar de crear una pila tecnológica aislada para las aplicaciones de cada línea de negocio, los desarrolladores de toda la organización pueden recurrir a un conjunto común de API internas para acceder a los datos. Esto elimina la duplicación y reduce el tiempo de desarrollo de software, lo que mejora la productividad de los desarrolladores y del departamento de TI.

Desarrollo de un sistema de registro

Las API internas favorecen el desarrollo de un sistema de registro que actúa como fuente autorizada de los elementos de datos clave de una organización. Para garantizar la integridad de los datos, debe existir un único sistema de registro —y solo uno— para cada dato concreto. Si cada línea de negocio (LOB) dispone de sus propios datos o incluso de una versión ligeramente distinta, se generan discrepancias y confusión. Las API internas constituyen un mecanismo eficaz para acceder a esta única fuente de información fiable.

Ahorro de costes

La eficiencia se traduce en un ahorro de costes: no es necesario crear plataformas propias con un alto grado de personalización para cada línea de negocio. Tampoco es necesario desarrollar ni adquirir conectores e integraciones costosos que, en esencia, son herramientas aisladas.

Por ejemplo, el Gobierno nacional de Estonia utiliza X‑Road, una plataforma de intercambio de datos que conecta de forma fluida a todos los organismos públicos. Los ciudadanos estonios ni siquiera necesitan llevar consigo el permiso de conducir, ya que esa información puede obtenerse rápidamente del registro de población y del registro de vehículos, aunque ambos repositorios de datos estén separados. Este informe del Banco Mundial estimó de forma conservadora que, al facilitar el acceso a la información, X‑Road había ahorrado al Gobierno y a los ciudadanos de Estonia 2,8 millones de horas de trabajo en un solo año (2014).

Directrices para gestionar las API internas

Veamos algunas prácticas recomendadas para gestionar las API internas.

Utiliza una herramienta de gestión de API

Para definir, publicar y proteger de forma eficiente las API, tanto internas como externas, así como supervisarlas y analizarlas, necesita una solución de gestión de API. También se necesita un portal para desarrolladores que permita a los desarrolladores internos familiarizarse rápidamente con las API publicadas.

Garantice un alto rendimiento

Los microservicios constituyen un nuevo enfoque arquitectónico para el desarrollo de software que está ganando terreno. Muchas empresas están rediseñando la arquitectura de sus aplicaciones internas existentes o creando otras nuevas con este marco. En las arquitecturas de microservicios, las API son el medio de comunicación tanto entre los clientes y la aplicación basada en microservicios como entre los propios microservicios que componen la aplicación. Cuando un cliente de API solicita recursos a una aplicación de backend, una puerta de enlace de API dirige el tráfico al microservicio correspondiente. La puerta de enlace de API también autentica las llamadas y aplica límites de frecuencia para evitar ataques que podrían producirse si agentes externos consiguieran vulnerar el cortafuegos corporativo.

Los microservicios son más «comunicativos» que las aplicaciones monolíticas y generan grandes volúmenes de tráfico «este-oeste» entre ellos. Por eso, es muy importante elegir una puerta de enlace de alto rendimiento que pueda procesar un gran volumen de solicitudes por segundo y ofrecer respuestas con gran rapidez. Las solicitudes de los clientes suelen generar varias llamadas a las API de distintos microservicios, por lo que un retraso en la puerta de enlace de API, incluso en una sola llamada, puede provocar un efecto en cascada y dar lugar a latencias muy elevadas.

No enrute las llamadas a través de una nube externa a la red corporativa

Aunque existen soluciones en la nube de primera generación que ofrecen una gestión completa del ciclo de vida de las API, no son adecuadas para gestionar API internas. Dado que sus arquitecturas acoplan estrechamente el plano de datos (la puerta de enlace de API que procesa el tráfico de las API) y el plano de control (que realiza las funciones de gestión de las API), durante la ejecución todas las llamadas a API internas deben enrutarse a través de la nube de la solución de gestión de API. Esto presenta dos inconvenientes:

Añade latencia – El desvío a la nube para procesar una llamada de API interna es innecesariamente largo e inevitablemente perjudica el rendimiento.
Infringe la política corporativa de confianza cero – Dado que la llamada a la API interna debe dirigirse a la nube, es necesario abrir puertos en el cortafuegos. Esto deja la red corporativa expuesta a ataques y brechas de seguridad e introduce una complejidad innecesaria.

Por motivos de seguridad, el tráfico interno de las API debe permanecer detrás del cortafuegos corporativo, lo que impide enrutar las llamadas a una nube externa. Esto se aplica incluso a las empresas que alojan aplicaciones y API en sus propios entornos de nube privada.

¿Cómo puede ayudar NGINX?

NGINX le ayuda de varias formas a gestionar sus API internas.

NGINX es conocido por su rendimiento. Según GigaOm, una firma independiente de análisis e investigación tecnológica, NGINX puede procesar llamadas a API de extremo a extremo en menos de 30 ms, incluso con tasas superiores a 30 000 solicitudes por segundo. Obtenga más información sobre los resultados de las pruebas de rendimiento en nuestro blog. Hemos publicado una arquitectura de referencia con directrices detalladas para ofrecer API en tiempo real.
NGINX y NGINX Plus están diseñados para contenedores, la infraestructura preferida para desarrollar microservicios. Con un tamaño aproximado de 2 MB, NGINX y NGINX Plus se ejecutan en servidores Linux compatibles (físicos, en la nube o virtuales), o directamente en contenedores Docker orquestados por Kubernetes y otras plataformas.
La innovadora arquitectura de la solución de gestión de API de NGINX está diseñada para ofrecer escalabilidad. NGINX permite una gestión distribuida de las API al desacoplar la puerta de enlace de API (NGINX Plus) del software de gestión de API (NGINX Controller [ahora F5 NGINX Management Suite] ). No existe ninguna dependencia en tiempo de ejecución entre ambos, lo que garantiza que el tráfico de las API se procese sin sobrecargas innecesarias, como scripts adicionales, llamadas a bases de datos u otra lógica del plano de control. La arquitectura desacoplada ofrece la máxima flexibilidad a la hora de decidir dónde implementar Controller [NGINX Management Suite] y las puertas de enlace de API NGINX Plus: puede implementarlos en sus propias instalaciones, en la nube pública o incluso en varias nubes públicas si su red corporativa se extiende a la nube. Las llamadas internas a las API no tienen que enrutarse a través de una nube externa a la red corporativa, ya que las puertas de enlace de API NGINX Plus que gestionan el tráfico de las API pueden implementarse de forma independiente detrás del cortafuegos corporativo.

¿Tiene API internas? ¿O tiene previsto desarrollar API internas? ¿Enruta sus API internas a través de la nube? Nos encantaría conocer su opinión en los comentarios. Mientras tanto, empiece hoy mismo con una prueba gratuita de 30 días de NGINX Controller [NGINX Management Suite] o póngase en contacto con nosotros para hablar sobre sus casos de uso.