La gobernanza adaptativa brinda a los desarrolladores de API la autonomía que necesitan

La empresa actual suele estar formada por equipos distribuidos globalmente que crean e implementan API y microservicios, generalmente en más de un entorno de implementación. Según el Informe sobre el estado de la estrategia de aplicação de F5, el 81 % de las organizaciones operan en tres o más entornos que van desde la nube pública, la nube privada, las instalaciones locales y el borde.

Garantizar la confiabilidad y seguridad de estas complejas arquitecturas multicloud es un desafío importante para los equipos de operaciones de plataforma responsables de su mantenimiento. Según los líderes de ingeniería de software encuestados en el informe de F5, la visibilidad (45 %) y la seguridad constante (44 %) encabezan la lista de desafíos multicloud que enfrentan los equipos de Platform Ops .

Con el creciente número de API y microservicios en la actualidad, la gobernanza de API se está convirtiendo rápidamente en uno de los temas más importantes para planificar e implementar una estrategia de API a nivel empresarial. Pero ¿qué es la gobernanza de API y por qué es tan importante para su estrategia de API?

¿Qué es la gobernanza de API?

En el nivel más básico, la gobernanza de API implica crear políticas y ejecutar controles y validaciones para garantizar que las API sean detectables, confiables, observables y seguras. Proporciona visibilidad del estado de los sistemas complejos y los procesos de negocio que impulsan sus aplicações modernas, que puede utilizar para guiar la evolución de su infraestructura de API a lo largo del tiempo.

¿Por qué necesita gobernanza de API?

No se puede sobreestimar la importancia estratégica de la gobernanza de API: es el medio por el cual se hace realidad la estrategia general de API de su organización. Sin una gobernanza adecuada, nunca podrá lograr coherencia en el diseño, la operación y la producción de sus API.

Cuando se realiza de forma deficiente, la gobernanza suele imponer requisitos onerosos que ralentizan a los equipos. Sin embargo, cuando se hace bien, la gobernanza de API reduce el trabajo, agiliza las aprobaciones y permite que los diferentes equipos de su organización funcionen de forma independiente mientras cumplen con los objetivos generales de su estrategia de API.

¿Qué tipos de API necesitas gobernar?

La creación de un plan de gobernanza de API eficaz como parte de su estrategia de API comienza con la identificación de los tipos de API que tiene en producción y las herramientas, políticas y orientación que necesita para administrarlas. Hoy en día, la mayoría de los equipos empresariales trabajan con cuatro tipos principales de API:

• API externas : se entregan a consumidores y desarrolladores externos para permitir integraciones de autoservicio con datos y capacidades.
• API internas : se utilizan para conectar aplicações internas y microservicios y solo están disponibles para los desarrolladores de su organización.
• API de socios : facilite las relaciones comerciales estratégicas al compartir el acceso a sus datos o aplicações con desarrolladores de organizaciones asociadas.
• API de terceros : consumidas por proveedores externos como un servicio, a menudo para gestionar pagos o habilitar el acceso a datos o aplicações.

Cada tipo de API en la empresa debe estar gobernado para garantizar que sea seguro, confiable y accesible para los equipos y usuarios que necesitan acceder a ella.

¿Qué modelos de gobernanza de API puedes utilizar?

Hay muchas formas de definir y aplicar la gobernanza de API. En NGINX, normalmente vemos que los clientes aplican uno de dos modelos:

• Centralizado : un equipo central revisa y aprueba los cambios; dependiendo 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 administrar API; esto aumenta el tiempo de comercialización, pero sacrifica la seguridad y la confiabilidad generales.

Sin embargo, a medida que las empresas avanzan en sus recorridos hacia las API como prioridad, ambos modelos comienzan a fallar a medida que aumenta el número de API en producción. Los modelos centralizados a menudo intentan implementar un enfoque único que requiere varias revisiones y aprobaciones a lo largo del camino. Esto ralentiza a los equipos de desarrollo y crea fricción: en su frustración, los desarrolladores a veces incluso encuentran formas de eludir los requisitos (la temida “TI en la sombra”).

El otro modelo (gobernanza descentralizada) funciona bien para los desarrolladores de API al principio, pero con el tiempo la complejidad aumenta. A menos que los diferentes equipos que implementan API se comuniquen con frecuencia, la experiencia general se vuelve inconsistente entre las API: cada una está diseñada y funciona de manera diferente, los cambios de versión resultan en interrupciones entre los servicios y la seguridad se aplica de manera inconsistente entre los equipos y servicios. Para los equipos que crean API, el trabajo adicional y la complejidad terminan haciendo que el desarrollo se ralentice hasta casi detenerse, al igual que el modelo centralizado.

