Physical architecture layer design: client-server, cloud, nonfunctional requirements

Analysis is finished and the models are balanced. The first big decision in design: on which machines will this software run, and how will its parts be distributed? The physical architecture layer answers this question. What determines the decision is the nonfunctional requirements you gathered in week 5: performance, security, the operational environment, cultural and political constraints. The exam brings a comparison of architecture types, cloud models and the scenario “which architecture for these requirements”; sometimes an availability calculation.

Golden rules:

1. Every application has four jobs: data storage, data access, business logic, presentation. The architecture is where these run.
2. Thin client = presentation only. The business logic is on the server.
3. Nonfunctional requirements choose the architecture, not the other way round.
4. The availability calculation: downtime = total time × (1 − ratio). For components in series, the ratios are multiplied.

The four basic components

Architecture types

Server-based architecture

All four components run on a central server (formerly a mainframe); the client is just a terminal that sends keystrokes and displays the screen.

• Pro: central control, security, maintenance in one place.
• Con: the server becomes a bottleneck, and growing it is expensive and not incremental (you have to buy a new and much bigger server).

Client-based architecture

The client does presentation, business logic and data access; the server only stores files (a file server).

• Pro: simple, easy to develop.
• Con: all the data is carried over the network to the client, so the network load is large; performance drops with many users.

Client-server architecture

The work is split: the client is responsible for presentation and the server for the data; the business logic is distributed to the two or to separate servers.

Two-tier
[Client: presentation + app logic]
          |
[DB server: data access + storage]

Three-tier
[Client: presentation]
          |
[App/web server: application logic]
          |
[DB server: data access + storage]

N-tier
[Client] - [Web srv] - [Order svc]
                     - [Payment svc]
                     - [DB server]

Middleware is intermediary software that lets software on different tiers talk to each other (message queues, API gateways).

Thin vs thick client: A thin client does only presentation (a web browser). A thick (fat) client also runs part of the business logic (some desktop or mobile applications). A thin client is easy to maintain; a thick client can work offline and reduces the server load.

Comparison

Cloud computing

Hardware and software resources are rented over the internet on a pay-as-you-go model. At its basis is virtualization: one physical server runs several virtual machines.

Pros: low initial investment, fast growth (elasticity), maintenance is with the provider. Cons: dependence on the provider (vendor lock-in), where the data sits (legal compliance), cost in the long run, dependence on an internet connection.

Other concepts: ubiquitous computing / Internet of Things (sensors, turnstiles and smart devices connect to the system), green IT (energy efficiency, fewer physical servers with virtualization).

From nonfunctional requirements to architecture

Availability calculation

Availability is the proportion of time the system is usable. A year is 365 × 24 = 8,760 hours.

$\text{allowed downtime} = 8760 \times (1 - A)$

A        Annual downtime
99%      87.6 hours
99.5%    43.8 hours
99.9%    8.76 hours  (525.6 min)
99.99%   52.56 min

Components in series: If the web server (99%) and the database (99.5%) must work together:

$A = 0.99 \times 0.995 = 0.98505 \approx 98.5\%$

The total is lower than even the weakest link. The solution: redundant servers, a load balancer.

Capacity estimation

In the campus food app, 2,000 active users at lunch break, about 5 requests per minute per person:

2,000 x 5 = 10,000 requests/min
10,000 / 60 ≈ 166.67 requests/s

The server is chosen according to this peak value and a safety margin.

Worked example: the architecture decision for FitHub

Requirements:

• O1. Members access it through a mobile app and the web; turnstiles (IoT) do check-in. (operational)
• P1. 1,500 concurrent users across 5 branches between 18:00 and 21:00. (performance)
• P2. 99.9% availability; if the turnstile does not work, a member cannot get in. (performance)
• S1. Card data will not be stored; payment is with an external provider. (security)
• C1. Personal data will be stored in Turkey or in a region compliant with the Turkish data protection law (KVKK). (cultural and political)

Decision: Three-tier (n-tier) client-server, on PaaS.

Deployment diagram

+------------------+     +-------------------+
| <<device>>       |     | <<device>>        |
| Member phone     |     | Turnstile (IoT)   |
| [fithub.apk]     |     | [gate-agent]      |
+--------+---------+     +---------+---------+
         | HTTPS                   | HTTPS
         v                         v
+--------------------------------------------+
| <<execution env>> PaaS app tier (x3)       |
| [fithub-api.jar]                           |
+--------------------+-----------------------+
                     | TCP (private network)
+--------------------v-----------------------+
| <<node>> Managed DB (primary + replica)    |
+--------------------------------------------+

A node (a cube; here a box) is hardware or an execution environment, the things in square brackets are artifacts, and the arrows are communication paths.

Hardware and software specification

One of the outputs of design is a list of the resources to be bought or rented:

The specification is sent to vendors; the offers are compared on price, performance, support and reliability. The whole cost is taken into account: license, installation, training, maintenance (total cost of ownership).

Common mistakes