Las aplicaciones nativas de la nube se componen de decenas, cientos o incluso miles de API que conectan microservicios entre sí. En conjunto, estos servicios y API proporcionan la resiliencia, la escalabilidad y la flexibilidad que constituyen la esencia de las aplicaciones nativas de la nube.
Hoy en día, estas API y microservicios subyacentes suelen ser desarrollados por equipos distribuidos por todo el mundo, que necesitan trabajar con cierto grado de autonomía e independencia para ofrecer nuevas funcionalidades al mercado de manera oportuna.
Al mismo tiempo, Operaciones de plataforma son responsables de garantizar la fiabilidad y la seguridad generales de las aplicaciones y la infraestructura de la empresa, incluidas sus API subyacentes. Necesitan visibilidad del tráfico de las API y la capacidad de establecer medidas de protección globales para garantizar una seguridad y un cumplimiento normativo uniformes, al tiempo que ofrecen una excelente experiencia para desarrolladores de API.
Aunque los intereses de estos dos grupos pueden entrar en conflicto, no creemos que sea inevitable. Hemos creado API Connectivity Manager como parte de F5 NGINX Management Suite para que los equipos de operaciones de plataforma puedan mantener la seguridad y garantizar un funcionamiento fluido, al tiempo que los desarrolladores de API pueden crear y lanzar nuevas funcionalidades con facilidad.
Creación de una arquitectura compatible con la conectividad de API
Como plano de gestión de última generación, API Connectivity Manager está diseñado para aprovechar y ampliar la potencia de NGINX Plus como puerta de enlace de API. Si ha utilizado NGINX anteriormente, ya conoce su escalabilidad, fiabilidad, flexibilidad y rendimiento como puerta de enlace de API.
Al diseñar API Connectivity Manager, desarrollamos una nueva arquitectura para facilitar una mejor colaboración entre los equipos de operaciones de plataforma y los desarrolladores. Esta arquitectura utiliza los siguientes términos estándar del sector para sus componentes (algunos de los cuales difieren de los nombres conocidos por los usuarios experimentados de NGINX):
- Espacio de trabajo – Un conjunto aislado de infraestructura destinado a la gestión y el uso exclusivos de una única unidad de negocio o equipo; suele incluir varios entornos
- Entorno – Una colección lógica de instancias (clústeres) de NGINX Plus que actúan como puertas de enlace de API o portales para desarrolladores en una fase específica del ciclo de vida de la aplicación, como desarrollo, pruebas o producción
- Clúster de proxies de puerta de enlace de API – Una representación lógica de la puerta de enlace de API de NGINX que agrupa instancias de NGINX Plus y sincroniza el estado entre ellas
- Proxy de API – Una representación de una instancia publicada de una API que incluye enrutamiento, control de versiones y otras políticas
- Políticas – Una abstracción global o local para definir funciones específicas del proxy de API, como la resiliencia del tráfico, la seguridad o la calidad del servicio
El siguiente diagrama muestra cómo se anidan los componentes dentro de un espacio de trabajo:
Esta jerarquía lógica permite diversos casos de uso importantes que facilitan la conectividad de las API en toda la empresa. Por ejemplo, los espacios de trabajo pueden incorporar varios tipos de infraestructura (como la nube pública y los entornos locales), lo que permite a los equipos acceder a ambos y proporciona a los responsables de la infraestructura visibilidad sobre el tráfico de las API en los dos entornos.
En futuras publicaciones analizaremos con más detalle los componentes de la arquitectura. Por ahora, veamos cómo API Connectivity Manager satisface las necesidades de los distintos perfiles que contribuyen al desarrollo y la entrega de API.
API Connectivity Manager para operaciones de plataforma
El equipo de Operaciones de Plataforma es responsable de crear y gestionar el ciclo de vida de la infraestructura de cada organización. Proporciona la plataforma sobre la que los desarrolladores crean aplicaciones y servicios destinados a clientes y socios. Los equipos de desarrollo suelen estar descentralizados, trabajan en múltiples entornos y dependen de distintas líneas de negocio. Satisfacer las necesidades de estos grupos y entornos dispersos, manteniendo al mismo tiempo estándares para toda la empresa, es uno de los mayores retos a los que se enfrentan actualmente los equipos de Operaciones de Plataforma.
API Connectivity Manager ofrece formas innovadoras de separar los equipos y sus operaciones mediante el uso de espacios de trabajo como límite lógico. También permite a los equipos de Operaciones de Plataforma gestionar el ciclo de vida de la infraestructura sin interferir con los equipos que crean e implementan API. API Connectivity Manager incluye un conjunto integrado de políticas globales predeterminadas que proporcionan seguridad y configuración básicas para las puertas de enlace de API y los portales para desarrolladores de NGINX Plus. A continuación, los equipos de Operaciones de Plataforma pueden configurar políticas globales adicionales para exigir opcionalmente mTLS, configurar formatos de registro o estandarizar las cabeceras de proxy.
La política global impone uniformidad y aporta coherencia a las API que se implementan en el clúster compartido de puertas de enlace de API. API Connectivity Manager también ofrece a las organizaciones la posibilidad de ejecutar clústeres descentralizados del plano de datos para separar físicamente los entornos en los que cada equipo o línea de negocio implementa sus API.
En una próxima entrada del blog, analizaremos cómo los equipos de operaciones de plataforma pueden utilizar API Connectivity Manager para garantizar la seguridad y la gobernanza de las API, al tiempo que ayudan a los desarrolladores de API a alcanzar sus objetivos.
API Connectivity Manager para desarrolladores
Los equipos de las distintas líneas de negocio poseen y gestionan sus propios conjuntos de API. Necesitan tener el control de sus productos de API para lanzar sus aplicaciones y servicios al mercado a tiempo, por lo que no pueden permitirse esperar la aprobación de otros equipos para utilizar una infraestructura compartida. Al mismo tiempo, deben existir «mecanismos de protección» que eviten que los equipos interfieran entre sí.
Al igual que el perfil de Operaciones de Plataforma, los desarrolladores que actúan como propietarios de API disponen de sus propios espacios de trabajo, que aíslan sus API de las de otros equipos. API Connectivity Manager proporciona políticas en el nivel de API Proxy para que los propietarios de API configuren ajustes del servicio, como la limitación de solicitudes y requisitos de seguridad adicionales.
En una próxima entrada del blog, analizaremos cómo los desarrolladores pueden utilizar API Connectivity Manager para simplificar la gestión del ciclo de vida de las API.
Primeros pasos
Inicia una prueba gratuita de 30 días de NGINX Management Suite, que incluye API Connectivity Manager e Instance Manager.
Sobre el autor
Artículos relacionados del blog
Únete a F5 NGINX en AppWorld 2024
Descubre las numerosas razones para asistir al evento insignia de F5, que incluirá un emocionante anuncio sobre la cartera de productos NGINX.
Rotación de certificados SSL/TLS sin reinicios en NGINX Open Source
La función de diccionario compartido permite configurar NGINX sin necesidad de reiniciarlo al renovar los certificados SSL/TLS.
Exposición de APIs en Kubernetes
La unidad 2 de Microservices March 2022 se centra en cómo exponer tus API en Kubernetes. Aquí tienes enlaces a los recursos que necesitas: la retransmisión en directo del 14 de marzo, artículos de blog y otros recursos de preparación, y el laboratorio práctico «Protege las API de Kubernetes mediante la limitación de solicitudes».
NGINX Sprint 2.0: visión clara, código renovado y nuevos compromisos con el código abierto
Hoy, en NGINX Sprint 2.0, anunciamos cómo respaldaremos nuestra visión del futuro de las aplicaciones modernas con una mayor presencia en la comunidad de código abierto, incluida la participación en el proyecto comunitario Kubernetes, nuevos proyectos de software de código abierto y la arquitectura de referencia para aplicaciones modernas.
Presentamos NGINX Plus R22
NGINX Plus R22 incorpora nuevas funcionalidades, como la compatibilidad con OCSP para verificar la revocación de certificados en TLS mutuo, el uso de varios proveedores de identidad OIDC en una configuración, el seguimiento en tiempo real de la limitación de solicitudes y conexiones en el panel de NGINX Plus y mejoras en NGINX JavaScript.
Presentamos NGINX Plus R17
NGINX Plus R17 incorpora compatibilidad con la limitación de velocidad en dos fases y con TLS 1.3, la versión más reciente del protocolo Transport Layer Security. La configuración de OpenID Connect es más sencilla y NGINX ModSecurity WAF es el doble de rápido que antes. También se ha actualizado el módulo JavaScript de NGINX.