El camino hacia el desarrollo sostenible para la conexión entre los servicios de las instituciones financieras

Las instituciones financieras que buscan aprovechar las oportunidades basadas en los ecosistemas necesitan sistemas y servicios sólidos para satisfacer las demandas de seguridad, resiliencia, escalabilidad y agilidad. La arquitectura moderna nativa de la nube intenta abordar estas preocupaciones aprovechando la gestión de API, los microservicios, la automatización y las capacidades de la nube.

Las instituciones financieras están implementando cada vez más microservicios alineados con dominios para mejorar la escalabilidad, la agilidad empresarial y operativa. Los microservicios se han convertido en un elemento clave en el tejido integrador de los ecosistemas de las instituciones financieras.

Sin embargo, la comunicación de servicio a servicio entre microservicios tiene muchas preocupaciones indirectas, como el descubrimiento de servicios, la seguridad, la gestión de políticas y la observabilidad. Existen múltiples enfoques en evolución para abordar los problemas de la arquitectura de microservicios multiplataforma, desde bibliotecas comunes hasta diversos tipos de redes de servicios.

A medida que aumenta el número de microservicios en una institución financiera, es esencial identificar la forma más adecuada de gestionar las preocupaciones transversales. Pocas opciones de evolución destacan junto con las consideraciones adecuadas.

Bibliotecas comunes:

Para evitar la duplicación de código, las primeras implementaciones de microservicios por parte de instituciones financieras aprovecharon bibliotecas comunes que incluían características multifuncionales. Sin embargo, estas bibliotecas comunes dependen del lenguaje de programación.

Red de Servicios con Sidecar:

Una red de servicios proporciona funcionalidad de red de aplicaciones, incluido el descubrimiento de servicios, la observabilidad, el enrutamiento del tráfico y la seguridad. La red de servicios mediante el enfoque de sidecars proporciona esta funcionalidad a través de un plano de control y un plano de datos programables. El plano de control admite la gestión central de la red y la configuración de políticas. El servicio de ejecución se enrutaría a través de servidores proxy secundarios en el plano de datos al servicio de comunicación.

Algunos de los productos de servicios web más populares incluyen Istio, Linkerd, Consul y Kuma. Istio utiliza un plano de datos basado en enviados y Linkerd utiliza su propio micro proxy personalizado con funciones de red de servicio de destino como plano de datos.

Sin embargo, existen pocos desafíos con el enfoque de red de servicios basado en sidecar.

Si bien la red de servicios con el enfoque sidecar proporciona una separación clara entre la lógica empresarial y la funcionalidad de la red, así como seguridad granular, imponen la necesidad de inyectar un proxy sidecar en cada contenedor de aplicaciones de Kubernetes. El proxy sidecar primero debe estar disponible para que se produzca la comunicación de red. Procesar el tráfico HTTP mediante Sidecar es computacionalmente costoso. Por lo tanto, el enfoque basado en sidecar tiende a generar consumo de recursos, gastos operativos y costos más altos.

Red de servicios sin sidecar:

Si bien el plano de datos que involucra sidecar está aportando valor, para aliviar sus limitaciones, varias entidades de la industria están probando varias opciones innovadoras, como el plano de datos sin sidecar.

Una opción de red de servicios secundarios es la red de servicios Cilium, que utiliza eBPF (filtro de bolsillo extendido de Berkeley) y proxy enviado. Cilium también es una CNI (Container Networking Interface) que admite los requisitos de red, seguridad y observabilidad de los contenedores en un clúster de Kubernetes utilizando la funcionalidad eBPF a nivel del kernel.

eBPF facilita programas personalizados basados ​​en eventos que se ejecutan en el kernel. Debido a que eBPF se dirige a los bolsillos de la red, puede respaldar la observabilidad, la seguridad y las métricas de la red. El camino a través de los bolsillos de la red sería más corto con eBPF y la latencia sería menor porque el camino no pasaría por las reglas de iptable. eBPF también puede admitir el cifrado de la capa de red a nivel de nodo. El verificador eBPF garantiza que el programa eBPF sea seguro para ejecutarse en un kernel.

