Chapter 1 — Calculus I
Lesson map
Lesson 01 published. Map, example, EX001.
flowchart TD
N0["Learning outcomes"]
N1["1.1 The opening case"]
N2["1.2 Rates of change"]
N3["1.3 Accumulation"]
N4["1.4 Growth of configuration"]
N5["1.5 Approximation"]
N6["1.6 Why maths first"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX001"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["1.1 The opening case"]
N2["1.2 Rates of change"]
N3["1.3 Accumulation"]
N4["1.4 Growth of configuration"]
N5["1.5 Approximation"]
N6["1.6 Why maths first"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX001"]
[Learning outcomes]
|
v
[1.1 The opening case]
|
v
[1.2 Rates of change]
|
v
[1.3 Accumulation]
|
v
[1.4 Growth of configuration]
|
v
[1.5 Approximation]
|
v
[1.6 Why maths first]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX001]
Learning outcomes
You will (1) use rates of change to describe how cloud resources and risks grow; (2) interpret derivatives as rates in operational data; (3) reason about accumulation; (4) connect calculus to the opening case.
1.1 The opening case
Elena Petrova is a fifth-year engineering student at the fictional Brackenridge Institute of Technology, on an industry project with the fictional Solent Energy Co-op under industry supervisor Rosa Delgado and academic tutor Dr Felix Wagner. Solent runs meterhub, a Kubernetes-hosted platform that ingests smart-meter readings from 80,000 homes. Last spring a container image for meterhub with a cloud access key built into one layer was pushed to a public registry by mistake, and the meterhub namespace had no network policies, so any pod could reach the readings database. The key was revoked within hours and no misuse was found, but the review asked for an engineered approach rather than patches.
The leak and the missing network policies give the course two threads to follow: how secrets end up where they should not, and how traffic inside a cluster is controlled. Elena's project brief asks her to understand both, design fixes that the small platform team can operate, and show with evidence that the fixes work. Each later chapter adds a tool she uses on that brief.
1.2 Rates of change
Engineers describe systems by how quantities change. If the number of running pods P changes over time t, dP/dt is the rate of scaling. When meterhub's ingest rate rises in the evening, the derivative of request volume tells the autoscaler how quickly capacity must grow.
The derivative matters because capacity cannot appear instantly: a new pod needs time to start, pull its image and pass its health checks. If demand rises faster than pods can start, requests queue or fail. Knowing the steepest evening rise lets Elena check whether the autoscaler's settings react quickly enough, or whether a small buffer of spare pods should run before the peak arrives.
1.3 Accumulation
The integral of a rate gives a total. The integral of exposure over time, for example the number of reachable sensitive services multiplied by hours, gives a measure of accumulated risk. Elena uses this idea later to compare designs: a short, wide exposure can matter as much as a long, narrow one.
Consider a database port accidentally reachable from the internet for two hours, against an internal admin service reachable from every pod for a month. The first is wide but brief; the second is narrow but long. Multiplying reach by time puts both on one scale, so the team can compare them honestly instead of reacting only to whichever sounds more alarming.
1.4 Growth of configuration
Each new microservice adds configuration. If services grow linearly but permissions per service grow too, total permissions grow faster than linearly, which explains why manual review stops scaling.
If each of ten services needs five permissions, a reviewer checks fifty entries; if forty services each need twelve, the count is 480, and many of them interact. Reviews that once took an afternoon now take a week and are done less carefully. This growth is the main argument for checking configuration with programs and policies rather than by reading every line by hand.
1.5 Approximation
Small steps approximate continuous change: sampling metrics every 30 seconds approximates the true curve, and the sampling interval limits how fast a change can be seen.
A spike lasting ten seconds may fall entirely between two 30-second samples and never appear in the graph. Shorter intervals reveal more but cost storage and processing. Elena checks the sampling interval of each metric she plans to use for alerts, because an alert can only fire on changes the samples actually capture. Alert rules state their interval.
1.6 Why maths first
Later chapters use rates for autoscaling, statistics for alert latency and logic for policy evaluation. The foundations make those designs analysable rather than guessed.
Guessed designs are hard to defend when someone asks why a threshold is five rather than ten, or why one design is safer than another. With rates, distributions and logic, Elena can show the reasoning and let others check it. The maths in these first chapters is kept to what the later engineering work actually uses.
Worked example
Elena estimates the accumulated exposure of the leaked key: one credential reachable publicly for 5 hours with access to 3 storage buckets gives 15 bucket-hours. She compares this with the namespace's missing network policies: 12 reachable pod pairs for an estimated 400 days, a much larger accumulated exposure, though of a different kind. The comparison helps Rosa explain why both issues need engineering fixes.
Synthetic case. Brackenridge, Solent Energy Co-op, meterhub and all figures are synthetic.
Errors and limits
Accumulated exposure is a simplified measure; it ignores how likely each exposure was to be used.
Exercises
- EX001 — Derivative meaning. What does dP/dt describe for pods? Rubric: 3 = rate of scaling; 2 = partial; 1 = vague; 0 = none.
- EX002 — Integral use. How can an integral measure risk? Rubric: 3 = exposure accumulated over time; 2 = partial; 1 = vague; 0 = none.
- EX003 — Leak estimate. What was the leaked key's accumulated exposure? Rubric: 3 = 15 bucket-hours; 2 = partial; 1 = vague; 0 = none.
Synthesis
Rates and accumulation give engineers a language for growth and exposure.