Las aplicações nativas de la nube dependen de API para que los microservicios individuales se comuniquen entre sí y envíen respuestas a la fuente de la solicitud. A medida que las empresas continúan adoptando microservicios por su flexibilidad y agilidad, la proliferación de API no desaparecerá . En cambio, se necesita un enfoque diferente para gobernar las API en estos entornos complejos y en constante cambio.

Utilice la gobernanza adaptativa para empoderar a los desarrolladores de API

Afortunadamente, existe una manera mejor. La gobernanza adaptativa ofrece un modelo alternativo que empodera a los desarrolladores de API y al mismo tiempo brinda a los equipos de Platform Ops el control que necesitan para garantizar la confiabilidad y la seguridad de las API en toda la empresa.

En el corazón de la gobernanza adaptativa se encuentra el equilibrio entre el control (la necesidad de consistencia) y la autonomía (la capacidad de tomar decisiones locales) para permitir la agilidad en toda la empresa. En la práctica, el modelo de gobernanza adaptativa desagrega y distribuye la toma de decisiones entre los equipos.

Los equipos de operaciones de plataforma administran 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 API actúan como expertos en la materia para sus servicios o línea de negocio. Tienen la capacidad de establecer y aplicar políticas locales para sus API (control de acceso basado en roles [RBAC], limitación de velocidad para sus servicios, etc.) para satisfacer los requisitos de sus contextos comerciales individuales.

La gobernanza adaptativa permite que cada equipo o línea de negocio defina sus flujos de trabajo y equilibre el nivel de control requerido, mientras utiliza la infraestructura compartida de la organización.

Implemente una gobernanza adaptativa para sus API con NGINX

A medida que comience a planificar e implementar su estrategia de API, siga estas prácticas recomendadas para implementar la gobernanza adaptativa en su organización:

• Proporcionar infraestructura compartida : proporcione a los equipos acceso a puertas de enlace de API y portales para desarrolladores para publicar servidores proxy de API y documentación.
• Dar a los equipos autonomía : ayudar a los equipos a incorporar y gestionar el ciclo de vida de sus API dentro de un espacio de trabajo compartido.
• Equilibre las políticas globales con el control local : establezca políticas globales en toda la infraestructura compartida y, al mismo tiempo, proporcione a los equipos controles granulares para sus servicios.

Veamos cómo puede lograr estos casos de uso con API Connectivity Manager , parte de F5 NGINX Management Suite.

Proporcionar infraestructura compartida

Los equipos de toda su organización están creando API y necesitan incluir funcionalidades similares en sus microservicios: autenticación y autorización, cifrado mTLS y más. También necesitan poner la documentación y las versiones a disposición de sus consumidores de API, ya sean equipos internos, socios comerciales o desarrolladores externos.

En lugar de requerir que los equipos creen sus propias soluciones, los equipos de Platform Ops pueden brindar acceso a una infraestructura compartida. Al igual que con todas las acciones en API Connectivity Manager, puede configurarlo en tan solo unos minutos usando la interfaz de usuario o la API REST totalmente declarativa, lo que le permite integrar API Connectivity Manager en sus pipelines de CI/CD. En esta publicación usamos la interfaz de usuario para ilustrar algunos flujos de trabajo comunes.

API Connectivity Manager admite dos tipos de espacios de trabajo: infraestructura y servicios. Los equipos de operaciones de plataforma utilizan los espacios de trabajo de infraestructura para incorporar y administrar infraestructura compartida en forma de clústeres de API Gateway y clústeres de portales para desarrolladores. Los espacios de trabajo de servicios son utilizados por los desarrolladores de API para publicar y administrar API y documentación.

Para configurar una infraestructura compartida, primero agregue un espacio de trabajo de infraestructura. Haga clic en Infraestructura en la columna de navegación izquierda y luego en el botón + Agregar en la esquina superior derecha de la pestaña. Dale un nombre a tu espacio de trabajo (aquí es una oración de equipo : un equipo imaginario que construye un simple "¡Hola, mundo!"). (API).

A continuación, agregue un entorno al espacio de trabajo. Los entornos contienen clústeres de API Gateway y clústeres de portales para desarrolladores. Haga clic en el nombre de su espacio de trabajo y luego en el ícono … en la columna Acciones ; seleccione Agregar en el menú desplegable.

