Cómo maneja IPF la realidad

IPF usa Akka y, como indica su documentación oficial, emulando Erlang, Akka hace explícita la falibilidad de la comunicación mediante el paso de mensajes; por lo tanto, no intenta mentir y emular una abstracción con fugas y el IPF SDK ha hecho suya esta filosofía.

Al comunicarse con flows construidos por IPF DSL, los desarrolladores de IPF siempre deben considerar fallos de red. El código generado por IPF DSL proporciona reintentos configurables y controles de idempotencia por defecto, dando a los desarrolladores mecanismos para construir semánticas de entrega exactamente-una-vez cuando se trata de inputs de flow.

Además, IPF DSL permite transiciones de flow en timeouts, promoviendo así la gestión de timeouts a ciudadano de primera clase: a menudo, qué hacer en caso de timeouts causados por ausencia de respuesta de un sistema externo es una decisión de negocio y no técnica. Configurando timeouts, los desarrolladores pueden crear diversas políticas de timeouts y asegurar así que se cumplan las demandas de negocio ante problemas de red.

Dado que en una aplicación típica de orquestación IPF los flows se integran estrechamente con el IPF Connector Framework, aprovechar retries y timeouts tanto en send como en receive connectors puede ayudarte a lidiar con interrupciones temporales de red, mientras que para interrupciones más largas puede ser más aplicable una estrategia de reintentos basada en mensajes enviados a un dead letter appender.

Akka Cluster también viene con soporte incorporado para particiones de red (y caídas de máquina, que se tratan igual que inalcanzable por red):

Por último, debes aplicar a tus flows las mismas prácticas de desarrollo que a tus funciones: prefiere flows de orquestación más cortos que hagan una cosa bien. Flows complejos —que constan de muchos estados y elevan muchos domain events durante su vida— a menudo tardan más en recuperarse cuando Akka los distribuye a nuevos nodos. Una buena regla es apuntar a flows con no más de 20 estados; por ejemplo, si realizar un chequeo de sanciones en tu flow de pagos consta de 8 estados, considera extraer esa lógica a un flow propio, especialmente si es algo reutilizable por otros flows.

IPF Connector Framework está construido sobre Akka Streams, que —similar a otras implementaciones de Reactive Streams— proporcionan mecanismos de back-pressure para manejar latencias variables y asegurar un flujo de datos suave. Akka Streams permite definir pipelines de procesamiento de datos que pueden adaptarse a la velocidad del componente más lento, evitando saturar cualquier parte del sistema y asegurando procesamiento eficiente incluso con latencia.

Además, tanto Akka como IPF SDK se han construido alrededor de operaciones no bloqueantes, asegurando que no se desperdicien recursos del sistema esperando I/O, sino que se usen para procesar trabajo pendiente.

Dado que rara vez las operaciones de negocio querrán esperar para siempre a que una operación termine, al considerar la latencia en tus soluciones debes aplicar el mismo pensamiento de reintentos y timeouts ya descrito en Network is Reliable.

Finalmente, a menudo la mejor forma de lidiar con la latencia de red es no usar la red: cachear localmente datos usados frecuentemente en lugar de hacer llamadas remotas repetidas suele ser una gran manera de reducir el impacto de la latencia. IPF proporciona su propia biblioteca de cache in-memory, pero no impide usar cualquier otra tecnología de caching que prefieras. Cuidado con el viejo dicho:

Muy similar a Latency is Zero, los mecanismos de back-pressure existentes permitirán que las soluciones con IPF SDK se ralenticen cuando la latencia aumente debido a que el bandwidth lleve la red al límite. Pero el IPF SDK también ofrece enfoques proactivos para controlar el bandwidth antes de que empiece a causar problemas:

Asumir que la red es segura a menudo lleva a descuidar el cifrado de datos en tránsito; sin cifrado, actores maliciosos pueden interceptar información sensible. Aunque una aplicación típica construida con IPF SDK normalmente no se ejecute dentro de una DMZ, aún hay decisiones conscientes de seguridad que puedes tomar para reducir riesgos.

