Develop solutions that use blob storage

Develop solutions that use blob storage:

Azure Storage overview

In this section, we will be looking at an overview of all the types of Azure storage available:

An Azure storage account contains all of your Azure Storage data objects: blobs, files, queues, tables, and disks. The storage account provides a unique namespace for your Azure Storage data that is accessible from anywhere in the world over HTTP or HTTPS. Data in your Azure storage account is durable and highly available, secure, and massively scalable.

Azure Blob storage

Object storage solution in the cloud

Azure Blob storage is Microsoft’s object storage solution for the cloud. Blob storage is optimized for storing massive amounts of unstructured data.

Note: Unstructured data is data that doesn’t adhere to a particular data model or definition, such as text or binary data.

Blob storage is designed for:

• Serving images or documents directly to a browser
• Storing files for distributed access
• Streaming video and audio
• Writing to log files
• Storing data for backup and restore disaster recovery, and archiving
• Storing data for analysis by an on-premises or Azure-hosted service

Accessible via an HTTP/HTTPS API

With HTTP/HTTPS, objects in blog storage can be accessed globally. Accessibility to the storage blog can be achieved via Azure Storage REST API, Azure PowerShell, Azure CLI, or an Azure Storage client library.

Note: Client libraries are available for different programming languages, including:

• .NET
• Java
• Node.js
• Python
• Go
• PHP
• Ruby

Azure Blob storage resource hierarchy

Storage account: This refers to an account that you can use to access Azure Storage. In terms of hierarchy, it’s the parent account of the container and blob resources.

Container: This refers to a collection of objects that are grouped together and accessed by using the same base Uniform Resource Identifier (URI).

Blob: This refers to an object, typically a media file or a disk, that is stored in the container.

Blob types

Blob events

Azure Storage events allow applications to react to the creation and deletion of blobs using modern serverless architectures. It does so without the need for complicated code or expensive and inefficient polling services. Instead, events are pushed through Azure Event Grid to subscribers such as Azure Functions, Azure Logic Apps, or even to your own custom http listener, and you only pay for what you use.

Blob storage events are reliably sent to the Event grid service which provides reliable delivery services to your applications through rich retry policies and dead-letter delivery.

Common Blob storage event scenarios include image or video processing, search indexing, or any file-oriented workflow. Asynchronous file uploads are a good fit for events. When changes are infrequent, but your scenario requires immediate responsiveness, event-based architecture can be especially efficient.

Develop solutions that use blob storage:

Set and retrieve properties and metadata

Containers and blobs support custom metadata, represented as HTTP headers. Metadata headers can be set on a request that creates a new container or blob resource, or on a request that explicitly creates a property on an existing resource.

Metadata headers are name/value pairs. The format for the header is:

x-ms-meta-name:string-value

Beginning with version 2009-09-19, metadata names must adhere to the naming rules for C# identifiers. Names are case insensitive. Note that metadata names preserve the case with which they were created, but are case-insensitive when set or read. If two or more metadata headers with the same name are submitted for a resource, the Blob service returns status code 400 (Bad Request). The metadata consists of name/value pairs. The total size of all metadata pairs can be up to 8 kilobytes (KB) in size. Metadata name/value pairs are valid HTTP headers, and so they adhere to all restrictions governing HTTP headers.

Metadata on a blob or container resource can be retrieved or set directly, without returning or altering the content of the resource. Note that metadata values can only be read or written in full; partial updates are not supported. Setting metadata on a resource overwrites any existing metadata values for that resource.

Develop for Azure storage (Develop solutions that use Cosmos DB storage)

Develop solutions that use blob storage:

implement data archiving and retention

Lifecycle management

Rule-based automation for data tiering and retention management:

• Rules run daily at the storage account
• Supports:
  • General-purpose v2 storage accounts
  • Blob storage
  • Premium BlockBlob (only supports deletion for lifecycle management)
• Prefix filters enable targeting of containers or sets of blobs

Develop solutions that use blob storage:

implement hot, cool, and archive storage

Storage tier

Azure Storage offers different storage tiers, which allow you to store Blob storage object data in the most cost-effective manner.

The available tiers include:

Premium storage is a performance tier optimized for mission-critical high-performance applications. This is currently available only for Block blob storage.

The following three access tiers are currently available in the Standard performance tier, for GPv2 account types.

•Hot storage is optimized for storing data that is accessed frequently.

•Cool storage is optimized for storing data that is infrequently accessed and stored for at least 30 days.

•Archive storage is optimized for storing data that’s rarely accessed and is stored for at least 180 days with flexible latency requirements (on the order of hours).

Storage tier pricing

Example of lifecycle management flows

Consider a scenario where data gets frequent access during the early stages of the lifecycle but only occasionally after two weeks. Beyond the first month, the dataset is rarely accessed.

In this scenario, hot storage is best during the early stages. Cool storage is most appropriate for occasional access. Archive storage is the best tier option after the data ages more than a month.

Policy Example

A policy must include at least one rule. You can define up to 100 rules in a policy.

A rule name can include up to 256 alphanumeric characters, and the name is case-sensitive. It must be unique within a policy.

Each rule definition is made up of a filter set and an action set.

Implement IaaS solutions

Create Azure App Service Web Apps

Implement Azure functions

Implement user authentication and authorization

Implement secure cloud solutions

Integrate caching and content delivery within solutions

Instrument solutions to support monitoring and logging

Develop an App Service Logic App

Implement API Management

Develop message-based solutions

Develop event-based solutions