My friend failed operating systems by 4 marks. Same week, he passed his first cloud certification with a score of 912.
I keep thinking about that week. Not because of the gap between the two numbers, but because I was living in the same gap. I just hadn't admitted it yet.
Two worlds that refused to talk
On one side you have the university. Lecture halls with 200 students, a projector, and a lecturer drawing a process state diagram on a whiteboard for the ninth time. Theory, proofs, exam papers, marks.
On the other side you have the cloud. A terminal at 2 AM. A dashboard turning red. A teammate asking why the function that worked yesterday now times out. Nobody there asks you to define a semaphore. They ask you to make the red thing green.
For a long time I assumed one of those worlds was a waste of my time. Some days I blamed the lectures. Other days I blamed the tutorials that taught me how to click through a console but never why anything behaved the way it did. I had a quiet theory that I only needed one of them, and I kept changing my mind about which.
I was wrong, and the way I found out was slow and a little embarrassing.
Deadlocks on paper, timeouts in production
In the OS course, deadlock is a tidy little story. Two processes, two resources. Process A holds one and waits for the other. Process B holds the other and waits for the first. Neither moves. You draw a resource allocation graph, find the cycle, and get your marks.
Then you meet a Lambda function that times out and the logs say nothing useful.
Here is what it looked like in my case. The function opened a database connection, grabbed a lock on a row, and then called another service that was also waiting on that same row. Different code, different runtime, same shape as the diagram on the whiteboard. A cycle. Two things holding and waiting. The timeout was the platform's way of killing the stalemate after a fixed number of seconds.
Once I saw it as a hold-and-wait problem, the fixes were already in my notes. Break the circular wait by always acquiring locks in the same order. Stop holding a resource while you wait on something slow. Add a timeout of your own so you fail early instead of hanging until the platform pulls the plug.
# Same idea as the textbook fix: one global order for locks
def transfer(a, b, amount):
first, second = sorted([a, b], key=lambda acct: acct.id)
with first.lock:
with second.lock:
first.debit(amount)
second.credit(amount)
I did not learn that from a cloud tutorial. I learned it from a lecture I had half ignored.
Normalization and the DynamoDB bill
Normalization is the other chapter I used to treat as exam fodder. First normal form, second, third, the whole ladder. Remove repeated groups, remove partial dependencies, remove transitive ones. You split tables so each fact lives in exactly one place.
It is a great habit for a relational database. It is a terrible habit to carry unchanged into DynamoDB.
I did carry it over. I modeled my data the way I had been trained to, with small clean tables and relationships stitched together at read time. DynamoDB has no joins, so my application did the stitching. One screen in the app meant five or six separate reads, and a few queries that quietly turned into scans. Reads cost money. Scans on a growing table cost a lot of money. The bill told me, rather loudly, that my model was wrong for the tool.
What fixed it was understanding why normalization exists in the first place. It exists to avoid update anomalies and wasted storage in a system where joins are cheap. In a key-value store where reads are the expensive part, the trade flips. You design around your access patterns, you duplicate data on purpose, and you accept that updates get harder because reads get cheaper.
If I had only memorized the rules, I would have been stuck. Because I understood the reasoning behind them, I could see exactly where the reasoning stopped applying. That is the whole difference between knowing a rule and knowing a tradeoff.
Scheduling, and how Kubernetes picks a pod's home
Every OS course spends weeks on CPU scheduling. First come first served, shortest job first, round robin, priority queues, starvation, aging. You compute average waiting times by hand until you hate Gantt charts.
Then you read how the Kubernetes scheduler works and it feels strangely familiar.
A new pod arrives and sits in a queue. The scheduler filters out nodes that cannot run it, for example nodes without enough CPU or memory left. Then it scores the survivors and picks the best one. Pods carry priorities. A high priority pod can preempt a lower one when the cluster is full. Resource requests and limits decide what a pod is promised and what it is allowed to burn.
Swap the word process for pod and the word CPU for node, and half of it reads like my old lecture notes. Priority inversion, starvation, preemption. These were not abstract words anymore. They explained why a low priority batch job kept getting evicted, and why a pod with no resource requests behaved like a noisy neighbor.
Nobody told me this would happen. I found out because a pod stayed Pending and I knew which questions to ask.
What the rebuild actually was
I did not wake up one morning and decide to connect the two worlds. It happened in small collisions. A production problem would stall me, I would remember a diagram from a lecture, and the problem would crack open.
Over time I started doing it on purpose. When I met a new cloud service, I asked what operating systems idea it was built on. Queues, caches, locks, schedulers, file systems, virtual memory. Almost every managed service is an old idea with a pricing page attached.
That rebuild is the reason I can debug a distributed system today. Not because I memorized more services. Because I stopped treating each one as a separate magic trick.
Back to my friend
I should be fair to him. A cloud certification and an operating systems exam test different things. One rewards breadth and a clear head under a clock. The other rewards depth and patience with ugly details. Failing one by 4 marks and acing the other says very little about how good an engineer he will be.
But it did make me see my own situation more clearly. I felt split. Half my week belonged to coursework that felt disconnected from my job, and the other half belonged to a job that felt disconnected from my coursework.
Living in both worlds at once feels like a handicap. It runs like a double lab nobody else gets to use. The lecture hall is where you learn why things work. The terminal is where you learn what happens when they don't. If you only have one, you are guessing at the other.
So if you are a student who also ships things, stop apologizing for the overlap. Open your old notes the next time something breaks at 2 AM. There is a decent chance the answer is already in there, written in a boring diagram you drew while half asleep.
What is the strangest place a textbook idea has shown up in your production work?
Top comments (0)