Akka Remoting — el componente usado internamente por Akka Cluster y por IPF para comunicarse con los flows de IPF SDK— soporta cifrado a nivel de transporte, con el bonus añadido de soportar mTLS con certificados rotados frecuentemente cuando se ejecuta en Kubernetes.

Además de soportar cifrado a nivel de transporte en Akka, IPF SDK también permite añadir cifrado a nivel de transporte a otros componentes:

Por último, si los consumidores destino lo soportan, IPF Connectors permiten enviar y consumir payloads cifrados mediante stages de cifrado. Usar payloads cifrados con JMS y Kafka también asegura que los datos estén cifrados en reposo.

Como se mencionó, IPF SDK se apoya en Akka Cluster y sus plugins para bootstrap del clúster del servicio y luego adaptarse dinámicamente a cambios en la topología de red y máquinas, asegurando disponibilidad continua y escalabilidad. Akka Cluster y sus mecanismos de discovery (incluyendo el descubrimiento basado en MongoDB propiedad de IPF) pueden detectar automáticamente cuando los nodos se unen o abandonan el clúster y redistribuir datos y tareas en consecuencia. Esto asegura que el sistema permanezca operativo incluso cuando cambia la topología de red.

Si bien los componentes mencionados cubren cambios de topología "gráciles", al tratar con cambios no gráciles —es decir, caídas y fallos— la pérdida de mensajes, ausencia de respuesta o aumento de latencia son síntomas comunes, por lo que se tratan de forma similar a lo descrito en Network is Reliable y Latency is Zero.

Además, dado que IPF SDK pretende soportar la escritura de aplicaciones cloud-native por diseño, ofrece herramientas para ayudarte al desplegar en la nube:

A diferencia de las falacias anteriores, IPF SDK juega solo un papel de apoyo para ayudarte a superar los problemas de esta: el papel principal lo desempeñan las herramientas y prácticas de observabilidad y monitorización que hayas adoptado. Como se mencionó en Topology Doesn’t Change y Latency is Zero, IPF viene con amplio soporte de observabilidad, así como endpoints HTTP amigables con la automatización y cloud-native. Estos no solo te permiten hacer seguimiento de tus SLAs y KPIs, sino que también pueden ser usados por herramientas de alertas y monitorización para ayudarte a añadir automatización robusta en pipelines de CI/CD. Cuando tu CI/CD incluye todas tus aplicaciones y también abarca infraestructura, se vuelve posible realizar rollbacks automáticos de cambios breaking. Incluso sin automatización, la telemetría de IPF y Akka debería permitirte construir reglas de alerta y dashboards operativos que ayuden a identificar problemas.

Tu enfoque aquí será reducir el número de llamadas de red, el tamaño de los payloads enviados por el cable y mejorar la localidad de datos. Si todo esto te suena, ¡has estado prestando atención! El enfoque aquí es similar a cómo se maneja Bandwidth is Infinite. La única diferencia es qué rastreas en tus herramientas de monitorización e informes: querrás identificar las métricas que se correlacionan con tus costes y usarlas primero para guiar optimizaciones y luego para vigilar cuidadosamente el presupuesto. Para despliegues en la nube, quizá quieras centrarte en infraestructura de red dedicada como NAT gateways y comunicación entre datacenters, ya que normalmente incurren en costes significativos de transferencia de datos.

Esta falacia fue una adición tardía a la lista por James Gosling y, en cierto modo, une todas las anteriores. La realidad es que las redes pueden incluir una mezcla de hardware, software, protocolos, configuraciones y costes, y todo ello puede cambiar en cualquier momento en la vida de tu aplicación.

Por lo tanto, las aplicaciones que construyas deben ser capaces de manejar network partitions o destinos que se vuelven inalcanzables, latencias cambiantes y congestiones repentinas, o requisitos de seguridad que se vuelven más estrictos de la noche a la mañana.