Chapter 1 — Computing and service architecture
Lesson map
Lesson 01 published. Map, example, EX001.
flowchart TD
N0["Learning outcomes"]
N1["1.1 The case and the service"]
N2["1.2 Components of the service"]
N3["1.3 Single points of failure"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX001"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["1.1 The case and the service"]
N2["1.2 Components of the service"]
N3["1.3 Single points of failure"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX001"]
[Learning outcomes]
|
v
[1.1 The case and the service]
|
v
[1.2 Components of the service]
|
v
[1.3 Single points of failure]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX001]
Learning outcomes
You will (1) describe how services are built from components; (2) place a ledger node within a service; (3) identify single points of failure.
1.1 The case and the service
Aiko Brennan is a technical trainee at the fictional Northfield Technical Institute, mentored by Mr Tomasz Kowal. During her eighteen-month course she supports the fictional Greenway Tool Library, about 600 borrowers, which records refundable borrowing deposits as tokens on a permissioned Ethereum-compatible ledger with three nodes. Borrowers pay a deposit token when taking a tool and receive it back on return. Every person, address and figure here is synthetic. Aiko starts by learning how the library's service is assembled from components, because every later task depends on knowing which part does what.
1.2 Components of the service
The service has a web front end where borrowers reserve tools, an application server that handles reservations, a database of borrowers and tools, a deposit service that prepares token transfers, three ledger nodes and a monitoring server. Aiko draws them as boxes with arrows showing requests and data. She labels which components the library runs itself and which are rented, such as the cloud servers. Seeing the architecture helps her understand that the ledger is one part of a larger service, and that most daily work concerns the components around it.
1.3 Single points of failure
A single point of failure is a component whose failure stops the whole service. Aiko finds two: the application server runs on one machine, and the deposit service has no standby. The three ledger nodes are not single points, because the ledger continues with two. She records each with its impact and a possible remedy, such as a second application server or a documented manual fallback for deposits. Mr Kowal explains that identifying single points of failure early is one of the most useful contributions a technician can make to service reliability.
Worked example
Aiko maps seven components and finds two single points of failure: the lone application server and the deposit service without standby.
Synthetic case. Aiko Brennan, Mr Tomasz Kowal, Northfield Technical Institute, Greenway Tool Library and all data are synthetic.
Errors and limits
Assuming a ledger's redundancy protects the whole service ignores single points around it.
Exercises
- EX001 — Library size. How many borrowers does Greenway serve? Rubric: 3 = about 600;; 2 = 600;; 1 = 6,000;; 0 = none.
- EX002 — Deposit token use. How are deposit tokens used? Rubric: 3 = paid when borrowing, returned on return;; 2 = refundable deposit;; 1 = sold;; 0 = none.
- EX003 — Not a single point. Why are the ledger nodes not single points? Rubric: 3 = the ledger continues with two of three;; 2 = redundancy;; 1 = they are;; 0 = none.
- EX004 — Remedy example. Name one remedy for a single point. Rubric: 3 = a second application server;; 2 = manual deposit fallback;; 1 = delete it;; 0 = none.
Synthesis
Knowing a service's components reveals where it can fail as a whole.