How IPF Handles the Reality

IPF uses Akka and as its official documentation states, by emulating Erlang Akka makes the fallibility of communication explicit through message passing, therefore it does not try to lie and emulate a leaky abstraction and IPF SDK has taken this philosophy to heart.

When communicating with flows built by IPF DSL, IPF developers should always consider network failures. The code generated by IPF DSL provides configurable retries and idempotency controls by default, giving developers the mechanisms for building exactly once delivery semantics when flow inputs are concerned.

Additionally, IPF DSL allows flow transitions on timeouts, thus promoting timeout management to a first-class citizen — more often than not, what to do in case of timeouts caused by no response from an external system is a business decision and not a technical one. By configuring timeouts developers can craft various timeout policies and thus ensure that business demands are met when faced with network issues.

Since in a typical IPF orchestration application the flows integrate closely with IPF Connector Framework, leveraging retries and timeouts in both send and receive connectors may help you deal with temporary network outages, while for longer outages a retry strategy built around messages sent to a dead letter appender may be more applicable.

Akka Cluster also comes bundled with built-in support for network partitions (and machine crashes, which are treated the same way as unreachable via the network):

Finally, you should apply the same development practices to your flows as you would with your functions: prefer shorter orchestration flows that perform one thing well. Complex flows — flows that consist of many states and raise a lot of domain events throughout their lifetime — often take longer to recover when Akka distributes them to new nodes. A good rule of thumb would be to aim for flows with no more than 20 states — for instance, if performing a sanctions check in your payment flow consists of 8 states, consider extracting that logic into a flow of its own, especially if it’s something that can be reused by other flows.

IPF Connector Framework is built on top of Akka Streams which — similar to other Reactive Streams implementations — provide back-pressure mechanisms to handle varying latencies and ensure a smooth data flow. Akka Streams allows for the definition of data processing pipelines that can adapt to the speed of the slowest component. This prevents overwhelming any part of the system and ensures that data is processed efficiently, even in the presence of network latency.

Additionally, both Akka and IPF SDK have been built around non-blocking operations, ensuring no system resources are being wasted on waiting for I/O operations to complete but are instead used to process pending work.

Seeing how it’s rarely the case that business operations will want to wait forever for an operation to complete, when considering latency in your solutions you should apply the same retry and timeout thinking already outlined in Network is Reliable.

Finally, often the best way to deal with network latency is not to use the network at all — caching frequently used data locally instead of making repeated remote calls is often a great way to reduce the impact of latency on your application. IPF provides its own in-memory caching library but doesn’t prevent you from using any other caching technology you may prefer. Beware of the old saying, though:

Very similar to Latency is Zero, the existing back-pressure mechanisms will enable IPF SDK solutions to slow down when latency increases due to bandwidth pushing the network to the brink. But the IPF SDK also offers proactive approaches to controlling the bandwidth before it starts causing issues:

Assuming the network is secure often leads to neglecting encryption of data in transit as without encryption, sensitive information can be intercepted by malicious actors. While a typical application built by IPF SDK will usually not be running within a DMZ, there are still security-conscious decisions that you could be making to reduce the security risks.

Akka Remoting — the Akka component used by Akka Cluster internally and by IPF to communicate with the IPF SDK flows — supports transport-level encryption, with an added bonus of supporting mTLS via frequently rotated certificates when running in Kubernetes.

In addition to supporting transport-level encryption in Akka, IPF SDK also lets you add transport-level encryption to other components:

Finally, if the target consumers support it, IPF Connectors allows sending and consuming encrypted payloads via encryption stages. Using encrypted payloads with JMS and Kafka also ensures data is encrypted at rest.

As mentioned before, IPF SDK relies on Akka Cluster and its plugins to bootstrap the service cluster and then dynamically adapt to changes in the network and machine topology, ensuring continuous availability and scalability. Akka Cluster and its discovery mechanisms (including the IPF-owned MongoDB-based discovery) can automatically detect when nodes join or leave the cluster and redistribute data and tasks accordingly. This ensures that the system remains operational even as the network topology changes.

While the mentioned components cover graceful topology changes, when dealing with non-graceful changes — i.e. crashes and failures — message loss, no response or increased latency are all common symptoms so they are dealt with in much the same way as outlined in Network is Reliable and Latency is Zero.

Additionally, since IPF SDK aims to support writing cloud-native applications by design, it offers some tools to help you when deploying into the cloud:

Unlike with previous fallacies, IPF SDK plays only a supporting role in helping you overcome the issues presented by this one — the main act are the observability and monitoring tools and practices you have adopted. As mentioned in Topology Doesn’t Change and Latency is Zero, IPF comes with extensive observability support, as well as automation-friendly and cloud-native HTTP endpoints. These not only enable you to keep track of your SLAs and KPIs but can also be used by alerting and monitoring tools to help you add robust automation into CI/CD pipelines. When your CI/CD includes all your applications and also encompasses infrastructure, it becomes possible to perform automated rollbacks of breaking changes. Even without automation, the IPF and Akka telemetry should allow you to build alerting rules and operational dashboards that can help identify issues.

Your focus here will be on reducing the number of network calls, the size of the payloads sent over the wire and also on improving data locality. If all that sounds familiar, you’ve been paying attention! The approach taken here is to how Bandwidth is Infinite is handled.

The only difference between the approaches is what you track in your monitoring and reporting tools — you will want to identify the metrics that correlate to your costs, and use them first to guide your optimizations, and then to keep a careful eye on the budget. For cloud deployments, you may want to focus on dedicated networking infrastructure like NAT gateways and cross-datacenter communication since those usually incur significant data transfer costs.

This fallacy was a late addition to the list by James Gosling and in a way it binds all the previous fallacies together. The reality is that networks can include a mix of different hardware, software, protocols, configurations, and associated costs and these can all change at any point in your application’s lifetime.

Therefore, the applications you build need to be able to handle network partitions or destinations becoming unreachable, changing latencies and sudden congestions, or security requirements becoming stricter overnight.