Gestión de API en entornos híbridos y multi-cloud: desafíos y decisiones

1. Multi-Cloud y Hybrid Cloud

Microservicios se ha convertido en un método popular de arquitectura de software donde las organizaciones descomponen sus productos en microservicios individuales basados en su comprensión de su propio negocio y utilizando métodos científicos como el diseño impulsado por el dominio. La estructura organizativa también se ajusta para alinearse con la arquitectura de microservicios, siguiendo la Ley de Conway, para apoyar el desarrollo iterativo del negocio.

En el pasado, las organizaciones construían sus propios centros de datos para desplegar sus productos. Estos centros de datos podían estar ubicados en instalaciones alquiladas o compradas, y las organizaciones eran responsables de gestionar la infraestructura compleja, como switches, servidores, almacenamiento, racks y otros hardware. También necesitaban lidiar con los problemas causados por cortes de energía, altas temperaturas en los racks, caídas de servidores, etc. Lidiar con tales problemas a menudo requiere muchos recursos humanos y financieros sin lograr buenos resultados. Como resultado, el SLA (acuerdo de nivel de servicio) de los productos propios de las organizaciones a menudo no cumple con la promesa a los clientes, lo que resulta en compensaciones.

Con el auge de la nube, las personas se han acostumbrado cada vez más a desplegar sus negocios en nubes públicas. Las nubes públicas ayudan a los usuarios a abstraer los detalles de la infraestructura de hardware, permitiendo a los ingenieros centrarse en desplegar, mantener y desarrollar su negocio. Sin embargo, además de la conveniencia que proporciona la nube, su auge y uso también traen otros problemas para los usuarios:

• Lock-in: Cuando un producto de un proveedor de nube está profundamente integrado en un negocio, mover el negocio a otra nube o salir de la nube por completo se vuelve bastante desafiante. Esto es particularmente común para los productos PaaS o SaaS que tienen un fuerte vínculo con el negocio. Desafortunadamente, esto a menudo ocurre cuando un negocio está en un período de rápido crecimiento y los tomadores de decisiones pasan por alto el efecto vinculante de usar productos en la nube.
• Problemas de disponibilidad: El principio de diversificación se aplica aquí, lo que significa que no ponemos todos los huevos en una sola canasta. Durante la fase de escalamiento de un negocio, las organizaciones a menudo priorizan lanzar productos rápidamente y capturar cuota de mercado, descuidando la infraestructura. Esto puede resultar en cortes de energía o cortes de cables en una región de la nube, afectando negativamente al negocio.

Como resultado, las personas se están acostumbrando cada vez más a usar múltiples nubes públicas o construir nubes privadas además de usar nubes públicas para evitar los problemas mencionados anteriormente. Este enfoque se conoce comúnmente como "multi-cloud" y "hybrid cloud".

"Multi-cloud" se refiere al uso simultáneo de múltiples nubes públicas, desplegando negocios de manera espejo o heterogénea en estas nubes. Utilizará servicios estándar tanto como sea posible (para evitar el vendor lock-in). Debido al uso de multi-cloud, cuando una nube se vuelve no disponible, el impacto en el negocio puede minimizarse, y se podría garantizar la continuidad del negocio modificando la resolución DNS y habilitando una nube de respaldo.

"Hybrid cloud" se refiere a organizaciones que, además de usar una o más nubes públicas, también tienen sus propias nubes privadas (o centros de datos). En este escenario, algunos servicios podrían desplegarse en nubes privadas, mientras que otros pueden desplegarse en nubes públicas. O todos los servicios se despliegan en la nube, y la nube privada se encarga de la gestión y el monitoreo. En cualquier caso, la flexibilidad y disponibilidad del despliegue de software mejoran enormemente después de adoptar el modelo "multi-cloud" o "hybrid cloud".

Sin embargo, implementar estrategias de "multi-cloud" y "hybrid cloud" puede hacer que la gestión de microservicios basados en la nube sea más compleja. Un desafío común es la gestión de API, ya que muchos microservicios dependen de API para la comunicación. Por lo tanto, al desplegar microservicios, sus API deben exponerse externamente para permitir conexiones con partes externas y proporcionar servicios.

2. La Necesidad de la Gestión de API en Escenarios Multi-Cloud y Hybrid Cloud

Como sabemos, una buena puerta de enlace de API es crucial para gestionar las API de microservicios. La puerta de enlace de API permite la exposición segura y eficiente de las API de microservicios. Sin embargo, al implementar estrategias de "multi-cloud" y "hybrid cloud", la necesidad de una puerta de enlace de API va más allá de su funcionalidad básica. Específicamente, consideraciones como:

Si admite la gestión de múltiples clústeres

