Basic Scaling

The tiers of Sureview can be scaled vertically (making servers bigger) and horizontally (adding more servers) with the use of Network Load Balancing for multiple servers, SQL redundancy for the database, and SANs for the filestore.

Example: Single server

One server hosting all three tiers (NOTE: this is not recommended for production use)

• Resilience: none
• Scaling: vertical only, with downtime (server must be shut down to be made bigger)
• Complexity: low

Example: Dual server

Two identical redundant servers hosting all three tiers, with a Network Load Balancer for incoming communications, and SQL Failover used for the database (with a Witness server)

• Resilience: minimum
• Scaling: vertical only, without downtime (can make servers bigger, but can only ever have two)
• Complexity: medium

Example: Multi Server

All tiers scaled across redundant servers, with Network Load Balancers for incoming communications to the Application and Device Tiers, SQL AlwaysOn for a redundant database, and a SAN for a redundant File Store.

• Resilience: high
• Scaling: vertical and horizontal, without downtime (can make servers bigger and add more servers)
• Complexity: high

Regional Scaling

Sureview can also be scaled regionally, allowing Application and Device servers to be placed in regions close to local resources

• Resilience: good for all tiers except the database which still resides in one region (loss of connectivity between regions means one region cannot operate)
• Scaling: vertical and horizontal, without downtime (can make servers bigger and add more servers)
• Complexity: high

Federation

Sureview can be federated allowing completely separate systems in regions to communicate together so users can access resources in any system they have access to

• Resilience: high
• Scaling: vertical and horizontal, without downtime
• Complexity: high