Storage has an image problem. It reads as plumbing — necessary, unglamorous, solved. Meanwhile the interesting-sounding work happens somewhere with a nicer diagram.
Having spent a long time on enterprise storage, I would argue the opposite: it is one of the least forgiving distributed systems domains there is, and it is unforgiving in a way that teaches you things the rest of the field learns later and worse.
The reason is the failure semantics. In most distributed systems, the worst outcome of a bug is that something is unavailable for a while. In storage the worst outcome is that something is *wrong* — silently, durably, and in a way that propagates to every replica and every backup before anyone notices. Availability problems announce themselves. Correctness problems do not.
That single asymmetry shapes everything downstream. It is why replication semantics get argued about at a level of pedantry that looks excessive from outside. It is why the interesting question about a failover is never "did it fail over" but "what did the two sides believe about each other while it happened". It is why migration and cutover work — moving data from one system to another without a window where either could be authoritative — is genuinely difficult rather than tedious.
There is a career argument here too. Engineers ask me whether storage is a dead end while everything moves to cloud and AI. I think that gets it backwards. The AI systems being built now are enormous data-movement problems with correctness requirements attached. Somebody has to understand what happens when the bytes do not arrive, or arrive twice, or arrive stale. That instinct does not come from reading about it.
The hat is boring. The problem is not.