Como se mencionó anteriormente, al implementar estrategias de "multi-cloud" o "hybrid cloud", los servicios desplegados en cada nube o centro de datos privado pueden variar significativamente. Como resultado, los usuarios pueden necesitar desplegar clústeres separados de puertas de enlace de API en cada nube con diferentes configuraciones, certificados y claves API. Supongamos que la puerta de enlace elegida no admite la gestión de múltiples clústeres. En ese caso, puede causar dificultades significativas en la gestión de API, especialmente durante períodos de expansión del negocio cuando el número y la escala de los clústeres de puertas de enlace aumentan.

En tales casos, un producto de puerta de enlace de API que admita la gestión de múltiples clústeres puede reducir significativamente los costos de gestión para los administradores.

1. Los usuarios tienen acceso a una consola unificada para seleccionar el clúster que desean configurar y monitorear. También pueden poner un clúster de puerta de enlace en línea o fuera de línea, dependiendo de la situación actual del despliegue del negocio.
2. Los usuarios pueden ver el estado de funcionamiento de todos estos clústeres de puertas de enlace de API en la consola, incluyendo QPS común, latencia, uso de CPU y memoria del clúster de puerta de enlace, etc.

Si admite colaboración

Con el rápido desarrollo del negocio, un pequeño número de administradores de puertas de enlace de API puede necesitar ayuda para gestionar y mantener todos los clústeres de puertas de enlace de API por su cuenta. Mientras tanto, muchas configuraciones de puertas de enlace, como agregar rutas y configurar complementos, pueden ser manejadas por desarrolladores, reduciendo la necesidad de una amplia participación del administrador. Por lo tanto, si admite "colaboración" se vuelve esencial para la gestión.

Específicamente, los administradores pueden invitar a otros miembros de la organización a unirse a la gestión del clúster de puertas de enlace de API utilizando RBAC (Control de acceso basado en roles) u otras estrategias para asignar diferentes permisos a los miembros del equipo. Por ejemplo, establecer el rol de Organization Admin (capaz de realizar cualquier operación) para el administrador y Service Admin (capaz de mantener solo algunos servicios y rutas) para el desarrollador general. Este enfoque garantiza la seguridad de las operaciones mientras implementa la colaboración. También facilita la recuperación oportuna de cuentas o la modificación de permisos en caso de rotación de empleados o cambios en los puestos de trabajo.

Si puede ejecutarse en cualquier infraestructura

A medida que las tecnologías de contenedores y orquestación de contenedores maduran, muchos microservicios están pasando de máquinas virtuales a ejecutarse en Kubernetes. Esto significa que los usuarios pueden usar Kubernetes, máquinas virtuales tradicionales o incluso máquinas físicas, como en sus centros de datos privados. Supongamos que el producto de puerta de enlace de API elegido por el usuario es rico en características y cumple con las necesidades del negocio, pero está limitado por la infraestructura subyacente o carece de herramientas de instalación maduras. En ese caso, puede crear un desafío para el usuario, ya sea renunciar a usarlo o llevar a cabo un desarrollo adicional para permitir que la puerta de enlace de API se ejecute en cierta infraestructura. De cualquier manera, esto resultará en costos adicionales de uso.

3. Decisiones

Como se discutió, se vuelve extremadamente vital elegir la puerta de enlace de API correcta en el contexto de escenarios de "multi-cloud" y "hybrid cloud". Se enumeran algunas opciones comunes, y los usuarios deben analizarlas en función de sus escenarios reales y planes futuros.

Diferentes soluciones en diferentes nubes

Por lo general, cada proveedor de nube pública ofrece su propia solución de puerta de enlace de API integrada, y los usuarios pueden considerar comprar una solución de puerta de enlace de API para cada nube.

Las ventajas incluyen:

1. Costo de uso extremadamente bajo, sin necesidad de despliegue o mantenimiento.
2. Por lo general, admite el pago por uso; el uso temprano puede requerir solo costos mínimos.

Las desventajas incluyen:

1. El uso de puertas de enlace de API en diferentes nubes a menudo es incompatible entre sí, por lo que completar la misma configuración requiere diferentes rutas.
2. Las características del producto no son simétricas entre diferentes proveedores. Por ejemplo, un proveedor puede admitir mTLS mientras que otro no.
3. En el escenario de "hybrid cloud", puede ser necesario elegir otra puerta de enlace de API de código abierto o comercial y desplegarla en la nube privada del usuario.

Al usar este enfoque, lograr una experiencia de usuario consistente en diferentes proveedores de nube puede requerir personalización del producto, el desarrollo de una herramienta de sincronización de configuración y la abstracción de detalles subyacentes. Esto puede implicar investigación, análisis y desarrollo adicionales por parte del usuario. Los usuarios pueden encontrar problemas de compatibilidad y funcionalidad limitada, y solo podrían usar algunas características comunes de los productos de puerta de enlace de API. Además, también se debe tener en cuenta la posibilidad de fallos de sincronización.

Por supuesto, los usuarios también pueden repetir manualmente la configuración de cada puerta de enlace de API en cada nube (si pueden tolerarlo).

Solución de puerta de enlace de API de código abierto

