01
The Mystery
Begin with an architectural question that creates genuine curiosity.
“Something works. Something does not. Why?”Author · Educator · Systems Thinker
Don't memorize
the system.
Discover why it must exist.
A teaching philosophy built around architectural mystery, first principles, deliberate failure, and earned understanding.
The Author
Technology becomes easier when the learner can see why.
Author Profile
This author profile is intentionally centered on the work rather than a conventional résumé. The goal is to help engineers understand Kubernetes, cloud, DevOps and distributed systems by reconstructing the architectural pressures that make their mechanisms necessary.
The teaching journey starts with a mystery, builds the smallest plausible design, breaks it with realistic pressure, observes the failure, and only then reveals the terminology used by the industry.
The result is an interactive learning experience where concepts are not handed to the learner as vocabulary. They are earned as explanations.
— Mohit Dharmadhikari
Author · First Principles
Author · First Principles
Replace the identity layer. Put your portrait, name, concise professional biography, credentials and verified achievements here. The architecture of the page is already designed to make the author feel like the guide into the investigations.
The Teaching Method
Start with a mystery.
Never start with terminology.
The learner should first encounter a system that almost works. Every new concept appears because the previous design could no longer survive.
02
The Naive Architecture
Construct the simplest design a thoughtful engineer might naturally invent.
No Kubernetes. No jargon. Just machines, workloads and constraints.03
Break the Design
Introduce one pressure at a time: concurrency, failure, movement, scale, identity or isolation.
Every failure becomes evidence.04
Earn the Requirement
Turn the observed failure into an explicit architectural guarantee.
The learner now knows what the system must provide.05
Reveal the Mechanism
Only after the requirement is understood do implementation terms appear.
Kubernetes becomes an answer, not a collection of magic words.06
Bridge to the Next Mystery
Do not close the system prematurely. Preserve the unresolved boundary that naturally creates the next investigation.
Understanding compounds across the book.The learner should be able to say “of course the system needs this” before being told what it is called.
First Principles
Don't teach the architecture.
Make the architecture inevitable.
Make the architecture inevitable.
The Learning Loop
Curiosity → construction → failure → explanation.
01
Observe
See the mystery before receiving the answer.
02
Predict
Form a mental model and make a falsifiable prediction.
03
Break
Push the design until its hidden assumption becomes visible.
04
Derive
Extract the requirement that survives the failure.
05
Name
Attach the industry terminology after the concept is earned.
The Work
A Kubernetes book built as a sequence of architectural investigations.
The interactive companion is not a glossary wrapped in HTML. Each investigation is designed as a guided experiment: inherit what was already established, expose the next boundary, test the simplest design, break it, and derive the contract.
MysteryWhat is wrong?
Naive DesignWhat would we build?
FailureWhere does it break?
ContractWhat must be true?
Interactive
Readers do not merely scroll past diagrams. They trigger experiments, inspect state, and observe transitions.
Progressive
Later investigations inherit guarantees from earlier ones instead of restarting from a blank page.
Constitutional
Deliberate simplifications and unresolved boundaries are made explicit so the learning path stays honest.
The Kubernetes Investigation Book
Enter the system one mystery at a time.
Start at INV·000. Each investigation inherits what came before and hands off to the next — read them in order, or jump to whatever boundary is bothering you today.
INV·000
The Execution Boundary Problem
Where does a process's responsibility end and the environment's begin?
START HERE →
INV·001
Why a Process Cannot Keep Itself Alive
Why liveness must be an external contract, not a self-reported claim.
ENTER INVESTIGATION →
INV·002
The Reconciliation Pattern
Why converging on desired state beats issuing imperative commands.
ENTER INVESTIGATION →
INV·003
The Controller Pattern
Who is responsible for making reality match intent, continuously?
ENTER INVESTIGATION →
INV·004
Why Watches Beat Polling
Why efficient state propagation demands a push model, not repeated asking.
ENTER INVESTIGATION →
INV·005
Observe Once, Share Many
Why every controller re-listing the same state doesn't scale.
ENTER INVESTIGATION →
INV·006
Why Discovery and Execution Must Be Separated
Why finding what to run and running it are different problems.
ENTER INVESTIGATION →
INV·007
The Source of Truth
What object gets to define reality when multiple copies disagree?
ENTER INVESTIGATION →
INV·008
The Consensus Problem
How multiple replicas agree on one truth despite failures.
ENTER INVESTIGATION →
INV·009
Versioned Truth
Why state needs a version, not just a value, to be safely updated.
ENTER INVESTIGATION →
INV·010
The Single Leader Problem
Why only one actor can safely make a decision at a time.
ENTER INVESTIGATION →
INV·011
Failure Detection
How you tell a slow node from a dead one.
ENTER INVESTIGATION →
INV·012
The Ownership Problem
Who is allowed to delete what, and how do they know?
ENTER INVESTIGATION →
INV·013
The Garbage Collection Problem
What happens to orphaned resources once their owner is gone.
ENTER INVESTIGATION →
INV·014
The Scheduling Problem
Who decides where a workload actually runs?
ENTER INVESTIGATION →
INV·015
The Execution Problem
What actually turns a scheduling decision into a running process?
ENTER INVESTIGATION →
INV·016
The Container Runtime Problem
What a container really is, once you strip away the abstraction.
ENTER INVESTIGATION →
INV·017
The Pod Problem
Why multiple containers need to be scheduled as one unit.
ENTER INVESTIGATION →
INV·018
The Node Networking Problem
How containers on the same node actually reach each other.
ENTER INVESTIGATION →
INV·019
The Node Resource Problem
What stops one workload from starving every other one on the node.
ENTER INVESTIGATION →
INV·020
The Cluster Network Problem
Why machines being connected does not automatically mean workloads are reachable across node boundaries.
ENTER INVESTIGATION →
INV·021
The Stable Address Problem
What happens when a reachable workload is replaced and its identity changes?
ENTER INVESTIGATION →
INV·022
The Name Resolution Problem
How stable service names keep resolving while platform-owned addresses change underneath them.
ENTER INVESTIGATION →
INV·023
The External Access Problem
How public requests enter through one controlled boundary without exposing internal platform structure.
ENTER INVESTIGATION →
INV·024
The Network Isolation Problem
How a platform selectively revokes reachability between workloads without dismantling the flat network.
ENTER INVESTIGATION →
INV·025
The Persistent Storage Problem
How durable storage can outlive any process without abandoning the principle that processes are disposable.
ENTER INVESTIGATION →
INV·026
The Storage Placement Problem
Why compute and topology-constrained storage must be placed together before either decision becomes final.
ENTER INVESTIGATION →
INV·027
The Storage Interface Problem
Why independently owned platforms and storage systems require one stable contract without sharing implementations or release schedules.
ENTER INVESTIGATION →
INV·028
The Stable Identity Problem
Why surviving data is insufficient when a distributed system needs the same logical participant to return after failure.
ENTER INVESTIGATION →
INV·029
The Configuration Problem
Why executable logic and independently changing operational intent require separate owners and lifecycles.
ENTER INVESTIGATION →
INV·030
The Secret Distribution Problem
Why values that grant capability through possession require explicit ownership, intended consumers, and an independent authority lifecycle.
ENTER INVESTIGATION →
INV·031
The API Extension Problem
Why independently evolving domains need to extend a platform's resource vocabulary without destabilising its common guarantees.
ENTER INVESTIGATION →
INV·032
The Automation Problem
Why domain-owned convergence behavior needs a stable participation contract around authoritative platform state.
ENTER INVESTIGATION →
INV·033
The Admission Problem
Why independently owned judgments need candidate-bound results, explicit dispositions, and one platform-owned authoritative commit.
ENTER INVESTIGATION →
INV·034
The Bin Packing Problem
Why economic comparison must stay honest about capacity shape, unknown future demand, modeled capacity semantics, and compatible shared commitments.
ENTER INVESTIGATION →
INV·035
The Elasticity Problem
Why changing demand evidence needs owned interpretation, declared intent, and a non-authoritative claim before finite shared capacity can change.
ENTER INVESTIGATION →
INV·036
The Fairness Problem
Why a defensible scarcity policy must make its fairness subjects, comparison domain, delegation boundary, and temporal scope explicit.
ENTER INVESTIGATION →
INV·037
The Preemption Problem
Why a legitimate policy preference is not automatically authority to reclaim a commitment already accepted by someone else.
ENTER INVESTIGATION →
INV·038
The Disruption Problem
Why legitimate reclamation authority does not by itself establish that displacing healthy work is safe, and what availability boundary must constrain it.
ENTER INVESTIGATION →
INV·039
The Retry Economy Problem
Why ownership of unfinished corrective work does not grant unlimited access to finite shared execution capacity — and closes Movement VI.
LATEST →
Author-to-book transition. The intended experience is: discover the person → understand the teaching philosophy → become curious about the method → enter the investigation book without breaking the cinematic language.
Achievements & Evidence
Show the outcomes.
Let the work prove the philosophy.
Selected engineering, teaching and community outcomes, grounded in systems built, engineers mentored and technical knowledge shared.
01
Engineering at scale
Led engineering of high-volume, high-traffic applications using Microsoft .NET and Azure across 20+ years of software engineering experience.
02
Teaching with depth
Trained and mentored 2,000+ engineers and developers through deep-dive programs covering Git, GitHub, DevOps, cloud engineering and modern software architecture.
03
Community contribution
Delivered technical talks and hands-on workshops to engineering communities and student audiences, including an AWS Student Community Day session attended by 450+ students, translating complex engineering concepts into practical learning.
What matters here
- Engineering at scale — Experience designing and building high-volume, high-traffic systems using .NET, Azure, cloud and modern engineering practices.
- Technical leadership — Turning complex engineering problems into practical architectures, engineering standards and solutions that teams can actually build and operate.
- Teaching with depth — 2,000+ engineers and developers trained and mentored, with a focus on understanding how systems work rather than simply learning tools or commands.
- Community contribution — Regularly sharing engineering knowledge through technical talks, workshops and developer communities, including sessions for audiences of 450+ students.
- First-principles thinking — Exploring the why behind technologies such as Git, Docker, Kubernetes, cloud infrastructure and distributed systems.
- Practical impact over credentials — Evidence through systems built, engineers mentored, workshops delivered and technical knowledge shared—not a collection of certifications.
The Author's Promise
If a concept feels like magic,
we haven't investigated deeply enough.
we haven't investigated deeply enough.
Press “Reveal the method” to see how an investigation is constructed.
Enter the Book
You have met the author.
Now investigate the system.
Start with a question.
Build the smallest design that could work.
Apply pressure until it fails.
Extract the requirement hidden inside the failure.
Only then learn what Kubernetes calls it.