Journey to

While finishing my bachelor's thesis in Cloud Software Engineering, I took on a (small) detour: I built a three-node distributed cluster, on my desk.

I have never been someone who learns things by heart. I remember best the things that I can make sense of for myself.

That is why I often try to map the concept to the thing itself, see what is happening underneath, and apply it before it really sticks. tufte-css

From abstract clouds to real metal

Managing and provisioning my own machines gave me exactly that. It connected abstract distributed cloud concepts to real hardware and network communication, helped me understand why cloud services are designed the way they are, and made me appreciate how much complexity they hide.

When every dependency, every replica, and every connection lives inside a dashboard, it's easy to treat reliability as a magic property of the platform. Put the same stack on physical machines and suddenly failover is a real hard drive and a power cable, load balancing is a real switch, and latency is a real wire you can measure.Three is the minimum you need for real quorum. Reproduce the cluster on your own desk and every one of these abstractions becomes a part you can touch.

The build

Over the past six months, I designed the setup, sourced the materials, rented an angle grinder, built the frame, built the PCs, and somehow ended up with a working cluster. Most of that was a first.

No rack, no vendor, no console. Just spare parts, a rented grinder, and a willingness to screw up in the open.

What it did to my understanding

• Provisioning stopped being a form I fill in. It's now boot logs and DHCP and storage you have to make decisions about.

• Networking went from config blocks to actual cables. I can see the traffic move; I can find the point where it stops.

• The value of managed services became obvious — precisely because I had to do the unmanaged version by hand first.

After running a few projects on it, I feel more ready than ever to bring that hands-on understanding to the AWS Certified Solutions Architect Associate exam, and to continuing my master's studies in Distributed Cloud Computing and Software Engineering.⊕This is the whole point of running the unmanaged version yourself: every managed convenience becomes something you understood by rebuilding it by hand.

Turning theory into understanding

So, what is your own way of turning theory into understanding?

For me, it's this: build the smallest real version of the thing, then let the gaps between the diagram and the hardware teach you what the diagram left out.