Camino de evolución sostenible para la conectividad entre servicios de las instituciones financieras

Camino de evolución sostenible para la conectividad entre servicios de las instituciones financieras

Marca de tiempo: 8 de enero de 2024 5:29 a. M.
Camino de evolución sostenible para la conectividad entre servicios de institutos financieros PlatoBlockchain Data Intelligence. Búsqueda vertical. Ai.

Las instituciones financieras, que buscan capitalizar las oportunidades basadas en ecosistemas, requieren sistemas y servicios sólidos que aborden los requisitos de seguridad, resiliencia, escalabilidad y agilidad. La arquitectura nativa de la nube moderna 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 el dominio para mejorar los requisitos de escalabilidad, negocios y agilidad operativa. Los microservicios se han convertido en un elemento clave en el tejido de integración del ecosistema de las instituciones financieras.

Sin embargo, la comunicación entre microservicios tiene muchas preocupaciones transversales, como el descubrimiento de servicios, la seguridad, la gestión de políticas y la observabilidad, que deben abordarse. Existen múltiples enfoques que han ido evolucionando para abordar preocupaciones transversales de la arquitectura de microservicios, desde bibliotecas comunes hasta varios tipos de malla de servicios.

A medida que aumenta el número de microservicios en una institución financiera, es imperativo identificar un camino óptimo para manejar las preocupaciones transversales. Se destacan pocas opciones en evolución junto con las consideraciones apropiadas.

Bibliotecas comunes:

Para evitar la duplicación de código, las implementaciones iniciales de microservicios de los institutos financieros aprovecharon bibliotecas comunes que encapsulaban características transversales. Sin embargo, estas bibliotecas comunes dependen del lenguaje de programación.

Malla de Servicio con Sidecars:

Una malla de servicios proporciona funcionalidad de red de aplicaciones que incluye descubrimiento de servicios, observabilidad, enrutamiento de tráfico y seguridad. El enfoque de malla de servicios a través de sidecars proporciona esta funcionalidad a través del concepto de plano de control y un plano de datos programable. El plano de control ayuda en la gestión central y la configuración de políticas de la malla. La comunicación entre el servicio de tiempo de ejecución y el servicio se enrutaría a través de servidores proxy sidecar del plano de datos.

Algunos de los productos de malla de servicios 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 malla de servicios específicas como plano de datos.

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

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

 Malla de servicio sin sidecar:

Si bien el plano de datos que incluye sidecars proporciona valor, para mitigar sus limitaciones, varias entidades de la industria están probando varias opciones innovadoras, como el plano de datos sin sidecar.

Una de esas opciones de malla de servicios sin sidecar es la malla de servicios Cilium, que utiliza eBPF (filtro de bolsillo extendido de Berkeley) y proxy enviado. Cilium también es una CNI (Interfaz de red de contenedores) que ayuda con los requisitos de red, seguridad y observabilidad de los contenedores en un clúster de Kubernetes mediante el uso de la funcionalidad eBPF a nivel de kernel.

eBPF facilita la ejecución de programas personalizados dentro del kernel en función de eventos. Como eBPF se ocupa de los bolsillos de la red, puede ayudar con las métricas de observabilidad, seguridad y redes. El camino de paso de los bolsillos de la red sería más corto con eBPF y daría como resultado una latencia más baja, ya que el camino no implicaría pasar por reglas de iptable. eBPF también puede ayudar en el cifrado de la capa de red a nivel de nodo. El verificador de eBPF garantiza que el programa eBPF sea seguro para ejecutarse en un kernel.

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

En el caso de Istio, la malla ambiental de Istio está evolucionando como un plano de datos alineado con un enfoque sin sidecar. La malla ambiental de Istio aborda la comunicación de servicio a servicio dividiéndola en características seguras de capa 4 y políticas y comportamiento de capa 7.

La malla ambiental de Istio maneja los problemas de conectividad de la capa 4 entre 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 se encarga de la autorización del servicio de capa 4, la seguridad mediante mTLS, la observabilidad mediante registros TCP y la gestión del tráfico de TCP.  

Las características de la capa 7 de malla ambiental de Istio se manejan mediante el proxy de waypoint. El proxy Waypoint, basado en envoy, protege a través de políticas de autorización de capa 7 enriquecidas, ayuda en la observabilidad a través de métricas y rastreo http, así como políticas de gestión de tráfico como prueba canary y prueba de caos. El procesamiento de la capa 7 ocurre en un proxy de waypoint, en pods programados por separado como un recurso de espacio de nombres compartido y se pueden escalar automáticamente.

El plano de control de Istio atiende tanto al plano de datos de malla ambiental con sidecar como sin sidecar, proporcionando así opcionalidad. Si bien la malla ambiental será útil para muchos casos de uso de la malla de servicios, hay escenarios en los que los complementos seguirán siendo útiles, como el cumplimiento y el ajuste del rendimiento.

 Impacto en las operaciones:

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

Si bien el manejo de las preocupaciones transversales de los microservicios a través de un enfoque de bibliotecas comunes 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 en escenarios de microservicios políglotas y fomenta una configuración consistente en una gran cantidad de microservicios. Implica un mayor consumo de recursos y gastos operativos debido a los sidecars. La opción sin sidecar proporciona el beneficio del procesamiento de nivel L4 a nivel de nodo y el procesamiento L7 a nivel de espacio de nombres para las funciones de enrutamiento de tráfico. La opción sin sidecar tiene el potencial de simplificar el esfuerzo operativo con escala, junto con un consumo de recursos relativamente menor.

Con el creciente número de microservicios nativos de la nube políglotas en los institutos financieros, la escalabilidad operativa aumentará progresivamente desde el enfoque de bibliotecas comunes hasta el enfoque de malla de servicios con sidecars y el de malla de servicios con enfoque sin sidecars.

Conclusión:

Si bien las principales iniciativas nativas de la nube de los institutos financieros están adoptando implementaciones de malla de servicios con bibliotecas comunes y un enfoque basado en sidecar, las opciones sin sidecar están evolucionando rápidamente para mitigar sus deficiencias.

Por lo tanto, las instituciones financieras innovadoras, mientras evolucionan su enfoque de integración de servicios, necesitan experimentar con nuevas opciones de malla de servicios basadas en eBPF para obtener los beneficios óptimos de una mejor eficiencia operativa, seguridad y TCO (costo total de propiedad). La implementación de una malla de servicios correcta y sin sidecar con tecnología eBPF ayudará a posicionar la infraestructura de servicios del instituto financiero en un camino sostenible.

Sello de tiempo:

Mas de fintextra