El panel Crear entorno se abre como se muestra en la Figura 2. Complete el campo Nombre (y opcionalmente, Descripción ), seleccione el tipo de entorno (producción o no producción) y haga clic en el botón + Agregar para la infraestructura que desea agregar (clústeres de API Gateway, clústeres de Developer Portal o ambos). Haga clic en el botón Crear para terminar de configurar su entorno. Para obtener instrucciones completas, consulte la documentación de API Connectivity Manager .

Darle agencia a los equipos

Proporcionar una separación lógica para los equipos por línea de negocio, región geográfica u otro límite lógico tiene sentido, siempre y cuando eso no los prive del acceso a las herramientas que necesitan para tener éxito. Tener acceso a una infraestructura compartida no debería significar que los equipos tengan que preocuparse por las actividades a nivel global. En lugar de ello, desea que se concentren en definir sus propios requisitos, trazar una hoja de ruta y construir sus microservicios.

Para ayudar a los equipos a organizarse, los equipos de Platform Ops pueden proporcionar espacios de trabajo de servicios para que los equipos organicen y operen sus servicios y documentación. Estos crean límites lógicos y brindan acceso a diferentes entornos (desarrollo, prueba y producción, por ejemplo) para desarrollar servicios. El proceso es como crear el espacio de trabajo de infraestructura que creamos en la sección anterior .

Primero, haga clic en Servicios en la columna de navegación izquierda y luego en el botón + Agregar en la esquina superior derecha de la pestaña. Proporcione un nombre a su espacio de trabajo (aquí, api-sentence para nuestro servicio “Hola, mundo”) y, opcionalmente, proporcione una descripción e información de contacto.

En este punto, puedes invitar a los desarrolladores de API a comenzar a publicar servidores proxy y documentación en el espacio de trabajo que has creado para ellos. Para obtener instrucciones completas sobre la publicación de servidores proxy de API y documentación, 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 el empoderamiento de los equipos para tomar decisiones que impulsen la agilidad. Es necesario establecer una separación clara de responsabilidades definiendo las configuraciones globales impuestas por Platform Ops y estableciendo “límites” que definan las herramientas que usan los desarrolladores de API y las decisiones que pueden tomar.

API Connectivity Manager proporciona una combinación de políticas globales (aplicadas a la infraestructura compartida) y controles granulares administrados a nivel de 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 : acceso seguro a las API con una política de OpenID Connect
• Encabezados de respuesta : incluya o excluya encabezados en la respuesta
• Tamaño del cuerpo de la solicitud : limite el tamaño de las cargas útiles de la API entrante
• TLS entrante : establezca la política para conexiones TLS con clientes API
• TLS de backend : proteja la conexión a los servicios de backend con TLS

Las políticas de proxy de API disponibles en API Connectivity Manager incluyen:

• Métodos HTTP permitidos : define qué métodos de solicitud se pueden utilizar ( GET , POST , PUT , etc.)
• Control de acceso : acceso seguro a las API mediante diferentes técnicas de autenticación y autorización (claves API, autenticación básica HTTP, tokens web JSON)
• Comprobaciones de estado del backend : ejecute comprobaciones de estado continuas para evitar solicitudes fallidas a los servicios del backend.
• CORS : permite el acceso controlado a recursos por parte de clientes de dominios externos
• Almacenamiento en caché : mejore el rendimiento del proxy API con políticas de almacenamiento en caché
• Encabezados de solicitud de proxy : pasar encabezados de selección a los servicios de backend
• Limitación de velocidad : limite las solicitudes entrantes y proteja las cargas de trabajo de la API

En el siguiente ejemplo, utilizamos la interfaz de usuario para definir una política que protege 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 en ese entorno.

En la fila del clúster de API Gateway al que desea aplicar una política, haga clic en el ícono … en 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.

Para aplicar la política TLS Backend , haga clic en el ícono … en el extremo derecho de su fila y seleccione Agregar política en el menú desplegable. Complete la información solicitada, cargue su certificado y haga clic en Agregar . Luego haga clic en el botón Guardar y enviar . A partir de ahora, el tráfico entre el clúster API Gateway y los servicios backend está protegido con TLS. Para obtener instrucciones completas, consulte la documentación de API Connectivity Manager .

resumen

La planificación e implementación de la gobernanza de API es un paso crucial para garantizar el éxito de su estrategia de API. Al trabajar hacia un modelo distribuido y confiar en la gobernanza adaptativa para abordar los requisitos únicos de diferentes equipos y API, puede escalar y aplicar una gobernanza uniforme sin sacrificar la velocidad y la agilidad que hacen que las API y los entornos nativos de la nube sean tan productivos.

Introducción

Comience 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 NGINX App Protect para proteger sus API.