Las empresas actuales suelen estar formadas por equipos distribuidos por todo el mundo que desarrollan e implementan API y microservicios, normalmente en más de un entorno de implementación. Según el Informe sobre el estado de la estrategia de aplicaciones de F5, el 81 % de las organizaciones opera en tres o más entornos, entre los que se incluyen la nube pública, la nube privada, las instalaciones locales y el edge.
Garantizar la fiabilidad y la seguridad de estas arquitecturas multicloud complejas supone un gran reto para los equipos de Operaciones de Plataforma responsables de su mantenimiento. Según los responsables de ingeniería de software encuestados en el informe de F5, la visibilidad (45 %) y la aplicación uniforme de medidas de seguridad (44 %) encabezan la lista de retos multicloud a los que se enfrentan los equipos de Operaciones de Plataforma.
Con el creciente número de API y microservicios que existen hoy en día, el gobierno de las API se está convirtiendo rápidamente en uno de los aspectos más importantes a la hora de planificar e implementar una estrategia de API para toda la empresa. Pero ¿qué es el gobierno de las API y por qué es tan importante para su estrategia de API?
¿Qué es la gobernanza de las API?
En esencia, la gobernanza de las API consiste en crear políticas y realizar comprobaciones y validaciones para garantizar que las API sean fáciles de encontrar, fiables, observables y seguras. Proporciona visibilidad sobre el estado de los sistemas complejos y los procesos empresariales que sustentan sus aplicaciones modernas, lo que permite orientar la evolución de su infraestructura de API a lo largo del tiempo.
¿Por qué necesita la gobernanza de API?
No se puede subestimar la importancia estratégica de la gobernanza de las API: es el medio que permite materializar la estrategia global de API de su organización. Sin una gobernanza adecuada, nunca podrá lograr coherencia en el diseño, el funcionamiento y la comercialización de sus API.
Cuando se aplica de forma deficiente, la gobernanza suele imponer requisitos engorrosos que ralentizan a los equipos. Sin embargo, cuando se aplica correctamente, la gobernanza de las API reduce la carga de trabajo, agiliza las aprobaciones y permite que los distintos equipos de la organización funcionen de forma independiente, al tiempo que contribuyen a alcanzar los objetivos generales de la estrategia de API.
¿Qué tipos de API necesita gobernar?
La creación de un plan eficaz de gobernanza de API como parte de su estrategia de API comienza por identificar los tipos de API que tiene en producción, así como las herramientas, políticas y directrices que necesita para gestionarlas. En la actualidad, la mayoría de los equipos empresariales trabajan con cuatro tipos principales de API:
- API externas – Se ofrecen a consumidores y desarrolladores externos para permitir integraciones de autoservicio con datos y funcionalidades
- API internas – Se utilizan para conectar aplicaciones internas y microservicios, y solo están disponibles para los desarrolladores de su organización
- API para socios – Facilitan las relaciones comerciales estratégicas al compartir el acceso a sus datos o aplicaciones con desarrolladores de organizaciones asociadas
- API de terceros – Se consumen como servicio de proveedores externos, a menudo para procesar pagos o permitir el acceso a datos o aplicaciones
Cada tipo de API de la empresa debe gestionarse para garantizar que sea seguro, fiable y accesible para los equipos y usuarios que necesiten acceder a él.
¿Qué modelos de gobernanza de API puede utilizar?
Hay muchas formas de definir y aplicar la gobernanza de las API. En NGINX, normalmente vemos que los clientes aplican uno de estos dos modelos:
- Centralizado – Un equipo central revisa y aprueba los cambios; en función de la escala de las operaciones, este equipo puede convertirse en un cuello de botella que ralentice el progreso
- Descentralizado – Los equipos individuales tienen autonomía para crear y gestionar API; esto acelera la comercialización, pero compromete la seguridad y la fiabilidad generales
Sin embargo, a medida que las empresas avanzan en su transición hacia un enfoque API-first, ambos modelos empiezan a fallar conforme aumenta el número de API en producción. Los modelos centralizados suelen intentar aplicar un enfoque único para todos que exige diversas revisiones y aprobaciones a lo largo del proceso. Esto ralentiza a los equipos de desarrollo y genera fricciones; frustrados, los desarrolladores a veces incluso encuentran formas de eludir los requisitos (la temida «TI en la sombra»).
El otro modelo —la gobernanza descentralizada— funciona bien al principio para los desarrolladores de API, pero con el tiempo aumenta la complejidad. A menos que los distintos equipos que implementan API se comuniquen con frecuencia, la experiencia general pierde coherencia entre las diferentes API: cada una se diseña y funciona de forma distinta, los cambios de versión provocan interrupciones entre servicios y la seguridad se aplica de manera desigual entre equipos y servicios. Para los equipos que crean API, el trabajo y la complejidad adicionales acaban ralentizando el desarrollo hasta casi paralizarlo, al igual que ocurre con el modelo centralizado.
Las aplicaciones nativas de la nube dependen de las API para que los distintos microservicios se comuniquen entre sí y envíen las respuestas al origen de la solicitud. A medida que las empresas siguen adoptando los microservicios por su flexibilidad y agilidad, la proliferación de API no va a desaparecer. Por el contrario, se necesita un enfoque diferente para gobernar las API en estos entornos complejos y en constante evolución.
Utilice la gobernanza adaptativa para empoderar a los desarrolladores de API
Afortunadamente, hay una forma mejor de hacerlo. La gobernanza adaptativa ofrece un modelo alternativo que brinda autonomía a los desarrolladores de API, al tiempo que proporciona a los equipos de Operaciones de Plataforma el control que necesitan para garantizar la fiabilidad y la seguridad de las API en toda la empresa.
La gobernanza adaptativa se basa en equilibrar el control (la necesidad de coherencia) con la autonomía (la capacidad de tomar decisiones locales) para favorecer la agilidad en toda la empresa. En la práctica, el modelo de gobernanza adaptativa descentraliza y distribuye la toma de decisiones entre los equipos.
Los equipos de Operaciones de Plataforma gestionan la infraestructura compartida (puertas de enlace de API y portales para desarrolladores) y establecen políticas globales para garantizar la coherencia entre las API. Sin embargo, los equipos que crean las API actúan como expertos en la materia para sus servicios o líneas de negocio. Tienen autonomía para definir y aplicar políticas locales a sus API —control de acceso basado en roles (RBAC), limitación de la tasa de solicitudes de su servicio, etc.— con el fin de satisfacer los requisitos de sus respectivos contextos empresariales.
La gobernanza adaptativa permite que cada equipo o línea de negocio defina sus flujos de trabajo y equilibre el nivel de control necesario, al tiempo que utiliza la infraestructura compartida de la organización.
Implemente la gobernanza adaptativa para sus API con NGINX
A medida que empiece a planificar e implementar su estrategia de API, siga estas prácticas recomendadas para implantar una gobernanza adaptativa en su organización:
- Proporcionar una infraestructura compartida – Proporcione a los equipos acceso a puertas de enlace de API y portales para desarrolladores donde puedan publicar proxies de API y documentación
- Dar autonomía a los equipos – Ayudar a los equipos a incorporarse y gestionar el ciclo de vida de sus API en un espacio de trabajo compartido
- Equilibra las políticas globales con el control local – Establece políticas globales en toda la infraestructura compartida y, al mismo tiempo, ofrece a los equipos controles detallados sobre sus servicios
Veamos cómo puede abordar estos casos de uso con API Connectivity Manager, que forma parte de F5 NGINX Management Suite.
Proporcionar una infraestructura compartida
Los equipos de toda su organización están desarrollando API y necesitan incluir funcionalidades similares en sus microservicios: autenticación y autorización, cifrado mTLS y mucho más. También deben poner la documentación y el control de versiones a disposición de los consumidores de sus API, ya sean equipos internos, socios comerciales o desarrolladores externos.
En lugar de exigir a los equipos que desarrollen sus propias soluciones, los equipos de Operaciones de Plataforma pueden proporcionar acceso a una infraestructura compartida. Al igual que todas las acciones de API Connectivity Manager, puede configurar esta opción en tan solo unos minutos mediante la interfaz de usuario o la API REST totalmente declarativa, que le permite integrar API Connectivity Manager en sus canalizaciones de CI/CD. En este artículo utilizamos la interfaz de usuario para mostrar algunos flujos de trabajo habituales.
API Connectivity Manager admite dos tipos de espacios de trabajo: de infraestructura y de servicios. Los equipos de operaciones de plataforma utilizan los espacios de trabajo de infraestructura para incorporar y gestionar infraestructura compartida en forma de clústeres de API Gateway y clústeres del portal para desarrolladores. Los desarrolladores de API utilizan los espacios de trabajo de servicios para publicar y gestionar API y documentación.
Para configurar una infraestructura compartida, primero añada un espacio de trabajo de infraestructura. Haga clic en Infraestructura en la columna de navegación de la izquierda y, a continuación, en el botón + Añadir situado en la esquina superior derecha de la pestaña. Asigne un nombre al espacio de trabajo (en este caso, team-sentence, un equipo imaginario que está creando una API sencilla de «¡Hola, mundo!»).
Figura 1: Añadir espacios de trabajo de infraestructura
A continuación, añada un entorno al espacio de trabajo. Los entornos contienen clústeres de API Gateway y clústeres del portal para desarrolladores. Haga clic en el nombre de su espacio de trabajo y, a continuación, en el icono … de la columna Acciones; seleccione Añadir en el menú desplegable.
El panel Crear entorno se abre como se muestra en la figura 2. Rellene el campo Nombre (y, opcionalmente, Descripción), seleccione el tipo de entorno (de producción o no productivo) y haga clic en el botón + Añadir de la infraestructura que quiera añadir (clústeres de API Gateway, clústeres del Portal para desarrolladores o ambos). Haga clic en el botón Crear para terminar de configurar el entorno. Para obtener instrucciones completas, consulte la documentación de API Connectivity Manager.
Figura 2: Crear un entorno e incorporar infraestructura
Da autonomía a los equipos
Proporcionar una separación lógica entre los equipos por línea de negocio, región geográfica u otro límite lógico tiene sentido, siempre que no les prive del acceso a las herramientas que necesitan para alcanzar sus objetivos. Tener acceso a una infraestructura compartida no debería implicar que los equipos tengan que preocuparse por las actividades a nivel global. En su lugar, conviene que se centren en definir sus propios requisitos, trazar una hoja de ruta y desarrollar sus microservicios.
Para ayudar a los equipos a organizarse, los equipos de Operaciones de Plataforma pueden proporcionar espacios de trabajo de servicios para que los equipos organicen y gestionen sus servicios y documentación. Estos espacios crean límites lógicos y proporcionan acceso a distintos entornos —por ejemplo, desarrollo, pruebas y producción— para desarrollar servicios. El proceso es similar al de crear el espacio de trabajo de infraestructura que creamos en la sección anterior.
Primero, haz clic en Servicios en la columna de navegación de la izquierda y, a continuación, en el botón + Añadir situado en la esquina superior derecha de la pestaña. Asigna un nombre a tu espacio de trabajo (en este caso, api-sentence para nuestro servicio «Hello, World») y, si lo deseas, añade una descripción e información de contacto.
Figura 3: Crear un espacio de trabajo de servicios
En este punto, puede invitar a los desarrolladores de API a empezar a publicar proxies y documentación en el espacio de trabajo que ha creado para ellos. Para obtener instrucciones completas sobre cómo publicar proxies y documentación de API, consulte la documentación de API Connectivity Manager.
Equilibrar las políticas globales y el control local
La gobernanza adaptativa requiere un equilibrio entre la aplicación de políticas globales y la autonomía de los equipos para tomar decisiones que aumenten la agilidad. Es necesario establecer una separación clara de responsabilidades, definiendo la configuración global que aplica el equipo de Operaciones de Plataforma y estableciendo «límites de actuación» que determinen las herramientas que utilizan los desarrolladores de API y las decisiones que pueden tomar.
API Connectivity Manager ofrece una combinación de políticas globales (aplicadas a la infraestructura compartida) y controles granulares gestionados en el nivel del proxy de API.
Las políticas globales disponibles en API Connectivity Manager incluyen:
- Formato de respuesta de error – Personalice el código de error y la estructura de respuesta de la puerta de enlace de API
- Formato de registro – Habilite el registro de acceso y personalice el formato de las entradas del registro
- OpenID Connect – Proteja el acceso a las API mediante una política de OpenID Connect
- Encabezados de respuesta – Incluya o excluya encabezados en la respuesta
- Tamaño del cuerpo de la solicitud – Limita el tamaño de las cargas útiles de API entrantes
- TLS entrante – Establezca la política para las conexiones TLS con clientes de API
- TLS de backend – Proteja con TLS la conexión con los servicios de backend
Las políticas de proxy de API disponibles en API Connectivity Manager incluyen:
- Métodos HTTP permitidos – Defina qué métodos de solicitud se pueden utilizar (
GET,POST,PUT, etc.) - Control de acceso – Proteja el acceso a las API mediante distintas técnicas de autenticación y autorización (claves de API, autenticación básica HTTP, tokens web JSON)
- Comprobaciones del estado del backend – Realice comprobaciones continuas del estado para evitar solicitudes fallidas a los servicios de backend
- CORS – Permite el acceso controlado a los recursos por parte de clientes de dominios externos
- Almacenamiento en caché – Mejore el rendimiento del proxy de API mediante políticas de almacenamiento en caché
- Encabezados de solicitud del proxy – Transmite determinados encabezados a los servicios de backend
- Limitación de velocidad – Limita las solicitudes entrantes y protege las cargas de trabajo de las API
En el siguiente ejemplo, utilizamos la interfaz de usuario para definir una política que proteja la comunicación entre un proxy de API Gateway y los servicios de backend.
Haga clic en Infraestructura en la columna de navegación izquierda. Después de hacer clic en el nombre del entorno que contiene el clúster de API Gateway que desea editar, la pestaña muestra los clústeres de API Gateway y los clústeres del portal para desarrolladores de ese entorno.
Figura 4: Configuración de políticas globales para clústeres de API Gateway y clústeres del Portal para desarrolladores
En la fila correspondiente al clúster de API Gateway al que desea aplicar una política, haga clic en el icono … de la columna Acciones y seleccione Editar configuración avanzada en el menú desplegable. Haga clic en Políticas globales en la columna izquierda para mostrar una lista de todas las políticas globales que puede configurar.
Figura 5: Configurar políticas para un clúster de API Gateway
Para aplicar la política TLS Backend, haga clic en el icono … situado en el extremo derecho de su fila y seleccione Add Policy en el menú desplegable. Introduzca la información solicitada, cargue el certificado y haga clic en Add. A continuación, haga clic en el botón Save and Submit. A partir de ese momento, el tráfico entre el clúster de API Gateway y los servicios de backend estará protegido mediante TLS. Para obtener instrucciones completas, consulte la documentación de API Connectivity Manager.
Resumen
Planificar e implementar la gobernanza de las API es un paso fundamental para garantizar el éxito de su estrategia de API. Al avanzar hacia un modelo distribuido y recurrir a una gobernanza adaptativa para abordar los requisitos específicos de los distintos equipos y API, puede ampliar y aplicar una gobernanza uniforme sin renunciar a la velocidad y la agilidad que hacen que las API y los entornos nativos de la nube sean tan productivos.
Primeros pasos
Inicie una prueba gratuita de 30 días de NGINX Management Suite, que incluye acceso a API Connectivity Manager, NGINX Plus como puerta de enlace de API y a NGINX App Protect para proteger sus API.
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.