Deployment Best Practices
The following best practices are published to help you understand and make conscious decisions about the deployment of your IPF flows, applications and complete solutions.
Flow Deployment Considerations
IPF provides flexibility in how flows will be deployed; either multiple flows in a single service OR each flow in a separate deployable service. Deploying flows separately allows them to be scaled, resourced, tested and deployed separately.
Rationale - Decisions about how to deploy flows should be driven by the non-functional requirements and should allow maximum flexibility in how to meet those requirements.
Implications
-
It is important to consider the required NFRs/TPS for specific flows/services early in the project so that:
-
Services can be designed accordingly
-
Infrastructure can be provisioned and tested early in the project to de-risk performance issues later on
-
-
Flows that need to process a high volume of payments (high TPS), will likely be hosted separately from low volume flows so that the services can be scaled independently
-
Flows for payments with a similar processing profile may be hosted in the same physical application to save on infrastructure costs
-
If there is ambiguity about NFRs and future requirements, then it is normally advisable to 'start simple' with fewer physical applications. It is always possible to split processing flows into separate applications later in the project/roadmap.
Multiple Flow Deployment Options
| Deployment Option | Pros | Cons |
|---|---|---|
Multiple flows deployed in same application (from the same MPS project) |
Allows direct flow-flow calls Less infrastructure required to deploy applications:
|
Load on one flow may affect performance of others if resources are lacking No ability to scale applications separately |
Deployed as separate applications (From separate MPS projects) |
Applications can be scaled separately according the resource requirements of the flows Processing for different behaviour profiles can be split between different applications |
Flows should be split into separate MPS projects Kafka (or some other infrastructure transport) required to call from one flow to another More infrastructure required
|
Deploying Flow Changes
Once you have a flow deployed to a live environment and processing transactions, care needs to be taken when deploying changes or updates. You are advised to use flow versioning
Rationale - Attempting to deploy changes once a flow is live and processing transactions runs the risk of disrupting in-flight transactions. For example changing the event behaviour to add transitions. IPF supports flow versioning to avoid this and ensure transactions complete on the version they were first initiated on.
Implications - Read the considerations for Handling In-Flight Transactions
Scaling
IPF flows that are split into separate IPF processing applications can be deployed separately in different Akka clusters [eg initiation vs execution]. This will allow individual scaling of flows that have higher throughput requirements:
-
Scaled vertically - assigned appropriate resources (CPU, RAM etc)
-
Scaled horizontally - more nodes in the cluster
It is also possible to start simpler, with fewer applications, and split into separate applications as the need arises (e.g. single application cluster for execution to start with)
Flows that can use a common code base, may be deployed multiple times, for example in different regions, if dictated by the non-functional requirements.
| If the same IPF processing application was to be deployed in different regions in different Akka clusters, then they would need to be deployed on logically separated infrastructure - i.e. separate Mongo collections and Kafka topics (to stop them from consuming the same messages/data) |
This will also help achieve a more granular deployment strategy, where different regions/products receive new versions at different times (e.g. staggered deployments). This decreases dependencies across business areas where upgrades can be received according to business schedules & priorities.
Observability
IPF provides a number of observability tools, make sure that these are configured correctly early in the development cycle.
Rationale - The Grafana dashboards that IPF provides out of the box for monitoring the health of the application which will be invaluable to operational staff when attempting to resolve performance issues in both the test and production environments.
It is also advisable to use a logging framework to monitor IPF application logs to detect any other anomalies in the system.
These above techniques can provide early alerts for potential problems with the system and assist in finding a resolution.
Implications - Make sure that the monitoring tools are configured correctly and working in all relevant environments.
Ensure that the monitoring and alerting requirements of the system are well understood; this may mean that new dashboards are required to augment those provided with IPF out of the box.