Como alternativa a usar diferentes soluciones en diferentes nubes, los usuarios pueden considerar usar soluciones de puerta de enlace de API de código abierto como Apache APISIX, Kong, Tyk, Traefik, etc. Este enfoque permite a los usuarios usar la misma puerta de enlace de API en todas las nubes, incluidos los centros de datos privados, evitando así problemas de compatibilidad entre diferentes soluciones. Una puerta de enlace de API de código abierto madura y robusta puede ayudar a los usuarios a resolver muchos problemas en diferentes escenarios. Incluso si no cubre todos los escenarios, estas puertas de enlace de API generalmente permiten a los usuarios extenderlas de varias maneras. Por ejemplo, Apache APISIX permite a los usuarios extenderlo usando lenguajes y tecnologías como Go, Java, Python, Lua, WASM, etc.

Sin embargo, estas puertas de enlace de API de código abierto generalmente adoptan la estrategia de código abierto Open Core, donde las características principales del producto son de código abierto, pero las capacidades de gestión a nivel empresarial, como la consola visualizada, la gestión de múltiples clústeres, la auditoría, SSO (Single Sign-On), etc., a menudo son de pago (integradas en sus productos comerciales). Supongamos que los usuarios no quieren pagar. En ese caso, solo pueden elegir desarrollar su propia plataforma de gestión (también conocida como el plano de control de la puerta de enlace) para gestionar estas puertas de enlace de API, lo que significa que los usuarios necesitan contratar a un ingeniero a tiempo completo para asumir este trabajo de desarrollo.

Comprar un servicio SaaS de puerta de enlace de API de nivel empresarial

Supongamos que las puertas de enlace de API de código abierto cumplen con los requisitos en términos de funcionalidad, pero el costo de investigación y desarrollo propio no es aceptable. En ese caso, los usuarios también pueden considerar contactar a los fabricantes originales de este software de código abierto (como API7.ai detrás de Apache APISIX, Kong Inc detrás de Kong, y Tyk Inc detrás de Tyk, etc.). Estos fabricantes a menudo proporcionan diferentes productos y servicios de soporte de puertas de enlace de API de nivel empresarial. Especialmente en el escenario de "multi-cloud" y "hybrid cloud", estos fabricantes han lanzado sucesivamente sus productos SaaS. Los productos SaaS de la puerta de enlace de API a menudo se centran en el lado de la gestión, proporcionando una consola lista para usar sin preocuparse por dónde se despliega la instancia de la puerta de enlace de API (por supuesto, algunos servicios SaaS también admiten alojar la instancia de la puerta de enlace de API, pero esto a menudo también introduce otros problemas, como la latencia al representar la API).

Los servicios SaaS generalmente proporcionan un panel de control de puerta de enlace privado para cada inquilino, conectándolo a instancias de puerta de enlace desplegadas por el usuario (o alojadas por SaaS) utilizando estrategias como mTLS para garantizar la seguridad y privacidad de los datos, y proporcionar capacidades de gestión. Si bien la compra de un servicio SaaS puede requerir una inversión, puede ser más rentable que contratar a un ingeniero dedicado para mantener una puerta de enlace de API y su panel de control.

Por supuesto, la compra de servicios SaaS requiere precaución. Por lo tanto, antes de confirmar un pedido, los usuarios deben evaluar un servicio SaaS desde los siguientes aspectos:

1. ¿Puede este servicio SaaS satisfacer las necesidades de uso actuales y futuras?
2. ¿Es el proveedor del servicio SaaS profesional y confiable? ¿Qué tipo de casos de uso tienen?
3. ¿Es este servicio SaaS compatible, cumple con GDPR y tiene informes de auditoría SOC2?
4. ¿Este servicio SaaS tiene términos de SLA claros?
5. ¿Cómo se cobra este servicio SaaS? ¿Pueden los usuarios estimar el gasto futuro para un año o unos pocos años?

Desarrollo completamente propio

Supongamos que las soluciones de puerta de enlace de API de código abierto no satisfacen las necesidades reales del usuario. En ese caso, los usuarios pueden considerar desarrollar su propio producto exclusivo de puerta de enlace de API, lo que puede llevar mucho tiempo y recursos, y la estabilidad de la puerta de enlace también es una preocupación importante. Desarrollar una puerta de enlace de API no es tan difícil como implementar una base de datos relacional o un navegador, pero no es algo que se pueda hacer de la noche a la mañana; por lo tanto, el desarrollo propio puede considerarse "la peor estrategia". Como resultado, a menudo solo se considera como último recurso.

4. Conclusión

En un entorno nativo de la nube, gestionar API en escenarios de "multi-cloud" y "hybrid cloud" será un desafío para cada organización, incluso antes de adoptar estas estrategias. Por lo tanto, aunque este artículo presenta varias opciones, es esencial tener en cuenta que no existe una solución única para todos, y los usuarios deben seleccionar la opción que mejor se adapte a sus necesidades comerciales específicas y objetivos de desarrollo.

Para obtener más información sobre la puerta de enlace de API, visite nuestros blogs o contáctenos.