Blob storage

Azure's documentation describes block blobs for files and data, append blobs for logs, and page blobs for random-access disks. In a transfer conversation, "blob" almost always means the block-blob case, which behaves like an S3 object.

The naming fight is the reason for a separate page. Amazon says bucket and object. Azure says container and blob. The operations match: put the bytes, get the bytes, attach metadata, sign a time-limited URL, upload in blocks, expire by lifecycle. A job written against one API does not run on the other without a translation layer. The file the user receives does not change because the vendor changed the noun.

A pipeline uploads `render-14.mov`, 18 GB, as a block blob in container `deliveries`. It stages blocks and commits the list, the Azure analogue of a multipart complete. A reviewer gets a shared access signature valid for six hours. The download is a GET of that blob. An engineer who looks for an S3 bucket of the same name on the Azure account finds nothing, files a missing-file incident, and the object has been there under the other word. Page blobs are the trap inside the term. They are disks. Treating a page blob as a downloadable deliverable works only if something copied it out as a file first.

Use blob storage when the contract or the SDK says blob. Use object storage when you mean the pattern. Do not write two procedures. Write one procedure and a glossary line for the nouns: container equals bucket, blob equals object, shared access signature equals presigned URL, until a vendor feature actually diverges.