Azure Storage and Azure SQL Database both play an important role in the Microsoft Azure Platform-as-a-Service (PaaS) strategy for storage. Azure Storage enables storage and retrieval of large amounts of unstructured data. You can store content files such as documents and media in the Blob service, use the Table service for NoSQL data, use the Queue service for reliable messages, and use the File service for Server Message Block (SMB) file share scenarios. Azure SQL Database provides classic relational database features as part of an elastic scale service.

Uploading a blob
You can upload files to blob storage using many approaches, including the following:

1- Using the AzCopy tool 
2- Directly using the Storage API and writing HTTP requests
3- Using the Storage Client Library, which wraps the Storage API into a language and platform-specific library 
4- Using Windows PowerShell cmdlets 

To upload a blob using AzCopy, complete the following steps:

1- Download AZCopy 
2- Open a command prompt and navigate to C:\Program Files (x86)\Microsoft SDKs\Azure\AzCopy.
3- Create a text file in a folder that is easy to get to. Insert some random text in it.
4- In the command window, type a command that looks like this: AzCopy /Source:c:\…../Dest:https://myaccount.blob.core.windows.net/mycontainer2 /DestKey:key /Pattern:*.txt.
Press Enter to issue the command to transfer the file.

Reading data
You can anonymously read blob storage content directly using a browser if public access to blobs is enabled. The URL to your blob content takes this format:

https://<your account name>.blob.core.windows.net/<your container name>/<your path and filename>

Or you can read blobs using Visual Studio.  You can also use Server Manager in Visual Studio to view the contents of your blob containers and upload or download files. Navigate to the blob storage account that you want to use.
Double-click the blob storage account to open a window showing a list of blobs and providing functionality to upload or download blobs.

Challenge

Applications can delegate specific tasks to other services, for example, to perform background processing or to integrate with other applications or services. In the cloud, a message queue is typically used to delegate tasks to background processing. In many cases the order requests are received in by a service isn’t important. In some cases, though, it’s necessary to prioritize specific requests. These requests should be processed earlier than lower priority requests that were sent previously by the application.

Solution

A queue is usually a first-in, first-out (FIFO) structure, and consumers typically receive messages in the same order that they were posted to the queue. However, some message queues support priority messaging. The application posting a message can assign a priority and the messages in the queue are automatically reordered so that those with a higher priority will be received before those with a lower priority. 

Challenge

An application running in the cloud is expected to handle a large number of requests. Rather than process each request synchronously, a common technique is for the application to pass them through a messaging system to another service (a consumer service) that handles them asynchronously. This strategy helps to ensure that the business logic in the application isn’t blocked while the requests are being processed.

The number of requests can vary significantly over time for many reasons. A sudden increase in user activity or aggregated requests coming from multiple tenants can cause an unpredictable workload. At peak hours a system might need to process many hundreds of requests per second, while at other times the number could be very small. Additionally, the nature of the work performed to handle these requests might be highly variable. 

Solution

Use a message queue to implement the communication channel between the application and the instances of the consumer service. The application posts requests in the form of messages to the queue, and the consumer service instances receive messages from the queue and process them. This approach enables the same pool of consumer service instances to handle messages from any instance of the application. 

Azure Container Service: If you are looking to deploy your application in Linux environment and are comfortable with an orchestrator such as Swarm, Kubernetes or DC/OS, use ACS. A typical 3 tier application (such as a web front end, a caching layer, a API layer and a database layer) can be easily containerized with 1 single dockerfile (or docker-compose file). It can be continuously decomposed into smallerservices gradually. This approach provides an immediate benefit of portability of such an application. Containers is Open technology and there is great community support around containers.

Azure Service Fabric: If an application must have its state saved locally, then use Service Fabric. It is also a good choice if you are looking to deploy application in Windows server ecosystem(Linux support is in the works as well). 

Azure Functions: If an application needs an HTTP endpoint for a potentially long running  process without getting into a elaborate programming model, Azure Functions is a good option. They can be developed as an extension of an existing application. They support routing based endpoints similar to an API. They support AAD and other authentication, SSL, Custom Domain, RBAC, etc. They have a good CI/CD support as well. They are in the process of integrating .Net Core support. So if you are looking to get a simple application model and don’t want to get into setting up/managing underlying infrastructure, Azure Functions is good choice.

Microservices developed using Service Fabric have many advantages such as:

• Hyper Scale — Application developed using Service Fabric can be independently created and deployed without any dependencies. The services can be auto-scaled based on CPU Consumption, Memory Usage etc., Service Fabric can help with maximizing resource utilization with features such as load balancing, partitions, and replications across all nodes in the cluster.
• Partitioning — Stateful services can be partitioned across multiple nodes in a cluster. The partitions are re-balanced regularly to ensure resource availability to each service deployed on the cluster.
• Rolling Upgrades — Services deployed on service fabric platform can be updated in stages with minimum downtime. The update domains are used to divide the nodes in the cluster into logical groups which are updated one at a time. When a service needs to be upgraded (new version deployed), Service Fabric can ensure that newer version can be rolled out one node at at time, thereby ensuring that there is no downtime.
• High Density — Service Fabric offers native support for Microservices. Each service hosted on the Service Fabric will be logically isolated and can be managed without affecting other services. This ensures that a relatively high number of Microservices can be deployed to a node, to maximize resource utilization. This can significantly reduce the costs associated with hosting applications.
• Fault Tolerance — Microservices deployed on Service Fabric can leverage the support of automatic fault tolerance. When Service Fabric detects a fault on an instance of a microservice, it can automatically spin up the new instance of the microservice on a healthy node within the cluster to ensure availability. This process is completely automated and requires no additional effort from the teams managing the clusters or developing microservices.
• Reverse Proxy — When you provision a Service Fabric cluster, you have an option of installing Reverse Proxy on each of the nodes on the cluster. It performs the service resolution on the client’s behalf and forwards the request to the correct node which contains the application. In majority of the cases, services running on the Service Fabric run only on the subset of the nodes.