Page Comparison

On the whole, there is little difference operating PhixFlow on any combination of valid platform software - that is the combination of operating system and database. This is true for both performance, and general maintenance.

This decision is generally driven by what in-house skills you already have in place, corporate software licensing (and therefore the cost of the deployment, and the support options in place), and coroporate standards governing systems like PhixFlow.

• Current infrastructure
• Coroporate software licensing

Physical location/ cloud provider

In terms of management of PhixFlow from an administration point of view, and performance on back office tasks, the choice of physical deployment makes little difference. However, if you have a choice over where PhixFlow is deployed, the size, physical distribution and circumstances of your user base may be worth consideration. If your user base is large, globally distributed, and in some cases working with variable and unpredictable home internet connections (e.g. you have a lot of home workers), working with a public cloud is more likely to allow you to support fast connections to the service, wherever it is situated in the world.

• Physical location of users

Network topology

In most cases, the strongest influence on network topology is balancing access for PhixFlow users against security considerations.

• Does your PhixFlow solution need to be available on the public internet? Or can you confine it to a corporate network (including allowing remote acces via VPN)?
• If you need to make PhixFlow available via the public internet, can you restrict the source IP addresses?
• What is an acceptable level of risk:
  • Does the solution handle sensitive data?
    • Personally identifiable information (PII)
    • Extra sensitive data about individiuals as defined by applicable legislation
    • Financial data
    • Commerically sensitive data

Common network topologies are discussed here: , but as long as you meet the Minimum system requirements, you can adopt any topology you wish.

• Security considerations
• Physical location of users

It may be useful to specify some targets, or at an early stage, reasonable expectations, for performance of the system, in particular to human interaction - e.g. on the application that will be built in PhixFlow, how long should certain key actions take when a button is pressed?

• Target times for key processes and operations
• Tolerance to variance against these targets

Server specifications are discussed here: Server Specification and Access

• Performance requirements
• Data volumes
• Processing volumes

Establishing your resilience to system and data loss, and specifiying these with the Recovery Point Objective (RPO) and Recovery Time Objective (RTO), are useful at an early stage to help determine the backup strategy.

Typically, at an early stage of the process, a high level description of the backup strategy is enough, and it is not necessary to determine the precise details of the process - this is usually done at the infrastructure planning stage (see Backup).

However, in some cases, if it is known that a particular backup solution is required, this may have an impact on the storage and performance of the servers (Server Specification and Access)

• Recovery (RPO, RTO)