Chapter 1 — Computing and service architecture
Lesson map
Lesson 01 published. Map, example, EX001.
flowchart TD
N0["Learning outcomes"]
N1["1.1 The trigger"]
N2["1.2 Fairway's services"]
N3["1.3 Service models"]
N4["1.4 Who runs what"]
N5["1.5 Components and connections"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX001"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["1.1 The trigger"]
N2["1.2 Fairway's services"]
N3["1.3 Service models"]
N4["1.4 Who runs what"]
N5["1.5 Components and connections"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX001"]
[Learning outcomes]
|
v
[1.1 The trigger]
|
v
[1.2 Fairway's services]
|
v
[1.3 Service models]
|
v
[1.4 Who runs what]
|
v
[1.5 Components and connections]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX001]
Learning outcomes
You will (1) describe how a small company's services are built from cloud components; (2) explain service models from NIST SP 800-145; (3) identify who runs each part.
1.1 The trigger
Tomás Reyes is a technical-course student at the fictional Hollins Technical College, working as an apprentice in the small IT team of the fictional Fairway Logistics, a regional courier. His supervisor is Grace Mensah. In March a developer made the storage bucket holding delivery manifests public so that a partner could download a file. It stayed public for nearly three days. Grace asks Tomás to help find out what happened and to make sure it does not happen again. The course follows that work.
1.2 Fairway's services
Fairway runs a parcel tracking site in containers on a managed Kubernetes cluster, stores manifests and driver photos in cloud storage buckets, keeps backups in another bucket, and uses a managed database. Its website images sit in a separate assets bucket. Each of these holds different data: manifests carry customer names and addresses, driver photos are personal data, backups contain everything, and the assets bucket is meant to be public. Tomás writes the list down before looking at any settings, so that the later checks cover every bucket rather than only the one involved in March.
1.3 Service models
NIST SP 800-145 defines infrastructure, platform and software as a service. Fairway's cluster is close to platform as a service, because the provider runs the control plane; its storage and database are managed services; its email is software as a service. The label matters less than what it implies for Fairway. With the managed cluster and storage, the provider runs the hardware and control software, but bucket policies, identities and workload settings are Fairway's job. The March exposure happened in exactly that customer-configured layer, through a policy change that the provider's service carried out as instructed.
1.4 Who runs what
For each component Tomás records whether the provider, Fairway's IT team or a vendor operates it. This tells him where Fairway must configure security itself. His table shows the provider operating the cluster control plane, the storage service and the database engine, while Fairway's IT team operates bucket policies, identities, container images and the deploy pipeline. The email service is run entirely by its vendor under Fairway's account settings. The manifests bucket's public setting sits firmly in Fairway's column, which is why the fix has to come from Fairway as well.
1.5 Components and connections
He sketches how the tracking site reads from the database, writes manifests to storage and sends emails, so later chapters can follow data through the system. The sketch shows the tracking site reaching the database through its private endpoint and writing manifests to the manifests bucket, while the CI pipeline uploads to the assets bucket. Partners appear only at the edge of the sketch, receiving files from Fairway. Drawing it this way makes the gap visible: nothing on the diagram showed how a partner was supposed to receive a manifest safely.
Worked example
Tomás lists six components with their service model and operator. Grace adds one he missed: the partner's file transfer, which the developer replaced with the public bucket. Tomás realises that the incident began when a missing service was improvised.
Synthetic case. Fairway, Tomás and Grace are synthetic.
Errors and limits
Service model labels are approximate; record actual responsibilities rather than arguing about categories.
Exercises
- EX001 — Incident summary. Describe the March incident in one sentence. Rubric: 3 = manifests bucket made public for partner, about three days; 2 = partial; 1 = vague; 0 = none.
- EX002 — Service models. Which NIST service model best fits Fairway's managed cluster, and why? Rubric: 3 = platform-like; provider runs control plane; 2 = partial; 1 = vague; 0 = none.
- EX003 — Operator record. Why record who operates each component? Rubric: 3 = shows where Fairway must configure security; 2 = partial; 1 = vague; 0 = none.
- EX004 — Missing component. What component did Grace add and why did it matter? Rubric: 3 = partner file transfer; its absence led to improvising; 2 = partial; 1 = vague; 0 = none.
Synthesis
Know each component, its service model and who runs it.