...
| Drawio | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
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 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 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 |
- Backups
- Network topology
- Physical location/ cloud provider
, but as long as you meet 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?
|
- Physical location/ cloud provider
- Platform software choice
- Platform software choice
The following links cover each of the above planning outcomes.
This is part of a process to go from planning to a full installed PhixFlow, which generally follows the following path
...
System planning
...
In many cases, a proof of concept installation of PhixFlow is created early on in discussions, with only minimal consideration of long term planning concerns, and this runs through to the point at which PhixFlow is made avaiable on the fully planned platform.
The proof of concept build can be on any platform set up that meets the minimum system requirements, but we have also provided an example installation that you can run through, based on the Ubuntu distribution on linux, and the MariaDB database, from initial server creation to a fully operational PhixFlow.
...
- System planning - establish planning outcomes, indicative server sizings, proposed network topology, security frameworks, location for solution
- Detailed infrastructure planning - servers configuration, including disk partitioning, network and network components, operating system
- PhixFlow installation - PhixFlow platform components (database, Java, Tomcat) and PhixFlow itself
This is by no means . In many virtualised platforms, databases will the either hosted as cloud native (or "serverless"), or will be created using pre-created image which includes partitioning of the server disks as well as the database installation itself.
System planning
...
Server specifications are discussed here: Server Specification |
| |
| Backups | Establishing your resilience to system and data loss, and 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) |
|