Versions Compared

Old Version 12

changes.mady.by.user Chris Welford

Saved on

compared with

New Version Current

changes.mady.by.user Zoe Baldwin

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 outcomeDescriptionMain 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.

  • Current infrastructure
  • Corporate 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 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 access via VPN)?
  • If you need to make PhixFlow available via the public internet, can you list the allowed 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
      • individuals as defined by applicable legislation
      • Financial data
Commerically
      • Commercially sensitive data

Common network topologies are discussed here: Network topology

Recovery (RPO, RTO)Resilience to system and data loss - Recovery Point Objective (RPO) and Recovery Time Objective (RTO)
  • Backups
Phyiscal location of usersIs there a large user base, and this is geographically scattered? If so, over what regions? Are a lot of the users home works, with variable and unpredictable home internet connections?
  • Network topology
  • Physical location/ cloud provider
Performance requirements

, but as long as you meet the Minimum system requirements, you can adopt any topology you wish.

  • Security considerations
  • Physical location of users
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?

  • Target times for key processes and operations
  • Tolerance to variance against these targets
Current infrastructureFit it with current standards and skills
  • Physical location/ cloud provider
  • Platform software choice
Coroporate software licensingCost considerations - can we use existing licences for operating system and database?
  • Platform software choice

The following links cover each of the above planning outcomes.

System planning

...

Server specifications are discussed here: Server Specification

  • Performance requirements
  • Data volumes
  • Processing volumes
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)

  • Recovery (RPO, RTO)