...
One important aspect of assessing your requirements is to avoid over specifying the resources needed to run PhixFlow, as much as to ensure that sufficient resources are provided. In most virtualised environments, which the vast majority of PhixFlow installations will run in, altering CPU and memory are straightforward. We have provided guide sizings belowsizing in this section, but it is possible to set resources at a starting level, and increase and or decrease in response to the observed perforamnce performance of the system. In this way, you can control costs in balance with meeting the needs of your solution. Establshing the requirements clearly at this stage helps to find this balance and measure the system against these requirements as the solution is established.
The table below illustrates where there are strong links between requirements and platform planning outcomes, but it is useful to consider
| Planning outcome | Description | Main input requirements |
|---|---|---|
| Platform software choice | 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 corporate standards governing systems like PhixFlow. |
|
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. |
|
Network topology | In most cases, the strongest influence on network topology is balancing access for PhixFlow users against security considerations.
Common network topologies are discussed here: Network topology, but as long as you meet the the Minimum system requirements, you can adopt any topology you wish. |
|
| Server specifications | 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?
Server specifications are discussed here: Server Specification and Access |
|
| Backups | Establishing your resilience to system and data loss, and specifiying specifying 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) |
|