Se están agregando más funciones de red de servicios a Cilium y utiliza eBPF para la red de servicios y la conectividad L4 del proxy enviado se refiere a capacidades de gestión de tráfico de capa 7, como implementaciones canary y reintentos. Funciona con muchos aviones de control populares en la industria como Istio.

En el caso de Istio, la red del entorno de Istio está evolucionando como un plano de datos, alineado con el enfoque sin bordes. La red ambiental de Istio dirige la comunicación de servicio a servicio dividiéndola en funciones seguras de capa 4 y políticas y comportamientos de capa 7.

La malla ambiental de Istio maneja los problemas de conectividad de la capa 4 entre los dos servicios a través de un agente compartido llamado ztunnel, una capa superpuesta segura que se ejecuta como un pod en cada nodo del clúster de Kubernetes. Ztunnel maneja la autorización de servicios de Capa 4, la seguridad mediante mTLS, la observabilidad mediante registros TCP y la gestión del tráfico TCP.

Gestiona las características de la capa 7 de red del entorno Istio a través de servidores proxy de puntos de referencia. El proxy Waypoint, basado en Envoy, protege a través de 7 políticas de autorización de capas enriquecidas, admite la observabilidad a través de métricas y seguimiento http, así como políticas de gestión del tráfico como la prueba Canary y la prueba Chaos. El procesamiento de capa 7 se produce en el proxy de waypoint, los pods se programan individualmente como recursos de espacio de nombres compartidos y se pueden escalar automáticamente.

El plano de control de Istio proporciona un plano de datos de red para entornos con y sin sidecar, brindando así la opción. Si bien la red Giro será útil en muchos casos de uso de redes de servicios, hay escenarios en los que las tarjetas laterales seguirán siendo útiles, como el relleno y el ajuste del rendimiento.

Impacto en las Operaciones:

Las instituciones financieras deben considerar la cantidad de microservicios, las habilidades del equipo y diversos requisitos de calidad del servicio para identificar las compensaciones apropiadas para las opciones de red de servicios.

Aunque manejar las preocupaciones transversales de los microservicios a través de un enfoque de biblioteca común proporciona facilidad de uso, depende de los lenguajes de programación y requiere un esfuerzo operativo para mantenerse al día con las actualizaciones. El enfoque basado en Sidecar ayuda con los microservicios políglotas y promueve una configuración consistente en grandes conjuntos de microservicios. Conduce a un mayor consumo de recursos y un mayor costo operativo debido a los vehículos laterales. La opción Sidecarless proporciona el beneficio del procesamiento L4 a nivel de nodo y el procesamiento L7 a nivel de espacio de nombres para funciones de enrutamiento de tráfico. La opción Sidecarless tiene el potencial de simplificar el esfuerzo operativo a escala, junto con un consumo de recursos relativamente menor.

A medida que aumente el número de microservicios políglotas nativos de la nube en la institución financiera, la escalabilidad operativa aumentará gradualmente desde el enfoque de biblioteca común al enfoque de red de servicios con sidecar y de la red de servicios al enfoque sin sidecar.

Conclusión:

Si bien las implementaciones de redes de servicios con bibliotecas comunes y un enfoque basado en sidecar están siendo adoptadas por grandes iniciativas nativas de la nube de instituciones financieras, las opciones sin sidecar están evolucionando rápidamente para mitigar sus deficiencias.

Como tal, las instituciones financieras innovadoras, mientras desarrollan su enfoque de integración de servicios, deben experimentar con nuevas opciones de redes de servicios basadas en eBPF para lograr la mejor eficiencia operativa, seguridad y beneficios de TCO (costo total de propiedad). Al establecer una red de servicios laterales directos con tecnología EBPF, ayudará a colocar la infraestructura de servicios del instituto financiero en un camino sostenible.