This module brought together three concepts that I had encountered separately but hadn’t fully connected: storage types, their real-world use cases, and how they fit into larger cloud architectures. Seeing them sequenced together made the logic click in a way that isolated definitions don’t.
Because of the AWS and Azure courses we took, I understood going in that object, block, and file storage each have fundamentally different performance characteristics, access models, and cost structures reframed how I think about infrastructure decisions. Block storage behaves like a hard drive attached directly to a machine. Object storage is more like a warehouse, where you retrieve things by label, not location. File storage sits in between, designed for shared access across multiple systems simultaneously.
The use cases and trade-offs topic was where the concepts became practical. The recurring tension between performance and cost is something I recognize from other domains. In neuroscience, biological systems make similar trade-offs between energy efficiency and speed. High-performance block storage costs more because it does more. Archival object storage costs less because retrieval is slower and access is rare. The right choice is never universal; it depends entirely on how the data will be used and how often.
The architecture topic tied everything together by showing that real systems rarely rely on a single storage type. A well-designed cloud application layers storage strategically, block for databases, object for media and backups, file for shared assets, with each layer chosen to match its workload. What struck me most was how early these decisions have to be made. Storage choices baked into an architecture at the start are expensive and disruptive to change later, which means getting the reasoning right from the beginning matters more than it might appear.
Leave a comment